EUVD-2026-44369
GHSA-55rj-x2vc-4whq
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from Vendor (https://github.com/symfony/symfony) · only source for this CVE.
CVSS VectorVendor: https://github.com/symfony/symfony
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionCVE.org
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
Symfony would like to thank Himanshu Anand for reporting the issue and Nicolas Grekas for providing the fix.
AnalysisAI
Webhook signature verification is silently skipped in Symfony's Twilio Notifier bridge across symfony/symfony 6.4.x through 8.0.x and symfony/twilio-notifier, even when a signing secret is explicitly configured. TwilioRequestParser::doParse() accepts a secret parameter but contains no code that reads or uses it, meaning every inbound POST to the webhook endpoint is accepted unconditionally regardless of whether the X-Twilio-Signature HMAC header is present or valid. An attacker who can reach the endpoint URL can inject arbitrary forged Twilio status callbacks - fake delivered, failed, or undelivered events - to corrupt delivery metrics or trigger downstream automation. No public exploit code identified at time of analysis; vendor-released patches are available in 6.4.40, 7.4.12, and 8.0.12.
Technical ContextAI
The affected code resides in Symfony's Notifier Bridge for Twilio (CPE: pkg:composer/symfony/twilio-notifier and pkg:composer/symfony/symfony). Twilio's webhook security model requires that each status callback POST be signed using the account auth token: the signature is HMAC-SHA1 over the full request URL concatenated with the POST parameters sorted alphabetically by key, then base64-encoded, transmitted in the X-Twilio-Signature header. TwilioRequestParser::doParse() is the entry point for verifying and decoding these callbacks. CWE-306 (Missing Authentication for Critical Function) describes the root cause precisely: the method signature declares a #[SensitiveParameter] string $secret argument, giving developers and tooling the impression that authentication occurs, but the method body never references the variable - making authentication entirely dead code. The fix introduces a private verifySignature() method that reconstructs the canonical string, computes the expected HMAC, and compares it against the header value using hash_equals() for constant-time comparison to prevent timing side-channels. Applications behind TLS-terminating reverse proxies require additional framework.trusted_proxies and framework.trusted_headers configuration to ensure Request::getUri() returns the public URL that Twilio signed.
RemediationAI
Vendor-released patches are available: upgrade symfony/symfony to 6.4.40, 7.4.12, or 8.0.12 according to your active version branch; the symfony/twilio-notifier standalone package is resolved by upgrading to 6.4.40. The patch commit is at https://github.com/symfony/symfony/commit/8545fb2af6c07dfb5ef0fc8d9bccf86db2c94356. If immediate upgrade is not possible, a compensating control is to restrict the webhook endpoint to Twilio's published outbound IP ranges at the network or web server layer - this reduces the attack surface to network-level access control but requires ongoing maintenance as Twilio updates its infrastructure, and provides no protection against an attacker operating from a Twilio IP. After upgrading, applications deployed behind a TLS-terminating reverse proxy must configure framework.trusted_proxies and framework.trusted_headers to ensure that Request::getUri() returns the public URL Twilio signed; failure to do so will cause the patched parser to reject all legitimate Twilio callbacks with a signature mismatch, breaking webhook functionality.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today