GHSA-fqc7-9xjw-jrh3
GHSA-fqc7-9xjw-jrh3 is a CWE-436 vulnerability in symfony/runtime. O3 Security confirms whether GHSA-fqc7-9xjw-jrh3 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SymfonyRuntime CVE-2024-50340 Patch Bypass: Web Requests Can Still Set APP_ENV/APP_DEBUG via parse_str/SAPI Argv Mismatch
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-fqc7-9xjw-jrh3.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
symfony/runtime🐘symfony/runtime🐘symfony/runtime🐘symfony/runtime🐘symfony/symfony🐘symfony/symfony🐘symfony/symfony🐘symfony/symfonyReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Description
CVE-2024-50340 (GHSA-x8vp-gf4q-mw5j) addressed an issue where, with register_argc_argv=On, a crafted query string let an unauthenticated GET change the kernel environment and debug flag by feeding --env/--no-debug through $_SERVER['argv']. The fix shipped in symfony/runtime 5.4.46 / 6.4.14 / 7.1.7 gated the argv read on empty($_GET) as a proxy for "is this a CLI invocation".
That proxy is unsafe: parse_str() (which builds $_GET) and the web SAPI (which builds $_SERVER['argv'] from the raw query when register_argc_argv=On) do not agree on every input, so an attacker can craft a query that leaves $_GET empty while $_SERVER['argv'] carries the attacker's flags. SymfonyRuntime::getInput() then parses them, restoring the exact primitive CVE-2024-50340 was meant to prevent.
Preconditions and impact match the original CVE: web SAPI, register_argc_argv=On, app booted through symfony/runtime; from an unauthenticated GET an attacker can flip APP_ENV and toggle APP_DEBUG.
Resolution
SymfonyRuntime now gates the argv read on isset($_SERVER['QUERY_STRING']) rather than on empty($_GET). QUERY_STRING is the same input the SAPI uses to build argv, so the security check and the thing it protects no longer parse different sources. Worker SAPIs (FrankenPHP / RoadRunner / Swoole) keep working because the runtime constructor runs once at boot when QUERY_STRING is unset.
The patch for this issue is available here for branch 5.4.
Credits
SymfonyRuntime would like to thank 0xEr3n for reporting the issue and Nicolas Grekas for providing the fix.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | symfony/runtime | ≥ 5.4.46&&< 5.4.52 | 5.4.52 |
| 🐘Packagist | symfony/runtime | ≥ 6.4.14&&< 6.4.40 | 6.4.40 |
| 🐘Packagist | symfony/runtime | ≥ 7.1.7&&< 7.4.12 | 7.4.12 |
| 🐘Packagist | symfony/runtime | ≥ 8.0.0&&< 8.0.12 | 8.0.12 |
| 🐘Packagist | symfony/symfony | ≥ 5.4.46&&< 5.4.52 | 5.4.52 |
| 🐘Packagist | symfony/symfony | ≥ 6.4.14&&< 6.4.40 | 6.4.40 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for symfony/runtime. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update symfony/runtime to 5.4.52 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fqc7-9xjw-jrh3 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-fqc7-9xjw-jrh3 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-fqc7-9xjw-jrh3. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-fqc7-9xjw-jrh3 in your dependencies?
O3 detects GHSA-fqc7-9xjw-jrh3 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.