Nicolas Grekas

The Symfony Security HTTP component contains an issue where the `authenticateUser()` function in `AuthenticatorManager` fails to execute the `checkPostAuth()` method of the firewall user checker during programmatic authentication. This occurs because `authenticateUser()`—which is utilized by `UserAuthenticatorInterface::authenticateUser()` and `Security::login()`—does not dispatch the `security.authentication.success` event required for `checkPostAuth()` to run. Consequently, users with accounts that should be rejected by a custom user checker (such as expired accounts) can still obtain an authenticated session if they are authenticated programmatically, such as through email verification links or password resets, even though they would be blocked by standard form logins.

The Symfony Config component is susceptible to XML External Entity (XXE) injection. This occurs because the `XmlUtils::parse()` function enables DTD validation by setting `$dom->validateOnParse = true` before calling `loadXML()`, and only rejects documents with a doctype afterward. Consequently, libxml resolves external entities during the loading process. While `LIBXML NONET` blocks `http://` requests, it does not block `file://` requests, allowing a remote attacker to supply a crafted XML document to determine if local files exist or cause a denial of service by pointing to large or slow files. Additionally, if a network-capable stream wrapper like `s3://` is registered, a parameter entity could be used to exfiltrate local file content to an external server. Applications are affected when untrusted XML is passed directly to the `XmlUtils::parse()` function.

The Symfony Serializer component `ObjectNormalizer` incorrectly treats attribute names containing `.` (and `[` starting from version 6.4) as writable property paths. This allows untrusted input to modify properties of nested objects, bypassing the `#[Ignore]` metadata attribute. The issue occurs because `ObjectNormalizer::isAllowedAttribute()` accepts these names, and `setAttributeValue()` passes them to `PropertyAccessor::setValue()`, which parses the name as a path to traverse into nested objects. For example, a payload key like `customer.admin` can write to `$order->customer->admin`. Additionally, since `PropertyAccessor` resolves path segments against public methods, a segment matching a public method name can trigger that method with an attacker-supplied value. This affects applications binding untrusted input to objects, such as controllers using `#[MapRequestPayload]` or `#[MapQueryString]`. When using `OBJECT TO POPULATE` for partial updates, the traversal can reach a hydrated entity graph, potentially leading to the persistence of modified fields.

The `DataUriNormalizer::denormalize()` function in the Symfony Serializer component uses a case-sensitive regular expression to match the `data:` scheme. This allows an attacker to use an uppercase scheme, such as `DATA:`, to bypass the check. Consequently, the input is treated as a local file path rather than inline data, leading to Arbitrary Local File Read through Path Traversal. This occurs when the application deserializes untrusted input into `File`, `SplFileInfo`, or `SplFileObject` types. Any endpoint performing this deserialization is affected, and a single request with a crafted value can read local files accessible to the application without requiring authentication if the endpoint is public.

The Symfony Serializer component contains an issue where the `DataUriNormalizer` only handles specific types, causing the `ObjectNormalizer` to instantiate subclasses like `UploadedFile` using attacker-controlled data via the constructor. This allows an arbitrary file on the server to be treated as an uploaded file. An attacker can send a request body containing a `path` variable to point to sensitive files, such as `.env.local`. By setting a `test` variable to `true`, the `UploadedFile::isValid()` function skips the `is uploaded file()` check, and the `move()` function reverts to `rename()`. This can lead to the exposure of any file readable by PHP, the unauthorized moving of files, or the confirmation of a file's existence on the server. The issue affects any code deserializing untrusted data into a type with such a property, including the use of `#[MapRequestPayload]` on a DTO with an `UploadedFile` property.

The Inline and Parser components of the Symfony Yaml component process certain YAML documents inefficiently. A specially crafted document can cause a PHP process to remain busy for extended periods, potentially leading to a denial of service. This occurs because the parser repeats work in several areas: embedded mappings in flow sequences are re-parsed for every appended scalar, causing exponential growth in parse time relative to nesting depth; mapping keys and tags scan spaces per character; and scalars in flow collections are matched against copies of the remaining collection, resulting in quadratic growth relative to input size. Additionally, nested blocks are copied at each level, consuming memory and time. Other triggers include empty sequence items followed by blank lines or anchors named `0`. Any code parsing untrusted YAML with default flags is affected. In versions 7.4 and later, this includes the `#[MapRequestPayload]` attribute when the Yaml component is installed and the endpoint does not restrict `acceptFormat`. In version 6.4, `#[MapRequestPayload]` is affected if the application registers a yaml request format.

Improper trust of forwarded headers in the `onKernelFinishRequest()` function of `RouterListener` allows a remote attacker to control the host, scheme, and port of absolute URLs generated for the remainder of a request. This occurs when a page renders an inline fragment via `render()` in Twig or an inline ESI tag; the `SubRequestHandler` temporarily adds 127.0.0.1 to trusted proxies, causing `RouterListener` to trust `X-Forwarded-*` and `Forwarded` headers from requests with a client address of 127.0.0.1, even if not explicitly configured. Consequently, absolute URLs produced by `url()` in Twig and `UrlGeneratorInterface::ABSOLUTE URL` can be manipulated, potentially poisoning links in shared caches or emails. This issue affects applications reached over HTTP from 127.0.0.1, such as those behind a TLS terminator, reverse proxy, local HTTP cache, or sidecar proxy on the same host that forwards client headers. If `framework.trusted hosts` is configured, hosts outside the list are rejected, but the scheme and port remain mutable.

`SymfonyComponentHttpFoundationRequestMatcher` and `RequestMatcherMethodRequestMatcher` (used from version 6.2.x onwards) perform verbatim comparisons when matching a request against a list of HTTP methods. Because HTTP semantics require the router to serve a HEAD request using the GET handler, security rules restricted to GET requests can be bypassed by sending a HEAD request to the same URL. This allows attackers to trigger controller execution and its side effects, as well as access response headers. This issue also impacts firewalls configured with `methods: [GET]`, as a HEAD request may bypass the intended firewall and be handled by another or none at all. Applications utilizing these request matchers directly or via a custom `request matcher` are also affected.

The `IpValidator` in the Symfony Validator component incorrectly classifies certain internal addresses as public when using filtered modes of the `Ip` constraint. This occurs because the validator relies on PHP flags `FILTER FLAG NO PRIV RANGE` and `FILTER FLAG NO RES RANGE`, which fail to account for shared address space (100.64.0.0/10) and specific IPv6 formats, such as IPv4-mapped, IPv4-compatible, and 6to4 addresses. Consequently, an internal address like `::ffff:127.0.0.1` may pass validation. This flaw can lead to Server-Side Request Forgery (SSRF), a condition where an attacker induces the server to make requests to an internal resource.

The `NoPrivateNetworkHttpClient` in the Symfony HttpClient component fails to pin the checked IP address of cached hosts. This allows for DNS rebinding, a technique where a DNS server changes the IP address associated with a domain name between requests, to bypass private network restrictions. The component resolves the host and checks the IP before connecting, but it only passes the `resolve` option on the first lookup. On subsequent requests, the decorated client resolves the host independently. An attacker controlling the DNS can provide a public IP for the first request and a private IP for later requests, enabling the enumeration of internal hosts and ports. This occurs because the connection is established before the `primary ip` check in the `on progress()` callback aborts the request, and the resulting error varies based on whether the port is open or closed.

The Symfony HtmlSanitizer component `UrlSanitizer` parses URLs using the RFC 3986 standard via league/uri, which differs from the WHATWG URL standard used by browsers. This discrepancy allows the `allowLinkHosts()` and `allowMediaHosts()` checks to be bypassed when URLs lack a well-formed authority (e.g., http:evil.example, ///evil.example, or https://://evil.example/). In such cases, the sanitizer fails to identify a host, while browsers resolve them to the intended host, leading to untrusted hosts being included in the sanitized output. This issue is exploitable when a host allow-list is used in conjunction with `allowRelativeLinks(true)` or `allowRelativeMedias(true)`.

The Symfony HtmlSanitizer component does not apply the media URL policy to the srcset and imagesrcset attributes, allowing values that point to hosts or schemes not permitted by allowMediaSchemes() or allowMediaHosts() to bypass it, so that browsers load images from disallowed hosts in Symfony versions 6.1.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11.The srcset attribute on img and source elements and the imagesrcset attribute on link elements are allowed by the sanitizer, but their URL candidates are never validated, so their values are kept verbatim while the same URL in src is dropped. The fixes for CVE-2026-45753 and CVE-2026-48761 extended the same attribute list but did not cover these two attributes. For example, with allowMediaSchemes(['https']) and allowMediaHosts(['trusted.example']), <img srcset="https://evil.example/a.png 1x"> survives sanitization, and the browser fetches the selected candidate as it would fetch src. Candidates with a scheme forbidden by the configuration, such as http, are kept as well. Any application that sanitizes untrusted HTML and relies on the media schemes and hosts allowlists to restrict where images can be loaded from is affected. A single crafted value is enough to make the browser of a user viewing the sanitized content send a request to an attacker-controlled host, which can be used to track viewers or log their IP addresses. No authentication is needed if the application accepts HTML from unauthenticated users.

An authentication bypass exists in `X509Authenticator` and `X509AuthenticationListener` where an attacker possessing a certificate from a trusted CA can authenticate as an arbitrary user, including privileged accounts, by influencing the Common Name (CN). The issue stems from an incomplete fix where the regular expression used to extract user identifiers from the Subject DN (Distinguished Name) passed in `$ SERVER['SSL CLIENT S DN']` was not escape-aware. Consequently, the system fails to distinguish between actual RDN (Relative Distinguished Name) separators and separator characters contained within a value. Under RFC 2253, escaped commas are incorrectly read as separators, and bare slashes are treated as separators. In the legacy `X509 NAME oneline()` format, bare commas are treated as separators. This allows a poisoned CN to smuggle a different user address for authentication.

The `ScopingHttpClient` component in Symfony HttpClient merges default scope options, such as `auth bearer` or `auth basic`, into a request before resolving a relative URL against the `base uri`. This allows a network-path reference to be sent to a different origin while retaining the default scope credentials, potentially disclosing them to an attacker-controlled server. This occurs when the resolved URL falls outside the origin of the base URI, including cases with different ports or user-info on the same host. The issue is reachable if an attacker controls the beginning of a URL passed to a client configured with a `base uri` and credentials, specifically those created via `HttpClient::createForBaseUri()` or configured under `framework.http client.scoped clients`.

The `MetaRefreshAttributeSanitizer` within the Symfony HtmlSanitizer component uses an overly narrow regular expression to sanitize the refresh URL of `content` attributes in `meta` tags. This allows the sanitization process to be bypassed, potentially leading to URL redirection to untrusted sites. The issue occurs because the regular expression fails to account for the WHATWG HTML Standard, where the separator after the time can be ASCII whitespace without a semicolon or comma, and the `url=` keyword is optional. Consequently, certain directives recognized by browsers are returned unchanged, bypassing the `UrlSanitizer` and defeating the `allowLinkSchemes` and `allowLinkHosts` restrictions. This is reachable in configurations that allow `meta` tags with `http-equiv` and `content`, such as the `allowStaticElements()` preset.

In the Symfony Routing components, `CompiledUrlMatcher` and `UrlMatcher` interpret host and path information differently. For routes defining a host, `CompiledUrlMatcher` matches the combined string of `$host`, `.`, and `$pathinfo` against the host and path regular expressions, whereas `UrlMatcher` processes them separately. This discrepancy allows a host placeholder to match a `/` character and consume the start of the path, routing the request to a controller that `UrlMatcher` would not find. Consequently, path-based authorization rules, such as `access control` entries and firewall patterns, are evaluated against the actual request path and may not apply, potentially allowing unauthenticated requests to reach protected controllers. This issue affects applications using routes with host placeholders protected by path-based rules.

The `HeaderUtils::split()` function parses header values using a pattern where a token alternative matches whitespace followed by a lookbehind. When a sequence of whitespace is placed before a separator, the engine attempts to divide the whitespace among iterations in exponentially many ways. This occurs within `HeaderBag` when processing the `Cache-Control` header during Request construction, making any application handling HTTP requests reachable without authentication. A request with a specifically crafted header can cause high CPU consumption; for instance, 17 spaces in an 8 KB header can cost nearly one second of CPU time. When 18 or more spaces are used, `preg match all()` reaches the `pcre.backtrack limit`, causing `split()` to return an empty array and silently drop all header directives.

The parser of the ExpressionLanguage component builds its node tree without a depth limit. An expression containing tens of thousands of nested unary operators, array literals, binary operators, or property accesses can crash the PHP process during the tree freeing process. This can occur when an application validates user-provided expressions via the `ExpressionLanguage::lint()` function, which is utilized by `#[AssertExpressionSyntax]`, allowing a single request to crash the system.

The `YamlParser::lexInlineStructure()` function recurses through `lexInlineMapping()` and `lexInlineSequence()` for every { and [ in an inline collection without respecting the `maxNestingLevel` boundary. A YAML document containing deeply nested inline collections can exhaust the stack during lexing, leading to a process crash or a fatal error depending on the PHP version and stack settings. This issue affects any code parsing untrusted YAML, including the use of `#[MapRequestPayload]` when the Yaml component is installed and the endpoint does not restrict `acceptFormat`, allowing a single unauthenticated request with a YAML content type to trigger the failure.

The issue arises when the filesystem loader loads templates for which the name is a user input. It is possible to use the `source` or `include` statement to read arbitrary files from outside the templates' directory when using a namespace like `@somewhere/../some.file`. In such a case, validation is bypassed.