https://vulnfeed.org/Every disclosure, as it lands. Critical-only feed available.enhttps://vulnfeed.org/cve/CVE-2026-118515/https://vulnfeed.org/cve/CVE-2026-118515/Fri, 06 Nov 2026 16:17:01 +0000The Symfony Serializer component DataUriNormalizer handles only the exact types SplFileInfo, SplFileObject, and File, so for a property typed with a subclass such as UploadedFile, ObjectNormalizer instantiates the object through its constructor from attacker-controlled data, including the file path. This allows an arbitrary file on the server to be treated as an uploaded file 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. A request body such as {"image": {"path": "/path/to/project/.env.local", "originalName": "a.png", "test": true}} makes the application handle any file on the server as an upload, without the file being sent. With test: true, UploadedFile::isValid() skips is_uploaded_file() and move() falls back to rename(). Assert\File does not prevent this because it validates the file at the attacker-chosen path, which exists on the server. Any code that deserializes untrusted data into a type that holds such a property is affected. That includes #[MapRequestPayload] on a DTO with an UploadedFile property, which is how uploads are mapped in Symfony 8.1; a single unauthenticated request with a JSON or form body is enough. Depending on what the application does with the upload, this can expose any file readable by PHP (for instance, when uploads are stored and served back), move any such file when move() is called, and reveal whether a path exists. A serializer built without DataUriNormalizer ahead of the object normalizer is not protected by the fix; the serializer configured by FrameworkBundle is.https://vulnfeed.org/cve/CVE-2026-121623/https://vulnfeed.org/cve/CVE-2026-121623/Fri, 06 Nov 2026 16:08:32 +0000The Symfony Serializer component DataUriNormalizer::denormalize() matches the data: scheme with a case-sensitive regular expression, allowing a value with an uppercase scheme, such as DATA:,/../../../etc/passwd, to bypass it, resulting in Arbitrary Local File Read through Path Traversal 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. A value whose scheme is not lowercase data: are treated as a local file path and opened instead of being decoded as inline data, so the resulting File, \SplFileInfo, or \SplFileObject points at a file on the server, which the application then handles as the uploaded content. Any endpoint that deserializes untrusted input into one of these types is affected. FrameworkBundle registers DataUriNormalizer ahead of ObjectNormalizer by default. A single request with a crafted DATA: value is enough to read arbitrary local files that the application can access, with no authentication needed if the endpoint is public.https://vulnfeed.org/cve/CVE-2026-123792/https://vulnfeed.org/cve/CVE-2026-123792/Fri, 06 Nov 2026 15:19:58 +0000The Symfony Yaml components Inline and Parser, parse some YAML documents inefficiently, so that a small crafted document can take disproportionately long to process, keeping a PHP process busy for seconds or minutes, potentially causing a denial of service 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. The parser repeats work it has already done in several places. An embedded mapping in a flow sequence is parsed again for every scalar appended to it, and so are the collections nested in it, so the parse time grows exponentially with the nesting depth. The patterns matching mapping keys and tags scan a run of spaces once per character of the run, and each scalar of a flow collection is matched against a copy of the rest of the collection, so the parse time grows quadratically with the size of the input. Nested blocks are also copied at each nesting level, which consumes memory as well as time. A few other constructs, such as an empty sequence item followed by a blank line or an anchor named 0, trigger similar repeated work. Any code parsing untrusted YAML is affected, with the default flags. In Symfony 7.4 and later, that includes #[MapRequestPayload] when the Yaml component is installed and the endpoint does not restrict acceptFormat. A single unauthenticated request with a YAML content type keeps a PHP worker busy until max_execution_time. JSON documents are valid YAML, so a JSON payload sent with a YAML content type is enough for the flow collection case. In Symfony 6.4, #[MapRequestPayload] accepts YAML only when the application registers a yaml request format.https://vulnfeed.org/cve/CVE-2026-121971/https://vulnfeed.org/cve/CVE-2026-121971/Wed, 04 Nov 2026 17:43:34 +0000The component ScopingHttpClient in Symfony HttpClient merges the options of its default scope (such as auth_bearer or auth_basic) into a request before resolving a relative URL against the base_uri, allowing a network-path reference such as "//evil.example/steal" to be sent to another origin together with the default scope’s credentials, and resulting in potential disclosure of those credentials to an attacker-controlled server. This affects Symfony in versions 5.x 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. The resolved URL falls outside the origin of the base URI, yet it keeps the merged options, whereas the absolute spelling "https://evil.example/steal" receives none. The same happens with a different port or user-info part on the same host. This is reachable whenever an attacker controls the beginning of a URL passed to a client built with a base_uri and credentials, including those created with HttpClient::createForBaseUri() or configured under framework.http_client.scoped_clients. To solve the issue, after resolving a relative URL against the base URI of the default scope, ScopingHttpClient now compares the scheme and authority of the result with those of the base URI, parsed the way the request is sent.https://vulnfeed.org/cve/CVE-2026-118513/https://vulnfeed.org/cve/CVE-2026-118513/Wed, 04 Nov 2026 12:19:53 +0000Authentication bypass by spoofing in X509Authenticator and X509AuthenticationListener of 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 allows an attacker holding a certificate from the application's trusted CA who can influence the CN to authenticate as an arbitrary user of the application, including a privileged one, following an incomplete fix for CVE-2026-45063.X509Authenticator extracts the user identifier from the Subject DN (Distinguished Name) that the web server passes in $_SERVER['SSL_CLIENT_S_DN']. The fix for CVE-2026-45063 anchored that extraction to an RDN (Relative Distinguished Name) boundary, but the regular expression used was not escape-aware. The expression runs against an already serialized DN, so it cannot tell an RDN separator from a separator character that occurs inside a value. Under RFC 2253, used by Apache and by nginx's $ssl_client_s_dn, a comma inside a value is escaped as \, and the expression reads it as a separator regardless. RFC 2253 also does not treat / as a separator, so it leaves it bare inside a value, while the expression treats every / as one. The legacy X509_NAME_oneline() format, used by Apache's LegacyDNStringFormat and by nginx's $ssl_client_s_dn_legacy, is the mirror image: it escapes / as \/ and leaves , bare. In that format, a certificate with no emailAddress attribute, or whose poisoned CN precedes it, authenticates as the smuggled address. To cover both RFC 2253 and the legacy X509_NAME_oneline() format, X509Authenticator and X509AuthenticationListener now split the DN into RDNs before looking for the attribute, instead of matching the attribute against the serialized string. They select the separator from the serialization, split on unescaped occurrences of that separator only, unescape each RDN afterwards with the rules of its format, and require the attribute to span a whole RDN. The accepted value grammar is unchanged. Applications that pass a per-attribute u…