Summary
Symfony: Security Firewall Bypass via failureforward Subrequest: Unauthenticated Access to accesscontrol-Protected GET Routes
Description
When a firewall is configured with form-login (or any authenticator using DefaultAuthenticationFailureHandler) and the failure_forward: true option, the handler reads the _failure_path parameter from the failing login request and uses it as the path of an internal subrequest dispatched through HttpKernelInterface::SUB_REQUEST.
Symfony's Firewall::onKernelRequest listener intentionally skips subrequests under the assumption they are internally generated and trusted, which also means AccessListener (the listener that evaluates access_control) does not run. Because the attacker controls the target of the subrequest, an unauthenticated POST to the check path with _failure_path=/admin/whatever performs a local request forgery that executes the target controller outside the firewall perimeter and returns its response to the caller.
Applications that follow Symfony's recommended best practice of protecting administrative areas with broad access_control rules (e.g. ^/admin requires ROLE_ADMIN) and expose read-only GET endpoints under that area (data exports, internal APIs, account views) are fully exposed: any such GET route can be read by an unauthenticated attacker without any developer misconfiguration, debug mode, or state-changing GET handler being required.
Resolution
DefaultAuthenticationFailureHandler no longer honors the request-supplied _failure_path parameter when failure_forward is enabled. The subrequest is always dispatched to the configured failure_path option (defaulting to login_path), which is set by the application owner and not by the request. The redirect branch (failure_forward: false) is unchanged because redirects re-enter the firewall on the next request and are not subject to this bypass.
The patch for this issue is available here for branch 5.4.
Credits
Symfony would like to thank Nguyen Ngoc Toan Thang (@a-tt-om) and Tran Quoc Tri Trung (@teebow1e) for reporting the issue, and Nicolas Grekas for providing the fix.
Impact
The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
symfony/security-http to 5.4.53 or later; symfony/symfony to 5.4.53 or later; symfony/security-http to 6.4.41 or later; symfony/security-http to 7.4.13 or later; symfony/security-http to 8.0.13 or later; symfony/symfony to 6.4.41 or later; symfony/symfony to 7.4.13 or later; symfony/symfony to 8.0.13 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-48489? CVE-2026-48489 is a high-severity incorrect authorization vulnerability in symfony/security-http (composer), affecting versions < 5.4.53. It is fixed in 5.4.53, 6.4.41, 7.4.13, 8.0.13. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
- Which packages are affected by CVE-2026-48489?
symfony/security-http(composer) (versions < 5.4.53)symfony/symfony(composer) (versions < 5.4.53)
- Is there a fix for CVE-2026-48489? Yes. CVE-2026-48489 is fixed in 5.4.53, 6.4.41, 7.4.13, 8.0.13. Upgrade to this version or later.
- Is CVE-2026-48489 exploitable, and should I be worried? Whether CVE-2026-48489 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-48489 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-48489?
- Upgrade
symfony/security-httpto 5.4.53 or later - Upgrade
symfony/symfonyto 5.4.53 or later - Upgrade
symfony/security-httpto 6.4.41 or later - Upgrade
symfony/security-httpto 7.4.13 or later - Upgrade
symfony/security-httpto 8.0.13 or later - Upgrade
symfony/symfonyto 6.4.41 or later - Upgrade
symfony/symfonyto 7.4.13 or later - Upgrade
symfony/symfonyto 8.0.13 or later
- Upgrade