HighGHSA-6h46-9jf5-q59xCVE-2026-48489

Symfony: Security Firewall Bypass via failure_forward Subrequest: Unauthenticated Access to access_control-Protected GET Routes

Published 15 Jun 2026 · Updated 10 Sept 2026

Affected packages

Affected
<5.4.53
Fixed in
5.4.53
Update to the fixed version for your release line, for example:composer require symfony/security-http:^5.4.53
Affected
<5.4.53
Fixed in
5.4.53
Update to the fixed version for your release line, for example:composer require symfony/symfony:^5.4.53
Affected
>=6.0.0 <6.4.41
Fixed in
6.4.41
Update to the fixed version for your release line, for example:composer require symfony/security-http:^6.4.41
Affected
>=7.0.0 <7.4.13
Fixed in
7.4.13
Update to the fixed version for your release line, for example:composer require symfony/security-http:^7.4.13
Affected
>=8.0.0 <8.0.13
Fixed in
8.0.13
Update to the fixed version for your release line, for example:composer require symfony/security-http:^8.0.13
Affected
>=6.0.0 <6.4.41
Fixed in
6.4.41
Update to the fixed version for your release line, for example:composer require symfony/symfony:^6.4.41
Affected
>=7.0.0 <7.4.13
Fixed in
7.4.13
Update to the fixed version for your release line, for example:composer require symfony/symfony:^7.4.13
Affected
>=8.0.0 <8.0.13
Fixed in
8.0.13
Update to the fixed version for your release line, for example:composer require symfony/symfony:^8.0.13

Details

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.

Is GHSA-6h46-9jf5-q59x in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected symfony/security-http, and gives you the command that fixes it.

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.