https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 10:24:32 +0000 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0617 certfr-2026-avi-0617 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0617 https://cve.radiocsirt.org/vuln/euvd-2026-337955 EUVD-2026-337955 https://cve.radiocsirt.org/vuln/euvd-2026-337955 https://cve.radiocsirt.org/vuln/fkie_cve-2026-47212 <p>Symfony is a PHP framework for web and console applications and a set of reusable PHP components. Prior to 6.4.40, 7.4.12, and 8.0.12, TwilioRequestParser::doParse() received the configured webhook secret but ignored the X-Twilio-Signature HMAC header, allowing unauthenticated POST requests to inject forged Twilio status payloads. This issue is fixed in versions 6.4.40, 7.4.12, and 8.0.12.</p> <p>Symfony is a PHP framework for web and console applications and a set of reusable PHP components. Prior to 6.4.40, 7.4.12, and 8.0.12, TwilioRequestParser::doParse() received the configured webhook secret but ignored the X-Twilio-Signature HMAC header, allowing unauthenticated POST requests to inject forged Twilio status payloads. This issue is fixed in versions 6.4.40, 7.4.12, and 8.0.12.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-47212 https://cve.radiocsirt.org/vuln/ghsa-55rj-x2vc-4whq <p><strong>Affected:</strong> Packagist: symfony/symfony, Packagist: symfony/twilio-notifier</p> <p>### Description</p> <p>The Twilio SMS notifier bridge ships a webhook request parser used to authenticate and decode the status callbacks Twilio POSTs to an application&#39;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.</p> <p>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.</p> <p>### Resolution</p> <p>`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.</p> <p>When no secret is configured the behaviour is unchanged: signature verification remains opt-in, but it is now actually enforced once opted in.</p> <p>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.</p> <p>The patch for this…</p> <p><strong>Affected:</strong> Packagist: symfony/symfony, Packagist: symfony/twilio-notifier</p> <p>### Description</p> <p>The Twilio SMS notifier bridge ships a webhook request parser used to authenticate and decode the status callbacks Twilio POSTs to an application&#39;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.</p> <p>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.</p> <p>### Resolution</p> <p>`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.</p> <p>When no secret is configured the behaviour is unchanged: signature verification remains opt-in, but it is now actually enforced once opted in.</p> <p>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.</p> <p>The patch for this…</p> https://cve.radiocsirt.org/vuln/ghsa-55rj-x2vc-4whq https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-47212 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: symfony, Ubuntu:Pro:18.04:LTS: symfony, Ubuntu:Pro:20.04:LTS: symfony, Ubuntu:Pro:22.04:LTS: symfony, Ubuntu:Pro:24.04:LTS: symfony, Ubuntu:25.10: symfony, Ubuntu:26.04:LTS: symfony</p> <p>Symfony is a PHP framework for web and console applications and a set of reusable PHP components. Prior to 6.4.40, 7.4.12, and 8.0.12, TwilioRequestParser::doParse() received the configured webhook secret but ignored the X-Twilio-Signature HMAC header, allowing unauthenticated POST requests to inject forged Twilio status payloads. This issue is fixed in versions 6.4.40, 7.4.12, and 8.0.12.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: symfony, Ubuntu:Pro:18.04:LTS: symfony, Ubuntu:Pro:20.04:LTS: symfony, Ubuntu:Pro:22.04:LTS: symfony, Ubuntu:Pro:24.04:LTS: symfony, Ubuntu:25.10: symfony, Ubuntu:26.04:LTS: symfony</p> <p>Symfony is a PHP framework for web and console applications and a set of reusable PHP components. Prior to 6.4.40, 7.4.12, and 8.0.12, TwilioRequestParser::doParse() received the configured webhook secret but ignored the X-Twilio-Signature HMAC header, allowing unauthenticated POST requests to inject forged Twilio status payloads. This issue is fixed in versions 6.4.40, 7.4.12, and 8.0.12.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-47212