---
id: "CVE-2026-118516"
kind: "vulnerability"
aliases: ["CVE-2026-118516"]
title: "Symfony Routing: host placeholders let a request bypass path-based access rules"
severity: "medium"
cvss: 6.3
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["package", "php", "symfony", "symfony-routing", "web-apps"]
not_affected_if: ["no-host-placeholders", "no-path-based-access-control", "patched-version"]
published_at: "2026-11-04T13:17:26+00:00"
first_seen_at: "2026-11-04T13:27:01+00:00"
updated_at: "2026-11-04T13:28:17+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-118516", "first_seen_at": "2026-11-04T13:27:01+00:00"}]
---

# Symfony Routing: host placeholders let a request bypass path-based access rules

Symfony's two route matchers parse the host and path differently when a route has a host placeholder, so a crafted Host header or hostname can route a request to a protected controller. An anonymous attacker can then reach controllers that access_control or firewall path rules were meant to block.

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

## How to check

- Run `composer show symfony/routing` and compare the version against the fixed ranges.
- Search route definitions for host placeholders such as `app.{domain}` on routes that also rely on path-based `access_control` or firewall rules.
- Check whether `framework.trusted_hosts` is set and whether the web server passes the raw Host header through.

## Fix

- Symfony 5.4: upgrade to `5.4.56` or later
- Symfony 6.4: upgrade to `6.4.50` or later
- Symfony 7.4: upgrade to `7.4.23` or later
- Symfony 8.1: upgrade to `8.1.11` or later

## Timeline

- 2026-11-04T13:27:01+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-118516

## Documents

- [advisory] Vendor advisory: github.com https://github.com/symfony/symfony/security/advisories/GHSA-xqw3-x93m-887x
- [fix] Patch: github.com https://github.com/symfony/symfony/commit/067cde51e29f6d605de4de53322a02c6e23b5416

## From the sources

The Symfony Routing components CompiledUrlMatcher and UrlMatcher interpret the host and path information differently, allowing path-based authorization rules to be bypassed in Symfony versions prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11.




For routes that define a host, CompiledUrlMatcher matches the string $host.'.'.$pathinfo against the host regular expression followed by the path regular expression, while UrlMatcher matches the host and the path separately. A host placeholder can therefore  match /, and consume the beginning of the path, so the request is routed to a controller, while UrlMatcher  would find no route. Rules that look at the path, such as access_control entries and firewall patterns, are evaluated against the actual request path, so they do not apply while the controller of the route runs, potentially allowing an unauthenticated request to reach a protected controller. For example, with the route /admin/report/{id}, the host app.{domain} and the rule access_control: [{ path: ^/admin, roles: ROLE_ADMIN }], an anonymous request for /admin/report/1 is sent to the login page. A request with the Host header app and path /x./admin/report/1 instead reaches the controller, with domain="/x". With the required domain: .+, the real hostname works: app.example.com and /x./admin/report/1 match with domain="example.com./x".




Applications are affected if they have routes with host placeholders protected by path-based rules. With the default requirement, the Host header must be the host of the route without its last labels, such as app: framework.trusted_hosts blocks that, while a web server that only serves known names may not, for instance, Nginx passing the raw Host header to FastCGI for a request line that carries an absolute URI. If the requirement accepts /, such as .+, a real hostname works, and trusted_hosts does not help.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_