Symfony: HEAD Requests Bypass the methods Option of security.access_control Rules and Firewalls
- Exploited
- No known exploitation
- Fix
- Fixed in 5.4.56, 6.4.50, 7.4.23, 8.1.11
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 5.4.56, 6.4.50, 7.4.23, 8.1.11.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 33/100 · provisional
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Symfony's HttpFoundation component, used to match requests in security access controls and firewalls, can be bypassed by sending a HEAD request instead of GET. Remotely, without logging in, an attacker can get past rules meant only for GET requests, reading response headers and triggering controller code and its side effects.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original description
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.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure17/25No login or user action needed per the CVSS vector, reachable over the network without a login · Unknown: No advisory context yet
- Reach10/20Affects Packagist packages
- Severity6.3/10CVSS 6.3
- No patch0/5No signal
What would change the score
- Would score about 78 if added to CISA KEV
- Would score about 73 if CISA's SSVC rates exploitation active
- Would score about 38 if advisories confirm default setups are exposed
What to do
Upgrade to a fixed version: 5.4.56, 6.4.50, 7.4.23, 8.1.11.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- symfony/http-foundationPackagist
fixed in 5.4.56; From 6 · fixed in 6.4.50; From 7 · fixed in 7.4.23; From 8 · fixed in 8.1.11
Evidence 3
- Advisory
- Patch
- Patch
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-118514
Is CVE-2026-118514 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
Which versions are affected by CVE-2026-118514?
symfony/http-foundation (Packagist): before 5.4.56; from 6 before 6.4.50; from 7 before 7.4.23; from 8 before 8.1.11.Source: cve.now feed data
How do I fix CVE-2026-118514?
Upgrade to a fixed version: 5.4.56, 6.4.50, 7.4.23, 8.1.11.Source: cve.now feed data