GHSA-fqc7-9xjw-jrh3
SymfonyRuntime CVE-2024-50340 Patch Bypass: Web Requests Can Still Set APP_ENV/APP_DEBUG via parse_str/SAPI Argv Mismatch
Blast Radius
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.