HEAD requests bypass HTTP method rules in Symfony HttpFoundation
Key facts
- Attack vector
- Network
- Privileges required
- None
- User interaction
- None
- Attack complexity
- Low
- Attack requirements
- Present
- Impact type
- Security bypass
- Confidentiality · integrity · availability
- Low · Low · None
- Fix status
- Fixed
Attack profile from CVSS 4.0 · CNA. Fix status from CNA. Impact type from CWE-863.
Summary
Symfony HttpFoundation before 5.4.56, 6.4.50, 7.4.23 and 8.1.11 compares request methods verbatim, so a HEAD request does not match rules written for GET. The router serves HEAD requests with the GET handler (CWE-863), so an unauthenticated remote attacker can bypass access_control method rules and firewalls limited to GET and run the controller. HEAD responses carry no body, but the attacker can still read response headers.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
Description from the CNA
In Symfony http-foundation prior to versions 5.4.56, 6.4.50, 7.4.23, and 8.1.11, Symfony\Component\HttpFoundation\RequestMatcher, and RequestMatcher\MethodRequestMatcher which replaces it from 6.2.x on, matches a request against a list of HTTP methods. These compared the request method to the list verbatim, while the router serves a HEAD request with the GET handler, as HTTP semantics require. This came after the incomplete fix of CVE-2026-45075 https://github.com/advisories/GHSA-6439-2f28-8p8q , which addressed the same gap in the #[IsGranted], #[IsSignatureValid] and #[IsCsrfTokenValid] attributes only. Security rules configured to apply only to GET requests could therefore be bypassed by sending a HEAD request to the same URL. Although HEAD responses contain no body, attackers could still access response headers and trigger the controller's execution, including any side effects. This issue also affects firewalls configured with methods: [GET]. A HEAD request would not match that firewall and could instead be handled by another matching firewall or no firewall at all. Applications using these vulnerable request matchers directly, including through a custom firewall request_matcher, could also be affected. The issue affects symfony/http-foundation through v5.4.55, v6.x through 6.4.49, v7.x through v7.4.22, and v8.x through v8.1.10.
Why it matters now
SSVC decision points
Not available: CISA has not published SSVC decision points for this record.
Affected products
No affected products listed by the sources yet.
CPE names Threatist (inferred) · 1
Inferred from how NVD named this product before; not given by a source.
| CPE | Versions | Role | Vendor |
|---|---|---|---|
| cpe:2.3:a:sensiolabs:symfony:*:*:*:*:*:*:*:* | — | — | sensiolabs |
- cpe:2.3:a:sensiolabs:symfony:*:*:*:*:*:*:*:* Versions — — ·sensiolabs
Remediation
Upgrade symfony/http-foundation to 5.4.56, 6.4.50, 7.4.23 or 8.1.11, matching your major version.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
Timeline
- 2026-11-06 Threatist record created from CVE-2026-118514
- 2026-11-08 Priority changed: MEDIUM → LOW
References
More symfony vulnerabilities
- TI-2024-33775 Ability to change environment from query in symfony/runtime CVSS 3.1HIGH 7.3
- TI-2026-34283 Twig: The `spaceless` filter implicitly marks its output as safe CVSS 4.0MEDIUM 5.1
- TI-2022-07667 Code injection in Twig CVSS 3.1CRITICAL 9.8
- TI-2018-10028 Twig before 2.4.4 allows Server-Side Template Injection (SSTI) via the search search_key… CVSS 3.0CRITICAL 9.8
- TI-2026-35851 Incorrect authorization in symfony CVSS 4.0HIGH 8.7
- TI-2026-35264 Improper input validation in symfony CVSS 4.0HIGH 8.3
Sources
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences