Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN531 _____________________________________________________________________ DATE : 21/05/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running symfony/symfony, symfony/runtime, symfony/twilio-notifier, symfony/json-path, symfony/mailtrap-mailer, symfony/lox24-notifier, symfony/mailjet-mailer, symfony/html-sanitize, symfony/monolog-bridge, symfony/mime, symfony/cache, symfony/routing, symfony/http-kernel, symfony/security-http, symfony/twig-bridge, symfony/web-profiler-bundle, symfony/yaml. ===================================================================== https://github.com/symfony/symfony/security/advisories/GHSA-fqc7-9xjw-jrh3 https://github.com/symfony/symfony/security/advisories/GHSA-m7v2-7gxm-vc2v https://github.com/symfony/symfony/security/advisories/GHSA-ph86-p8f6-f9r2 https://github.com/symfony/symfony/security/advisories/GHSA-xx3c-qf5g-hc39 https://github.com/symfony/symfony/security/advisories/GHSA-j8gj-9rm5-4xhx https://github.com/symfony/symfony/security/advisories/GHSA-29fc-p6c4-24cg https://github.com/symfony/symfony/security/advisories/GHSA-55rj-x2vc-4whq https://github.com/symfony/symfony/security/advisories/GHSA-8v8v-g73j-492j https://github.com/symfony/symfony/security/advisories/GHSA-59f3-vp2f-mp9w https://github.com/symfony/symfony/security/advisories/GHSA-64hg-93w9-fc35 https://github.com/symfony/symfony/security/advisories/GHSA-vqc8-7275-q272 https://github.com/symfony/symfony/security/advisories/GHSA-h5vq-qfcg-4m6p https://github.com/symfony/symfony/security/advisories/GHSA-6qh9-h6wf-jgqc https://github.com/symfony/symfony/security/advisories/GHSA-72xp-p242-47p9 https://github.com/symfony/symfony/security/advisories/GHSA-6439-2f28-8p8q https://github.com/symfony/symfony/security/advisories/GHSA-qc95-4862-92fh https://github.com/symfony/symfony/security/advisories/GHSA-qpmx-3rfj-7rhv https://github.com/symfony/symfony/security/advisories/GHSA-4qpc-3hr4-r2p4 _____________________________________________________________________ SymfonyRuntime CVE-2024-50340 Patch Bypass: Web Requests Can Still Set APP_ENV/APP_DEBUG via parse_str/SAPI Argv Mismatch High nicolas-grekas published GHSA-fqc7-9xjw-jrh3 May 20, 2026 Package symfony/runtime (Composer) Affected versions >=5.4.46, <5.4.52 >=6.4.14, <6.4.40 >=7.1.7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions >=5.4.46, <5.4.52 >=6.4.14, <6.4.40 >=7.1.7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 Description Description CVE-2024-50340 (GHSA-x8vp-gf4q-mw5j) addressed an issue where, with register_argc_argv=On, a crafted query string let an unauthenticated GET change the kernel environment and debug flag by feeding --env/--no-debug through $_SERVER['argv']. The fix shipped in symfony/runtime 5.4.46 / 6.4.14 / 7.1.7 gated the argv read on empty($_GET) as a proxy for "is this a CLI invocation". That proxy is unsafe: parse_str() (which builds $_GET) and the web SAPI (which builds $_SERVER['argv'] from the raw query when register_argc_argv=On) do not agree on every input, so an attacker can craft a query that leaves $_GET empty while $_SERVER['argv'] carries the attacker's flags. SymfonyRuntime::getInput() then parses them, restoring the exact primitive CVE-2024-50340 was meant to prevent. Preconditions and impact match the original CVE: web SAPI, register_argc_argv=On, app booted through symfony/runtime; from an unauthenticated GET an attacker can flip APP_ENV and toggle APP_DEBUG. Resolution SymfonyRuntime now gates the argv read on isset($_SERVER['QUERY_STRING']) rather than on empty($_GET). QUERY_STRING is the same input the SAPI uses to build argv, so the security check and the thing it protects no longer parse different sources. Worker SAPIs (FrankenPHP / RoadRunner / Swoole) keep working because the runtime constructor runs once at boot when QUERY_STRING is unset. The patch for this issue is available here for branch 5.4. Credits We would like to thank 0xEr3n for reporting the issue and Nicolas Grekas for providing the fix. Severity High CVE ID CVE-2026-46626 Weaknesses Weakness CWE-436 Credits @nicolas-grekas nicolas-grekas Remediation developer @0xEr3n 0xEr3n Reporter _____________________________________________________________________ Unauthenticated PHP Object Deserialization in MonologBridge server:log Listener High nicolas-grekas published GHSA-m7v2-7gxm-vc2v May 20, 2026 Package symfony/monolog-bridge (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 Description Description Symfony\Bridge\Monolog\Command\ServerLogCommand (the server:log console command) is a development-time helper that opens a TCP listener and displays log records pushed to it by the application's logging pipeline. Two unsafe defaults combine into a remotely reachable PHP object-deserialization sink: The listener binds to 0.0.0.0:9911 by default; it accepts connections on every interface, not only loopback. Each received frame is processed as unserialize(base64_decode($message)) without an allowed_classes allowlist, without authentication, and without any integrity check. The decoded value is then passed to displayLog(..., array $record) which assumes (without validating) that the result is an array. Any host that can reach TCP port 9911 on a machine running server:log can therefore submit attacker-chosen serialized PHP payloads. The minimum impact is an unauthenticated denial of service (sending a non-array, e.g. serialize(new stdClass()), crashes the listener with a type error). Object injection with magic-method side effects (__wakeup() / __destruct() / etc.) is reachable before the array type-check fires; full remote code execution is environment-dependent and contingent on usable gadget chains in the autoload set of the target process. Resolution The server:log command no longer binds to all interfaces by default: the default --host is now 127.0.0.1:9911, requiring explicit opt-in to accept off-host traffic. Message decoding is gated by an unserialize() allowlist restricted to the Symfony\Component\VarDumper\Caster\* and Symfony\Component\VarDumper\Cloner\* classes that legitimately appear inside dumped log records; any other class is rejected and the record discarded. The patch for this issue is available here for branch 5.4. Credits We would like to thank Toàn Thắng and Sam Sanoop for reporting the issue and Nicolas Grekas for fixing it. Severity High CVE ID CVE-2026-45077 Weaknesses Weakness CWE-502 Weakness CWE-668 Credits @snoopysecurity snoopysecurity Reporter @nicolas-grekas nicolas-grekas Remediation developer @a-tt-om a-tt-om Reporter _____________________________________________________________________ Identity Spoofing via Unanchored DN Regex in X509Authenticator High nicolas-grekas published GHSA-ph86-p8f6-f9r2 May 20, 2026 Package symfony/security-http (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected version <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 Description Description X509Authenticator implements client-certificate (mTLS) authentication: the web server validates the client's certificate against a trusted CA, then passes the certificate's Subject DN (Distinguished Name: a string like CN=Alice,O=Example,emailAddress=alice@example.com) to Symfony via $_SERVER['SSL_CLIENT_S_DN']. Symfony extracts the user identifier from that string. The extraction uses an unanchored regex that matches emailAddress= anywhere in the DN string: including inside the value of a different RDN (Relative Distinguished Name: one key=value component of the DN), such as CN. An attacker who can obtain a certificate from a trusted CA with a free-text CN can smuggle emailAddress=victim@target inside the CN value and be authenticated as the victim. Resolution The X509Authenticator now uses a regex that anchors the match to an RDN boundary (start of string, or following a , / / separator). The patch for this issue is available here for branch 5.4. Credits We would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix. Severity High CVE ID CVE-2026-45063 Weaknesses Weakness CWE-290 _____________________________________________________________________ Argument Injection in SendmailTransport via Dash-Prefixed Recipient Address High nicolas-grekas published GHSA-xx3c-qf5g-hc39 May 20, 2026 Package symfony/mailer (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 Description Description Symfony Mailer selects a transport via the MAILER_DSN environment variable / configuration (e.g. smtp://..., sendmail://..., native://default). SendmailTransport invokes the local sendmail binary and supports two modes: -bs (speak SMTP over stdin: the default) and -t (read the message on stdin, pass recipients as command-line arguments). In -t mode, recipient addresses are appended to the sendmail command line without a -- end-of-options separator. A recipient address beginning with - (which Symfony\Component\Mime\Address accepts as valid) is therefore interpreted by sendmail as a command-line option rather than an address. Resolution The SendmailTransport transport now ensure -- is set before the list of recipients. The patch for this issue is available here for branch 5.4. Credits We would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix. Severity High CVE ID CVE-2026-45068 Weaknesses Weakness CWE-88 _____________________________________________________________________ Cas2Handler Derives CAS service URL from Client Host Header → Cross-Service Ticket Replay High nicolas-grekas published GHSA-j8gj-9rm5-4xhx May 20, 2026 Package symfony/security-http (Composer) Affected versions >=7.1, <7.4.12 >=8, <8.0.12 Patched versions 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions >=7.1, <7.4.12 >=8, <8.0.12 Patched versions 7.4.12 8.0.12 Description Cas2Handler builds this service parameter from Request::getSchemeAndHttpHost(), which reflects the attacker-controlled HTTP Host header whenever Symfony's framework.trusted_hosts setting is not configured (the default). An attacker who controls any other application registered with the same CAS server can replay a victim's ticket against the Symfony application, with a spoofed Host header, and be authenticated as that victim. Resolution A new required service_url configuration option is introduced on Cas2Handler. The CAS service parameter sent to the validation endpoint is now built from this configured URL instead of being derived from the request's Host header, preventing cross-service ticket replay via Host header spoofing. The patch for this issue is available here for branch 7.4. Credits We would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Nicolas Grekas for providing the fix. Severity High CVE ID CVE-2026-45074 Weaknesses Weakness CWE-290 Credits @nicolas-grekas nicolas-grekas Remediation developer _____________________________________________________________________ OidcTokenHandler Accepts JWTs Missing aud/iss/exp Claims High nicolas-grekas published GHSA-29fc-p6c4-24cg May 20, 2026 Package symfony/security-http (Composer) Affected versions >=6.3, <6.4.40 >=7.4, <7.4.12 >=8, <8.0.12 Patched versions 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions >=6.3, <6.4.40 >=7.4, <7.4.12 >=8, <8.0.12 Patched versions 6.4.40 7.4.12 8.0.12 Description Description OidcTokenHandler is Symfony's built-in access-token handler for OpenID Connect: it validates a bearer JWT and returns the authenticated user identity. It delegates claim validation to the web-token/jwt-checker library's ClaimCheckerManager. OidcTokenHandler::verifyClaims() registers audience (aud), issuer (iss), and expiry (exp) checkers, but never passes the $mandatoryClaims argument to ClaimCheckerManager::check(). That method only validates claims that are present in the token: a checker for an absent claim is silently skipped. A validly-signed JWT that simply omits aud, iss, and exp therefore passes verification. Resolution The OidcTokenHandler now calls the ClaimCheckerManager with the list of mandatory claims so that tokens missing aud, iss, or exp are rejected. The patch for this issue is available here for branch 6.4. Credits We would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix. Severity High CVE ID CVE-2026-45069 Weaknesses Weakness CWE-345 Weakness CWE-1287 _____________________________________________________________________ Twilio Notifier Webhook Parser Never Verifies the X-Twilio-Signature HMAC: Unauthenticated Webhook Event Injection Moderate nicolas-grekas published GHSA-55rj-x2vc-4whq May 20, 2026 Package symfony/symfony (Composer) Affected versions >=6.4, <6.4.40 >=7.0, <7.4.12 >=8.0, <8.0.12 Patched versions 6.4.40 7.4.12 8.0.12 symfony/twilio-notifier (Composer) Affected versions >=6.4, <6.4.40 >=7.0, <7.4.12 >=8.0, <8.0.12 Patched versions 6.4.40 7.4.12 8.0.12 Description Description The Twilio SMS notifier bridge ships a webhook request parser used to authenticate and decode the status callbacks Twilio POSTs to an application's webhook endpoint. Its doParse(Request $request, #[\SensitiveParameter] string $secret) method receives the configured webhook secret but never reads it; it decodes and returns the payload unconditionally, ignoring the X-Twilio-Signature HMAC header Twilio sends with each request. As a result, an application that wires up the Twilio webhook endpoint accepts any POST to that URL, even when a signing secret is configured (the recommended setup). An attacker who knows the endpoint exists can submit forged status payloads, fake delivered / failed / undelivered events, leading to delivery-metrics fraud, downstream automation triggers, etc. Resolution TwilioRequestParser::doParse() now requires and verifies the X-Twilio-Signature header (HMAC-SHA1 over the full request URL concatenated with the alphabetically-sorted POST parameters, base64-encoded, keyed with the Twilio account auth token) before further processing, using a constant-time comparison. When no secret is configured the behaviour is unchanged: signature verification remains opt-in, but it is now actually enforced once opted in. Applications behind a TLS-terminating reverse proxy must configure framework.trusted_proxies and framework.trusted_headers so that Request::getUri() returns the public URL Twilio signed. The patch for this issue is available here for branch 6.4. Credits We would like to thank Himanshu Anand for reporting the issue and Nicolas Grekas for providing the fix. Severity Moderate CVE ID CVE-2026-47212 Weaknesses Weakness CWE-306 Weakness CWE-347 Credits @nicolas-grekas nicolas-grekas Remediation developer _____________________________________________________________________ JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits: ReDoS Moderate nicolas-grekas published GHSA-8v8v-g73j-492j May 20, 2026 Package symfony/json-path (Composer) Affected versions >=7.3, <7.4.12 >=8.0, <8.0.12 Patched versions 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions >=7.3, <7.4.12 >=8.0, <8.0.12 Patched versions 7.4.12 8.0.12 Description Description The JsonPath component's match() and search() filter functions compile a caller-supplied pattern straight into preg_match(): 'match' => @preg_match(\sprintf('/^%s$/u', $this->transformJsonPathRegex($argList[1])), $value), 'search' => @preg_match("/{$this->transformJsonPathRegex($argList[1])}/u", $value), transformJsonPathRegex() only performs cosmetic escaping: there is no length cap, no restriction to the RFC 9485 i-regexp subset, and no bound on backtracking. An application that evaluates an attacker-influenced JSONPath expression server-side (e.g. one taken from a query parameter or API field and passed to JsonCrawler) can therefore be made to run a catastrophic-backtracking pattern such as $[?search(@, "(a+)+$")]. Evaluated against a moderately sized document, this pins a CPU core for seconds per request, so a handful of concurrent requests exhausts the worker pool: a denial of service. Because the preg_match() calls are prefixed with @, the PCRE backtrack-limit errors that would otherwise surface are suppressed, leaving no log trace. Conditions for exploitation An application that evaluates an attacker-influenced JSONPath expression containing a match() / search() filter against any non-trivial JSON input. Resolution JsonCrawler runs the preg_match() calls through a helper that lowers pcre.backtrack_limit to 10000 for the duration of the call (restoring the previous value afterwards), so a pathological pattern fails fast instead of stalling the worker. The patch for this issue is available here for branch 7.4. Credits We would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix. Severity Moderate CVE ID CVE-2026-45756 Weaknesses Weakness CWE-400 Weakness CWE-1333 Credits @alexandre-daubois alexandre-daubois Remediation developer _____________________________________________________________________ Mailtrap Mailer Webhook Parser Never Verifies the X-Mt-Signature HMAC: Unauthenticated Webhook Event Injection Moderate nicolas-grekas published GHSA-59f3-vp2f-mp9w May 20, 2026 Package symfony/mailtrap-mailer (Composer) Affected versions >=7.2, <7.4.12 >=8.0, <8.0.12 Patched versions 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions >=7.2, <7.4.12 >=8.0, <8.0.12 Patched versions 7.4.12 8.0.12 Description Description The Mailtrap mailer bridge ships a webhook request parser used to authenticate and decode the event callbacks Mailtrap POSTs to an application's webhook endpoint. Its doParse(Request $request, #[\SensitiveParameter] string $secret) method receives the configured webhook secret but never reads it; it decodes and returns the payload unconditionally, ignoring the X-Mt-Signature HMAC header Mailtrap sends with each request. As a result, an application that wires up the Mailtrap webhook endpoint accepts any POST to that URL, even when a signing secret is configured (the recommended setup). An attacker who knows the endpoint exists can submit forged event payloads, fake delivery / bounce / open / click / spam events, leading to suppression-list corruption, delivery-metrics fraud, etc. Resolution MailtrapRequestParser::doParse() now requires and verifies the X-Mt-Signature header, an HMAC-SHA256 of the raw request body keyed with the configured secret, before decoding the payload, using a constant-time comparison. When no secret is configured the behaviour is unchanged: signature verification remains opt-in, but it is now actually enforced once opted in. The patch for this issue is available here for branch 7.4. Credits We would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois providing the fix. Severity Moderate CVE ID CVE-2026-45755 Weaknesses Weakness CWE-306 Weakness CWE-347 Credits @alexandre-daubois alexandre-daubois Remediation developer _____________________________________________________________________ Mailjet Mailer and LOX24 Notifier Webhook Parsers Never Verify the Configured Secret: Unauthenticated Webhook Event Injection Moderate nicolas-grekas published GHSA-64hg-93w9-fc35 May 20, 2026 Package symfony/lox24-notifier (Composer) Affected versions >=7.1, <7.4.12 >=8.0, <8.0.12 Patched versions 7.4.12 8.0.12 symfony/mailjet-mailer (Composer) Affected versions >=6.4, <6.4.40 >=7.0, <7.4.12 >=8.0, <8.0.12 Patched versions 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions >=6.4, <6.4.40 >=7.0, <7.4.12 >=8.0, <8.0.12 Patched versions 6.4.40 7.4.12 8.0.12 Description Description The Mailjet mailer bridge and the LOX24 SMS notifier bridge both ship webhook request parsers used to authenticate and decode the event callbacks each provider POSTs to an application's webhook endpoint. Their doParse(Request $request, #[\SensitiveParameter] string $secret) methods receive the configured webhook secret but never read it; they convert and return the payload unconditionally. As a result, an application that wires up either webhook endpoint accepts any POST to that URL, even when a webhook secret is configured (the recommended setup). An attacker who knows the endpoint exists can submit forged event payloads, fake bounce / blocked / spam / open / click / delivery events, leading to suppression-list corruption, delivery-metrics fraud, etc. Resolution MailjetRequestParser::doParse() now rejects the request unless it carries the expected HTTP Basic credentials, Mailjet's webhook authentication mechanism, using a constant-time comparison. The configured webhook secret is matched against the credentials embedded in the Mailjet webhook URL as user:password (use :password when the URL has no username). Lox24RequestParser::doParse() now rejects the request unless it carries an X-LOX24-Token HTTP header whose value matches the configured secret, using a constant-time comparison. The same token must be configured in the LOX24 dashboard under the callback settings. When no secret is configured the behaviour is unchanged: webhook authentication remains opt-in, but it is now actually enforced once opted in. The Mailjet patch is available here for branch 6.4. The LOX24 patch is available here for branch 7.4 (the LOX24 bridge was introduced in 7.1 and is not present in 6.4). Credits We would like to thank Himanshu Anand for reporting the issue, and Alexandre Daubois and Nicolas Grekas for providing the fixes. Severity Moderate CVE ID CVE-2026-45754 Weaknesses Weakness CWE-287 Weakness CWE-306 Credits @alexandre-daubois alexandre-daubois Remediation developer @nicolas-grekas nicolas-grekas Remediation developer _____________________________________________________________________ Email Header Injection via Non-Token Characters in Mime Parameter Names Moderate nicolas-grekas published GHSA-vqc8-7275-q272 May 20, 2026 Package symfony/mime (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 Description Description Symfony\Component\Mime\Header\ParameterizedHeader (and the related parameter handling reachable from Symfony\Component\Mime\Header\Headers) is responsible for serializing structured headers such as Content-Type and Content-Disposition, which carry key=value parameters (e.g. Content-Disposition: attachment; filename="x"). RFC 2045 / RFC 5322 require parameter names to be tokens: a restricted ASCII subset that excludes whitespace, CR/LF, and the tspecials set. Symfony's parameter handling validates and properly encodes parameter values, but does not validate parameter names: the supplied name is emitted verbatim into the serialized header. A caller that derives a parameter name from untrusted input, e.g. an application that lets a user influence a Content-Disposition parameter name, can include \r\n or other non-token bytes inside the name, terminating the current header and injecting additional headers in the rendered message. This is the classic CRLF / header-injection primitive applied to the parameter-name slot. Resolution ParameterizedHeader now rejects parameter names that contain bytes outside the RFC token character class. The patch for this issue is available here for branch 5.4. Credits We would like to thank Fabian Fleischer for reporting the issue and Alexandre Daubois for fixing it. Severity Moderate CVE ID CVE-2026-45070 Weaknesses Weakness CWE-93 Credits @alexandre-daubois alexandre-daubois Remediation developer _____________________________________________________________________ HtmlSanitizer URL Attributes Pass Through BiDi Override Characters → Visual href Spoofing Moderate nicolas-grekas published GHSA-h5vq-qfcg-4m6p May 20, 2026 Package symfony/html-sanitizer (Composer) Affected versions >=6.1, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions >=6.1, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 6.4.40 7.4.12 8.0.12 Description Description Symfony\Component\HtmlSanitizer\TextSanitizer\UrlSanitizer::parse() (used by UrlSanitizer::sanitize() and therefore by every HtmlSanitizer config that allows links or media) accepts URLs that contain Unicode explicit-direction BiDi formatting characters: U+202A–U+202E (LRE / RLE / PDF / LRO / RLO) and U+2066–U+2069 (LRI / RLI / FSI / PDI). These characters are passed through unchanged into the href / src attributes produced by HtmlSanitizer. When the resulting HTML is rendered in a browser, the override characters reverse or alter the visual ordering of the URL text, so the displayed link can differ arbitrarily from the actual destination: a classic visual-spoofing / phishing primitive against viewers of sanitized content. Resolution UrlSanitizer::parse() now rejects URLs containing the explicit-direction BiDi formatting code points (U+202A–U+202E, U+2066–U+2069) before invoking the underlying URL parser. As an unrelated companion fix in the same patch, spaces inside path/query/fragment are now percent-encoded rather than rejected outright, while spaces in the scheme/authority remain rejected by the post-encoding whitespace check. The patch for this issue is available here for branch 5.4. Credits We would like to thank Nicolas Grekas for reporting the issue and providing the fix. Severity Moderate CVE ID CVE-2026-45064 Weaknesses Weakness CWE-451 Weakness CWE-1007 Credits @nicolas-grekas nicolas-grekas Remediation developer _____________________________________________________________________ SQL Injection in PdoAdapter::doClear() via Unsanitized $prefix Moderate nicolas-grekas published GHSA-6qh9-h6wf-jgqc May 20, 2026 Package symfony/cache (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 Description Description Symfony\Component\Cache\Adapter\PdoAdapter is the PDO-backed cache adapter. Its clear($prefix) method (inherited from AbstractAdapterTrait) is documented to delete cache items whose key starts with $prefix. In the non-versioning code path, the caller-supplied $prefix is concatenated into $namespace = $this->namespace.$prefix and passed to PdoAdapter::doClear(), which builds: DELETE FROM WHERE LIKE '%' The value is interpolated directly into the SQL text and executed with PDO::exec(): $namespace is not bound. A caller able to influence $prefix can break out of the literal and inject SQL, expanding deletion scope from the intended prefix to arbitrary rows, or otherwise reshape query semantics. Most applications don't expose clear($prefix) to untrusted input directly, but the contract of the method is to safely accept any prefix string, so the lack of escaping is a defect of the adapter itself. Resolution AbstractAdapterTrait::clear() now rejects any $prefix containing characters outside [-+.A-Za-z0-9]: when an invalid prefix is supplied, the method logs a warning and returns false instead of reaching the SQL layer. This blocks quotes, %, null bytes and other characters that would let an attacker break out of the LIKE literal. The patch for this issue is available here for branch 5.4. Credits We would like to thank secsys_codex for reporting the issue and Nicolas Grekas for fixing it. Severity Moderate CVE ID CVE-2026-45073 Weaknesses Weakness CWE-89 Credits @FORIMOC FORIMOC Finder @nicolas-grekas nicolas-grekas Remediation developer _____________________________________________________________________ UrlGenerator Route-Requirement Bypass via Unanchored Regex Alternation → Off-Site //host URL Injection Moderate nicolas-grekas published GHSA-72xp-p242-47p9 May 20, 2026 Package symfony/routing (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 Description Description Symfony routes can declare a requirements regex per path parameter, e.g. a route /{_locale}/blog with requirements: { _locale: 'en|fr|de' }. The Twig path() / url() helpers (backed by UrlGenerator) validate supplied parameter values against that regex before building the URL. UrlGenerator constructs the validation pattern as '#^'.$req.'$#', where $req is the raw requirement string. For a requirement expressed as an alternation, e.g. _locale: 'ar|bg|...|vi|...|zh_CN' (very common), ^ and $ anchor only the first and last alternatives, so any middle alternative matches as an unanchored substring. A value like /evil.com satisfies the requirement (because it contains vi), and the generated path becomes //evil.com/...: a protocol-relative URL the browser navigates off-site. Resolution The UrlGenerator class now wraps the requirement in a non-capturing group so the ^ and $ anchors apply to the whole alternation. The patch for this issue is available here for branch 5.4. Credits We would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix. Severity Moderate CVE ID CVE-2026-45065 Weaknesses Weakness CWE-185 Weakness CWE-601 _____________________________________________________________________ HEAD Request Bypasses methods: ['GET'] Filter in #[IsGranted] / #[IsSignatureValid] / #[IsCsrfTokenValid] Moderate nicolas-grekas published GHSA-6439-2f28-8p8q May 20, 2026 Package symfony/http-kernel (Composer) Affected versions >=7.4, <7.4.12 >=8, <8.0.12 Patched versions 7.4.12 8.0.12 symfony/security-http (Composer) Affected versions >=7.4, <7.4.12 >=8, <8.0.12 Patched versions 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions >=7.4, <7.4.12 >=8, <8.0.12 Patched versions 7.4.12 8.0.12 Description Description Symfony's #[IsGranted('...')], #[IsSignatureValid], and #[IsCsrfTokenValid(...)] attributes allow you to define a methods: [...] argument to only enforce these checks for the listed HTTP methods and skip them otherwise. E.g. an attribute defining methods: ['GET'] would be ignored for a HEAD request. On the other hand, Symfony's router (and HTTP semantics generally) serves HEAD requests using the GET handler. Therefore, a controller protected by e.g. #[IsGranted('ROLE_ADMIN', methods: ['GET'])] can be reached via HEAD with the authorization check silently skipped. Even if the HEAD request won't get any response content, response headers leak (Content-Length, Location, custom headers). Also, the controller still executes and any side effects (DB writes, state changes) occur. Resolution When adding GET in the methods option of these attributes, Symfony now also include the HEAD method automatically. The patch for this issue is available here for branch 7.4. Credits We would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Alexandre Daubois for fixing it. Severity Moderate CVE ID CVE-2026-45075 Weaknesses Weakness CWE-863 Credits @alexandre-daubois alexandre-daubois Remediation developer _____________________________________________________________________ HtmlSanitizer allowLinkHosts() / allowMediaHosts() Bypass via URL-Parser Differentials and Misclassification Moderate nicolas-grekas published GHSA-qc95-4862-92fh May 20, 2026 Package symfony/html-sanitizer (Composer) Affected versions >=6.1, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions >=6.1, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 6.4.40 7.4.12 8.0.12 Description Description symfony/html-sanitizer lets applications sanitise untrusted HTML. The configuration methods allowLinkHosts([...]) and allowLinkSchemes([...]) are intended to restrict targets to an allowlist of hosts/schemes; allowMediaHosts() / allowMediaSchemes() do the same for etc. Three distinct bypasses allow a content author to smuggle off-allowlist URLs past these checks. First, UrlSanitizer::parse() parses the input following RFC-3986, while browsers follow the WHATWG URL Standard which normalises \ to / before parsing the authority of "special" schemes; so an input like https://evil\@trusted.com/ parses with host trusted.com server-side but navigates to https://evil/ in the browser. Second, WHATWG collapses any run of / after the scheme into //, while RFC-3986 does not; so https:/evil.com/ and https:///evil.com/ parse as host-less (skipping the host allowlist) but resolve to evil.com in the browser. Third, UrlAttributeSanitizer checks 'a' === $element to route to the link policy and falls through to the media policy otherwise, but is a navigable hyperlink equivalent to ; so was sanitised against the media policy (which typically allows data: and may have no host allowlist), bypassing allowLinkHosts() / allowLinkSchemes() entirely. Resolution UrlSanitizer::sanitize() now rejects URLs that contain a backslash or that use a special scheme (http, https, ftp, ws, wss) followed by a single slash or three slashes before parsing, eliminating the parser-differential bypasses. UrlAttributeSanitizer now applies the link policy to both and elements. The patch for this issue is available here for branch 5.4. Credits We would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix. Severity Moderate CVE ID CVE-2026-45066 Weaknesses Weakness CWE-184 Weakness CWE-436 _____________________________________________________________________ Email Header / SMTP Command Injection via CRLF in Symfony\Component\Mime\Address Moderate nicolas-grekas published GHSA-qpmx-3rfj-7rhv May 20, 2026 Package symfony/mime (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 symfony/symfony (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 Description Description Symfony\Component\Mime\Address is the value-object every Symfony Mailer address (to/cc/bcc/from/reply-to) flows through; its constructor is documented as validating the address and throwing on invalid input, so developers treat it as a security boundary. The constructor accepts email addresses whose local-part (the part before @) is an RFC-5322 quoted string containing raw \r\n bytes, e.g. "x\r\nBcc: attacker@evil"@example.com. The stored address is later emitted verbatim into (1) the rendered message headers and (2) SmtpTransport's MAIL FROM:<...> / RCPT TO:<...> protocol lines, turning the embedded CRLF into a new mail header and/or a new SMTP command. Resolution The Address constructor now rejects addresses containing line breaks. The patch for this issue is available here for branch 5.4. Credits We would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix. Severity Moderate CVE ID CVE-2026-45067 Weaknesses Weakness CWE-93 _____________________________________________________________________ YAML Parser Exponential Memory Allocation via Recursive Collection-Alias Expansion ("Billion Laughs") Low nicolas-grekas published GHSA-4qpc-3hr4-r2p4 May 20, 2026 Package symfony/symfony (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 symfony/yaml (Composer) Affected versions <5.4.52 >=6, <6.4.40 >=7, <7.4.12 >=8, <8.0.12 Patched versions 5.4.52 6.4.40 7.4.12 8.0.12 Description Description Symfony\Component\Yaml\Parser resolves YAML aliases (*anchor) during parsing. Aliases that reference collections (arrays, stdClass, TaggedValue-wrapped collections) can themselves point to other collections containing aliases, creating exponential expansion at resolution time. A small input can blow up into a multi-gigabyte structure and exhaust memory: the classic "Billion Laughs" denial-of-service against any parser exposed to untrusted YAML. Resolution The Parser now counts collection alias resolutions in a shared ParserState object, with a default limit of 128, following the SnakeYAML model. Scalar aliases remain unrestricted since they cannot drive exponential growth. The limit is configurable via a new $maxAliasesForCollections argument on Parser::__construct(), Yaml::parse() and Yaml::parseFile(). A new Yaml::PARSE_EXCEPTION_ON_ALIAS flag also rejects all aliases outright when parsing fully untrusted input. The patch for this issue is available here for branch 5.4. Credits We would like to thank Pietro Tirenna (Shielder) for reporting the issue and Nicolas Grekas for fixing it. Severity Low CVE ID CVE-2026-45304 Weaknesses Weakness CWE-776 ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================