Read the docs
TI-2026-85932 Aliases CVE-2026-118514

HEAD requests bypass HTTP method rules in Symfony HttpFoundation

Priority LOW 29CWE-863Published · Updated

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

EPSS 0.00613 49th percentileScored 2026-11-07
Fix Fixed No fixed version in the sources yet

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.

CPEVersionsRoleVendor
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

  1. 2026-11-06 Threatist record created from CVE-2026-118514
  2. 2026-11-08 Priority changed: MEDIUM → LOW

References

  • 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
See all 94 →

Sources

This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences