---
id: "CVE-2026-118514"
page: "https://infrastack.ai/live/CVE-2026-118514"
kind: "vulnerability"
aliases: ["CVE-2026-118514"]
title: "Symfony HttpFoundation: HEAD requests bypass GET-only access rules"
severity: "medium"
cvss: 6.3
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["package", "php", "symfony", "web-apps"]
not_affected_if: ["fixed-version", "no-custom-request-matcher", "no-get-only-rules"]
published_at: "2026-11-06T15:17:11+00:00"
first_seen_at: "2026-11-06T15:42:43+00:00"
updated_at: "2026-11-06T15:44:30+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-118514", "first_seen_at": "2026-11-06T15:42:43+00:00"}]
exploit_sources: []
---

# Symfony HttpFoundation: HEAD requests bypass GET-only access rules

Link for people: https://infrastack.ai/live/CVE-2026-118514 (this .md is for agents)

Symfony's request matcher compares HTTP methods verbatim, so a HEAD request to a GET-only route is not matched by GET rules while the router still runs the GET controller. An attacker can bypass GET-only security rules and trigger controller side effects, reading response headers.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Look for `symfony/http-foundation` in `composer.lock` and check the installed version with `composer show symfony/http-foundation`
- Search the app for `methods: [GET]` in firewall or access_control config and for custom `request_matcher` entries using RequestMatcher or MethodRequestMatcher
- Check whether GET-only controllers have side effects reachable with HEAD

## Fix

- `symfony/http-foundation` 5.4.56
- `symfony/http-foundation` 6.4.50
- `symfony/http-foundation` 7.4.23
- `symfony/http-foundation` 8.1.11

## Timeline

- 2026-11-06T15:42:43+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-118514

## Documents

- [advisory] Vendor advisory: github.com https://github.com/symfony/symfony/security/advisories/GHSA-jrf8-gvm4-7cgh
- [fix] Patch: github.com https://github.com/symfony/symfony/commit/13a8b85be687499cbc69a534ada16683f9ba3889
- [fix] Patch: github.com https://github.com/symfony/symfony/commit/cd20e9f8f16d1f0df6c2eac19bdb649325a192bd

## From the sources

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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_