Affected versions
Symfony HTTP Foundation versions <5.4.56, >=6, <6.4.50, >=7, <7.4.23, >=8, <8.1.11 are affected by this security issue.
The issue has been fixed in Symfony HTTP Foundation 5.4.56, 6.4.50, 7.4.23, 8.1.11.
Description
Symfony\Component\HttpFoundation\RequestMatcher, and RequestMatcher\MethodRequestMatcher which replaces it from 6.2 on, match a request against a list of HTTP methods. They compared the request method to the list verbatim, while the router serves a HEAD request with the GET handler, as HTTP semantics require.
Anything restricted to GET through such a matcher therefore did not apply to the same URL requested with HEAD. The reachable consequence is security.access_control, whose rules SecurityBundle compiles into these matchers, and firewalls, whose methods option is compiled the same way:
1 2 3
security:
access_control:
- { path: ^/admin, roles: ROLE_ADMIN, methods: [GET] }
1 2
GET /admin -> 401 or 403 without ROLE_ADMIN
HEAD /admin -> 200, the controller runs with no access rule applied
The response carries no body, but its headers leak, and the controller executes with any side effect it has. A firewall restricted with methods: [GET] has the same gap: a HEAD request falls through to the next firewall matching the path, or to none. An application that builds a request matcher itself, for a custom firewall request_matcher or for any other method-restricted decision, is affected the same way.
The fix for CVE-2026-45075 addressed the same gap in the #[IsGranted], #[IsSignatureValid] and #[IsCsrfTokenValid] attributes only.
Resolution
Both matchers now add HEAD to their list of methods whenever GET is in it, so they agree with the router. Lists without GET, and lists that already carry HEAD, are unchanged.
A rule or a firewall restricted to HEAD that comes after one restricted to GET for the same path is no longer reached. Applications that need a different rule for HEAD requests have to list it first, as they would for routes.
The patches for this issue are available here for branch 5.4 and here for branch 6.4 (and forward-ported to 7.4, 8.1 and 8.2). The 5.4 patch fixes RequestMatcher, which 6.4 still ships as deprecated, and the 6.4 patch fixes MethodRequestMatcher, which replaces it.
Credits
We would like to thank Ivan Tse for reporting the issue and Nicolas Grekas for providing the fix.
We would also like to thank Bruno Dias and Joao Regateiro from Checkmarx for their help getting a CVE assigned.