Loading vulnerability…
CVE-2026-3854 is a remote code execution vulnerability in GitHub Enterprise Server caused by improper neutralization of special elements in user-supplied git push option values. During processing of a git push, attacker-controlled push option values were incorporated into internal service headers without sufficient sanitization. Because the internal header format used a delimiter character that could also be supplied by the user, a malicious actor could inject additional metadata fields that downstream components interpreted as trusted internal values. This trust boundary failure enabled manipulation of the execution environment for push processing, bypass of sandboxing protections, and arbitrary command execution on the server handling the push. Affected GitHub Enterprise Server releases include 3.14.x before 3.14.25, 3.15.x before 3.15.20, 3.16.x before 3.16.16, 3.17.x before 3.17.13, 3.18.x before 3.18.7, and 3.19.x before 3.19.4.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (7 hidden).
This repository is not a standalone offensive exploit against a third-party product; it is an intentionally vulnerable educational lab that reconstructs the concepts behind CVE-2026-3854 using a downstream-modified Forgejo build called ForgeDock. The repo packages a complete local environment with Docker Compose, a FastAPI portal, an isolated pre-receive runner, a disposable web terminal, Redis-backed tracing, and a vendored Forgejo tree containing the vulnerable Go processor. Core exploit capability: authenticated users can abuse Git push options to influence downstream repository-event processing. Documentation and tests describe the vulnerable chain clearly: ForgeDock serializes trusted receive state and raw push-option text into a semicolon-delimited envelope; the parser then splits on semicolons, accepts duplicate protected keys, and applies last-write-wins semantics. This lets attacker-controlled push-option text override protected fields such as pipeline_mode, runtime_mode, custom_hooks_enabled, hook_root, and hook_manifest. The final stage resolves a hook path and dispatches it to the internal executor, enabling constrained backend code execution of lab-owned tools. Repository structure: (1) root docs explain architecture, threat model, curriculum, and deployment; (2) docker-compose.yml orchestrates lab-init, forgejo, forgejo-bootstrap, portal, web-terminal, hook-executor, and redis; (3) services/portal contains the FastAPI web UI for Learning Lab and Research Lab, including challenge definitions and trace-driven progression; (4) services/pre_receive_runner contains the executor API that authenticates requests and only runs exact allowlisted binaries under /opt/forgedock; (5) challenge/system-tools contains three shell scripts that echo a FLAG environment variable; (6) scripts/ contains environment initialization, smoke tests, provenance checks, and release hygiene tooling; (7) vendor/forgejo contains the pinned downstream Forgejo source with the vulnerable repositoryevents processor added. Main exploit flow by stage: Stage 1 uses a legitimate tag=<name> push option to create a server-side tag and recover a proof embedded in annotated tag metadata. Stage 2 injects a duplicate protected field to override pipeline_mode to diagnostic and recover a diagnostic proof from push output. Stage 3 injects multiple protected fields so the legacy custom-hook branch resolves to /opt/forgedock/system-tools/escape-hook, which the executor runs and returns a proof banner/flag. The executor is intentionally constrained: it requires a bearer token, rejects relative/out-of-root paths, forbids caller-supplied commands/environment, and only permits three exact executables. Notable files: services/pre_receive_runner/main.py implements the authenticated execution boundary; docker-compose.yml exposes the public/local services and internal executor URL; services/portal/main.py and curriculum.py define the user-facing exploit workflow; docs/architecture/push-option-processing.md and docs/learning/*.md document the vulnerable serialization/parsing chain; tests/integration/test_end_to_end.py demonstrates the full exploit sequence end-to-end. Overall, this is a real, operational lab environment for studying an authenticated push-option-to-RCE chain, not a fake exploit or mere detector.
Small 3-file repository containing a README, license, and a single Python script (exploi-git.py). The Python file is the sole code artifact and entry point. It is a self-contained educational proof-of-concept for CVE-2026-3854, modeling GitHub's vulnerable X-Stat header construction/parsing logic entirely in memory. The script defines baseline X-Stat fields, a vulnerable header builder that concatenates push options with semicolons, a parser that honors the last occurrence of duplicate keys, and a patched sanitizer that percent-encodes semicolons. It then runs three demos: (1) basic injection overriding rails_env from production to staging, (2) a conceptual multi-step RCE chain that changes rails_env, custom_hooks_dir, repo_pre_receive_hooks, and enterprise_mode to show how unsandboxed hook execution could occur, and (3) patched behavior showing the injection is neutralized. It also prints a conceptual git push command and external references. No live exploitation occurs: there are no network connections, no subprocess execution, and no file writes. The exploit capability is therefore demonstrative rather than operational, but it clearly documents the attack path and the critical fields/paths involved.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
249 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A high-severity remote code execution vulnerability in GitHub Enterprise products caused by improper sanitization of user-supplied git push option values, enabling command injection and arbitrary command execution on vulnerable systems.
A remote code execution vulnerability in GitHub’s handling of user-supplied git push options, caused by improper sanitization that enabled command/header injection and sandbox bypass.
A critical remote code execution vulnerability in GitHub's handling of user-supplied options during git push operations, allowing attackers with push access to inject trusted metadata fields, bypass sandboxing, execute arbitrary code, and gain read/write access to private repositories or fully compromise vulnerable GitHub Enterprise Server instances.
A high-severity vulnerability in GitHub's git infrastructure caused by internal services blindly trusting user-supplied push option input, enabling attackers to inject trusted internal metadata and gain full read/write access to private GitHub repositories.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.