GHSA-fqc7-9xjw-jrh3
Suggest an improvement- Source
- https://github.com/advisories/GHSA-fqc7-9xjw-jrh3
- Import Source
- https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/06/GHSA-fqc7-9xjw-jrh3/GHSA-fqc7-9xjw-jrh3.json
- JSON Data
- https://api.osv.dev/v1/vulns/GHSA-fqc7-9xjw-jrh3
- Aliases
- Published
- 2026-06-09T21:58:11Z
- Modified
- 2026-09-10T03:50:49Z
- Severity
-
- 6.9 (Medium) CVSS_V4 - CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N CVSS Calculator
- Summary
- SymfonyRuntime CVE-2024-50340 Patch Bypass: Web Requests Can Still Set APP_ENV/APP_DEBUG via parse_str/SAPI Argv Mismatch
- Details
-
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-debugthrough$_SERVER['argv']. The fix shipped insymfony/runtime5.4.46 / 6.4.14 / 7.1.7 gated the argv read onempty($_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 whenregister_argc_argv=On) do not agree on every input, so an attacker can craft a query that leaves$_GETempty 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 throughsymfony/runtime; from an unauthenticated GET an attacker can flipAPP_ENVand toggleAPP_DEBUG.Resolution
SymfonyRuntimenow gates the argv read onisset($_SERVER['QUERY_STRING'])rather than onempty($_GET).QUERY_STRINGis 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 whenQUERY_STRINGis 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.
- Database specific
{ "cwe_ids": [ "CWE-20", "CWE-436", "CWE-74" ], "github_reviewed": true, "github_reviewed_at": "2026-06-09T21:58:11Z", "nvd_published_at": null, "severity": "MODERATE" }- References
Affected packages
Packagist
symfony/runtime
Package
- Name
- symfony/runtime
- Purl
- pkg:composer/symfony/runtime
symfony/runtime
Package
- Name
- symfony/runtime
- Purl
- pkg:composer/symfony/runtime
symfony/runtime
Package
- Name
- symfony/runtime
- Purl
- pkg:composer/symfony/runtime
symfony/runtime
Package
- Name
- symfony/runtime
- Purl
- pkg:composer/symfony/runtime
symfony/symfony
Package
- Name
- symfony/symfony
- Purl
- pkg:composer/symfony/symfony
symfony/symfony
Package
- Name
- symfony/symfony
- Purl
- pkg:composer/symfony/symfony
symfony/symfony
Package
- Name
- symfony/symfony
- Purl
- pkg:composer/symfony/symfony
Affected versions
v7.*
symfony/symfony
Package
- Name
- symfony/symfony
- Purl
- pkg:composer/symfony/symfony