CVE-2024-50340

What it actually does

This vulnerability affects Symfony Runtime when PHP is configured with `register_argc_argv=On`. In affected versions, a web request can cause PHP to populate CLI-style `argv` values from a crafted query string, and Symfony Runtime may incorrectly trust those values while bootstrapping the application kernel. An unauthenticated remote attacker can therefore influence runtime options such as the application environment and debug mode for the handling of that request. The practical impact is improper input validation at application bootstrap: attacker-controlled URL input can alter security-relevant execution context, potentially enabling debug behavior, verbose errors, alternate configuration loading, information disclosure, and application behavior changes.

Why it matters to the business

Public Symfony applications using affected Symfony Runtime versions may allow unauthenticated users to force the application to process requests as if it were running in a different environment or with debugging enabled. This can expose sensitive configuration details, stack traces, source paths, internal service names, or secrets present in debug output, and can also cause operational instability if non-production configuration is selected. The CVSS score is high, the EPSS score is elevated, and exploit maturity is reported as weaponized, so internet-facing Symfony applications should be treated as priority remediation targets even though this issue is not currently listed in CISA KEV and is not known to be tied to ransomware campaigns.

How an attack unfolds

An attacker first identifies a Symfony application that uses Symfony Runtime and is served by a PHP runtime where `register_argc_argv` is enabled. The attacker then sends HTTP requests containing CLI-style option syntax in the query string, such as options intended to influence environment or debug settings. Because PHP can expose the query string as `argv` values and affected Symfony Runtime versions read those values outside of a true command-line context, the application may bootstrap the kernel using attacker-supplied runtime options. The attacker then observes differences in responses, headers, errors, logs, profiler exposure, cache behavior, or debug output to confirm whether the application entered a different environment or enabled debug handling. Successful exploitation can disclose diagnostic information, reveal application internals, and in some deployments alter configuration-dependent behavior for the targeted request.

How to fix it

Upgrade Symfony Runtime/Symfony to a fixed release. The vendor-fixed versions are Symfony Runtime 5.4.46, 6.4.14, and 7.1.7 or later; for source-based deployments, ensure the fix containing commit `057d88bef2d18a10d3b0b8fb093332131dc58e2f` is present. Run dependency updates through the normal package manager, rebuild application artifacts, clear and warm Symfony caches, and redeploy all affected web nodes or containers. As defense in depth, verify that `register_argc_argv` is disabled for web-facing PHP SAPIs where application compatibility allows, but do not treat that as a complete substitute for upgrading because the vendor guidance is to apply the fixed Symfony Runtime behavior. Also ensure production deployments do not expose Symfony profiler or development routes and that debug mode is not enabled by default.

How to confirm the fix worked

Confirm the deployed dependency version is fixed by checking `composer.lock`, `composer show symfony/runtime`, or the bundled Symfony framework version and verifying it is at least 5.4.46, 6.4.14, or 7.1.7 as applicable. For source builds, verify that commit `057d88bef2d18a10d3b0b8fb093332131dc58e2f` or an equivalent patch is present. Check PHP configuration for the web SAPI with `phpinfo()`, `php -i` for matching configuration, container image configuration, or FPM pool configuration and confirm whether `register_argc_argv` is enabled or disabled. After patching in a safe test environment, send benign requests containing URL-encoded and plain CLI-style query strings such as debug or environment flags and verify that the application does not change environment, does not enable debug mode, does not expose profiler/debug artifacts, and does not create or write development cache/log files as a result of the request.

Typical attack path

1. Reconnoiter public web applications likely to be built with Symfony or PHP and identify endpoints that route through the Symfony front controller.
2. Send crafted HTTP requests with query strings containing CLI-style Symfony/runtime options such as environment or debug flags.
3. Rely on PHP `register_argc_argv=On` behavior to expose the crafted query string through `argv` to the application runtime.
4. Trigger affected Symfony Runtime bootstrap logic to consume attacker-controlled `argv` values in a non-CLI web request.
5. Compare responses for signs of changed environment or debug behavior, such as verbose exception pages, debug headers, profiler artifacts, different cache paths, or configuration-dependent content.
6. Use the exposed diagnostic information or altered behavior to gather sensitive implementation details and support follow-on attacks.

How to detect it

Review HTTP access logs, reverse proxy logs, WAF logs, CDN logs, and application logs for requests where the query string contains CLI-style flags. Focus on requests containing `--env`, `-e`, `--debug`, `--no-debug`, or URL-encoded hyphen variants such as `%2D%2Denv` and `%2D%2Ddebug`, especially when sent to normal application routes rather than administrative endpoints. Correlate those requests with Symfony application logs for evidence that the request was handled in an unexpected environment or debug mode, including creation or updates to `var/log/dev.log`, `var/cache/dev/`, verbose exception pages, `X-Debug-Token` headers, Symfony profiler activity, or requests to `/_profiler` and `/_wdt` following suspicious probes. Check filesystem timestamps and deployment artifacts for unexpected development cache or log directories on production systems. If centralized tracing or APM is available, search for request URLs containing CLI-style options and compare response status codes, error rates, and exception detail exposure around those events.

• ?--env=
• ?%2D%2Denv%3D
• --env=dev
• --env=prod
• ?--debug
• ?%2D%2Ddebug
• ?--no-debug
• ?%2D%2Dno-debug
• ?-e
• ?%2De
• X-Debug-Token
• /_profiler
• /_wdt
• var/log/dev.log
• var/cache/dev/
• register_argc_argv = On
• register_argc_argv=On
• Symfony Profiler

What your security team should do

• Prioritize patching internet-facing Symfony applications that use Symfony Runtime because exploitation is remote, unauthenticated, low-complexity, and reported as weaponized with elevated EPSS.
• Inventory PHP applications using `symfony/runtime` or Symfony full-stack packages and map deployed versions to the fixed releases 5.4.46, 6.4.14, and 7.1.7 or later.
• Review web PHP configuration for `register_argc_argv=On`; disable it for web-facing runtimes where feasible as defense in depth after compatibility testing.
• Search historical web access logs for query strings containing Symfony/CLI-style options such as `--env`, `--debug`, `--no-debug`, and URL-encoded equivalents.
• Inspect Symfony logs, cache directories, and deployment artifacts for unexpected production creation or modification of `var/log/dev.log`, `var/cache/dev/`, profiler routes, or debug headers around suspicious requests.
• Block or alert on HTTP requests to production applications that include CLI-style option syntax in query strings, especially leading hyphen arguments and encoded hyphens.
• Verify that production Symfony profiler and development routes such as `/_profiler` and `/_wdt` are not reachable from untrusted networks.
• After remediation, perform regression testing to ensure crafted query strings no longer influence `APP_ENV`, `APP_DEBUG`, or kernel boot behavior.