Security Analysis Results

A few days later, and following Symfony's security disclosure process, we received a ZIP file with all their findings. In total, Claude Mythos reported 19 security vulnerabilities in Symfony and Twig codebases. The Symfony Core Team reviewed every report manually, and all 19 findings turned out to be real vulnerabilities, with no false positives.

Each vulnerability was reported in a separate file containing:

• The CWE, affected files, component, and version
• A summary of the problem with the vulnerable code highlighted
• Step-by-step exploitation instructions and impact analysis
• A reproducer
• A suggested fix

We've already fixed every one of these issues in our latest security releases. Details are available in the security advisories blog category.

The Future of Code Security

In 2011, Symfony organized a crowdfunding campaign to pay for an external security audit of Symfony code and, in 2019, Symfony set up a bug bounty program with the support of the European Commission.

In 2026, models like Claude Mythos Preview and initiatives like Project Glasswing are revolutionizing the way code security is audited. Thanks to Anthropic for giving us a chance to be part of it.

We're also grateful to every security researcher who recently reported issues to us, whether using other AI tools or through careful manual review.

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.

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.

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.

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.

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.

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.