Follow-up to the Symfony May Wave — Four Webhook Parsers That Never Verified the Secret (CVE-2026-45754 / -45755 / -47212), Plus the JsonPath ReDoS (CVE-2026-45756)

TL;DR — the 90-second summary

What is the problem? — the same bug in four provider bridges

Up front — the same bug in four bridges

All four webhook parsers share the same signature:

protected function doParse(Request $request, #[SensitiveParameter] string $secret): RemoteEvent

The SensitiveParameter attribute marks $secret as sensitive so its value does not appear in stack traces. That means the configured webhook secret really does reach the method. It was simply never read. doParse() decoded the request and returned the payload unconditionally.

This is not a classic code bug. It is a gap at the contract level: Symfony documentation described HMAC verification as recommended practice, but the AbstractRequestParser::doParse() interface did not enforce it. Anyone writing a new provider parser — Symfony core team or external contributor — could forget the signature check without any code review raising an alarm. That is what happened with Mailtrap, Mailjet, LOX24, and Twilio.

That all four were reported by the same researcher (Himanshu Anand) is not a coincidence. He went through the provider-bridge class systematically because finding one bug in a bridge always raises the question: „and the others?“ Security research in frameworks follows the class, not the individual case — and that is the larger lesson of this wave.

CVE-2026-45755 — Mailtrap Mailer Webhook Parser

MailtrapRequestParser::doParse() received the secret but never verified X-Mt-Signature. Anyone who knew the application's public Mailtrap webhook endpoint could inject forged events — bounce, delivery, open, click, spam. The result: suppression-list corruption, delivery-metrics fraud. Fix: HMAC comparison in constant time before the decode.

CVE-2026-45754 — Mailjet + LOX24 Webhook Parsers (one advisory, two bridges)

Both bridges had the same bug — doParse() received the secret without reading it. Anyone who knew the webhook URL could forge bounce, blocked, spam, open, click, or delivery events (Mailjet) or SMS status events (LOX24). Mailjet authenticates via Basic-Auth using the user:password pair embedded in the URL; LOX24 uses a token in the X-LOX24-Token header. Both comparisons now run in constant time.

CVE-2026-47212 — Twilio Notifier Webhook Parser

Twilio's HMAC scheme is the most demanding of the four: the signature is computed over URL || sort(post_params), which means the application has to see the same URL that Twilio used to sign — otherwise the HMAC does not match. Behind a TLS-terminating reverse proxy (the default in container deployments), framework.trusted_proxies must be correctly configured; otherwise Request::getUri() returns the internal URL and verification fails even with the right secret and signature. That is a configuration point to check after the patch.

CVE-2026-45756 — JsonPath component, ReDoS via match() / search()

JsonPath JsonCrawler evaluates match() and search() filters by passing the caller-supplied pattern straight into preg_match(). The transformJsonPathRegex() helper only performs cosmetic escaping — no length cap, no restriction to the RFC 9485 i-regexp subset, no backtracking bound. An attacker-controlled JSONPath expression with a catastrophic-backtracking pattern such as $[?search(@, "(a+)+$")] evaluated against a moderately sized document pins one CPU core for seconds per request; a few parallel requests exhaust the worker pool.

The subtle part: the preg_match() calls in the affected code are @-prefixed, which means PCRE backtrack-limit errors are silently swallowed — no log trace, no error event, just quiet worker exhaustion. The fix: JsonCrawler lowers pcre.backtrack_limit to 10,000 for the duration of the call (restoring it afterwards), so pathological patterns fail fast instead of stalling the worker.

Conditions for exploitation: an application that evaluates an attacker-influenced JSONPath expression containing a match() / search() filter against any non-trivial JSON input. Rarely directly exposed in end-user UI; more often in admin-filter backends, API query DSLs, reporting DSLs.

Who is affected?

At my end: what ran automatically, what remains

My post on the 20 May wave documented the platform audit for the HtmlSanitizer trio, UrlGenerator, Mime\Address, and X509Authenticator: 11 of 14 Sylius platforms have multi-locale routes, four Symfony apps run API Platform constraints, the container rebuild ran via Renovate overnight.

Today's four entries followed the same patch stream: Mailtrap, Mailjet, LOX24, and Twilio bridges along with symfony/json-path are sub-packages under symfony/*, and they were pulled along with the core update to 6.4.40 / 7.4.12 / 8.0.12. I do not run manual composer show samples per tenant. The component inventory lives in the SBOM (CycloneDX) generated automatically per build, and the CI gate via composer audit raises an alarm on any known advisory anyway. Both were green after the 20 May rebuild.

What Renovate cannot cover remains as a manual step: the configuration verification per webhook bridge in production. Which bridges run in which tenant setup is in the SBOM. Where a bridge is in production, two things have to be checked today — first, the secret value in the app configuration against the current value in the provider dashboard (otherwise the HMAC check, sharp from 7.4.12 on, blocks legitimate provider posts); second, for Twilio, framework.trusted_proxies. Renovate can neither rotate ENV variables nor open provider dashboards.

Impact

Webhook event injection (three of the four CVEs). Anyone who knows the public webhook endpoint can inject forged events as soon as the endpoint is publicly reachable. In practice these endpoints are trivial to find — they show up in JS bundles, in the provider's setup documentation, or as crawler hits on /webhook/… routes. The effect depends on the provider:

• Mailtrap and Mailjet: bounce, delivery, open, and click events. If the app processes bounce events as „address invalid“ automatically (the standard pattern in CRMs and newsletter pipelines), the reported contact is removed from the mailing list — a DoS against the company's own customer communication. Open and click events additionally distort marketing reporting.
• LOX24 (SMS provider, DACH market): status events for SMS delivery. In regulated industries — healthcare, TAN delivery, banking — a falsely reported delivery is a serious problem for the audit trail.
• Twilio: status events for SMS and Voice, same class as LOX24 but more widely deployed. In many setups Twilio status events trigger follow-up workflows (retry logic, alerting, audit logging). Forged events trigger follow-up actions on a false basis.

JsonPath ReDoS. CPU exhaustion on the worker; no RCE, no data leak. In practice: at moderate parallelism (10–20 requests), the worker pool blocks and further requests run into the queue timeout. Where JsonPath sits in an admin backend behind auth, the attack surface is restricted to logged-in operators — relevant, but not a public path vector. Where JsonPath is exposed in a publicly reachable API query DSL (rare, but it does exist in headless CMS contexts), the vector is public.

Non-impact: code execution, data leak, sandbox escape — none of the four paths lead there. These are authenticity and availability problems, not an integrity break in the application code.

No confirmed mass exploit as of 22 May 2026. A targeted attacker on a particular platform with a known webhook URL would, however, have had an open door since the respective bridge shipped (Mailtrap, Mailjet, Twilio for several Symfony releases; LOX24 since 7.1, i.e. November 2024 at the earliest) — the pattern is trivial and the endpoint is public. Anyone who has seen unusual bounce or delivery spikes in the CRM over the past few weeks, or SMS status anomalies in reporting, should check the reverse-proxy log for requests to /webhook/* routes that do not originate from provider IPs.

Mitigation

Path 1 — Composer update (already done if the 20 May wave ran)

composer update "symfony/*" --with-all-dependencies

# Verify the main component
composer show symfony/runtime | grep versions
# expected: 6.4.40 / 7.4.12 / 8.0.12 depending on major line

The four webhook bridges and symfony/json-path are sub-packages under the symfony/* umbrella. If a composer update "symfony/*" ran during the 20 May wave, they were already updated. That does not mean the configuration is complete — see Path 2.

Path 2 — Verify the webhook secret in the app configuration

After the patch, the HMAC check in the parser becomes active as soon as a secret is configured. The Symfony documentation puts it this way: „When no secret is configured the behaviour is unchanged: signature verification remains opt-in, but it is now actually enforced once opted in.“ That means:

• If a secret was already configured: from 7.4.12 on the signature is verified. Before 7.4.12 the secret was ignored and every request accepted. Watch out: if the secret value in the app configuration no longer matches the one in the provider dashboard (e.g. after a secret rotation in the provider), legitimate provider posts get blocked from the patch onward. A smoke test after the patch is mandatory.
• If no secret was configured: unchanged behaviour after the patch — opt-in remains opt-in. Today is the day to take the opt-in.

# config/packages/webhook.yaml
framework:
    webhook:
        routing:
            mailtrap:
                service: 'mailer.webhook.request_parser.mailtrap'
                secret: '%env(MAILTRAP_WEBHOOK_SECRET)%'
            mailjet:
                service: 'mailer.webhook.request_parser.mailjet'
                secret: '%env(MAILJET_WEBHOOK_SECRET)%'
            lox24:
                service: 'notifier.webhook.request_parser.lox24'
                secret: '%env(LOX24_WEBHOOK_SECRET)%'
            twilio:
                service: 'notifier.webhook.request_parser.twilio'
                secret: '%env(TWILIO_AUTH_TOKEN)%'

The *_WEBHOOK_SECRET values come from the respective provider dashboard: Mailtrap (Settings → Webhooks → Signing Secret), Mailjet (Basic-Auth credentials in the webhook URL), LOX24 (callback settings → token), Twilio (account dashboard → auth token).

Path 3 — Twilio-specific: set trusted_proxies

Twilio's HMAC is computed over the signed URL including the full … form. Behind a TLS-terminating reverse proxy (nginx, HAProxy, Cloudflare, Traefik), the PHP worker normally sees internal-ip/…. For Request::getUri() to return the public URL, trusted_proxies and trusted_headers must be configured correctly.

# config/packages/framework.yaml
framework:
    trusted_proxies: '%env(default::TRUSTED_PROXIES)%'
    trusted_headers:
        - 'x-forwarded-for'
        - 'x-forwarded-host'
        - 'x-forwarded-proto'
        - 'x-forwarded-port'

Path 4 — composer audit as CI gate

As documented in the 20 May post: composer audit as a pre-deploy gate is my standard, and it was green after the 20 May rebuild. Anyone who does not have that gate yet, sets it up today.

composer audit --format=plain

Detection

Inventory the webhook endpoints

# Symfony CLI in the project root
php bin/console debug:router | grep -iE '(webhook|notify|incoming|callback)'

Every match is a publicly reachable endpoint. Scan the reverse-proxy or load-balancer log for requests to these paths over the past 30 days. Spikes that do not match the provider dashboard view (e.g. „Mailtrap reports 1,200 events sent, the app log shows 4,700 POSTs at the endpoint“) are a clear signal of ongoing injection attempts.

Falco rule: webhook endpoint hit from non-provider IP (sketch)

- rule: Symfony Webhook Anomalous Source
  desc: Webhook endpoint receives requests from non-provider IP ranges
  condition: >
    evt.type=accept and
    fd.lport in (80, 443) and
    not fd.cip in (mailtrap_provider_ranges, mailjet_provider_ranges, twilio_provider_ranges, lox24_provider_ranges)
  output: "Webhook endpoint accessed from non-provider IP (cip=%fd.cip lport=%fd.lport)"
  priority: NOTICE

The *_provider_ranges lists are multi-CIDR per provider. Mailtrap, Twilio, and Mailjet publish their edge IPs in their documentation. The Falco rule is a detection signal, not a guard — the actual protection sits in the HMAC check after the patch.

Twilio smoke test after the patch

In the Twilio dashboard: SMS Logs → pick an SMS → „Send to Webhook Now“. Check the app log for RejectWebhookException or a successful decode. If the smoke test fails, the most common cause is a misconfigured trusted_proxies (see Mitigation Path 3).

JsonPath: telemetry for ReDoS attempts

In the JsonCrawler path, pcre.backtrack_limit is reduced to 10,000 after the patch. Pathological patterns now throw an error instead of stalling. If you use the JsonPath component in a publicly reachable path, add a log event in the error handler that records client_ip and the triggering pattern — that way a targeted ReDoS attempt becomes visible.

Operator recommendation

Operational Decision Block

• Patch immediately and verify the configuration if … a production webhook endpoint (Mailtrap, Mailjet, LOX24, Twilio) is publicly reachable and its events flow into CRM, mailing, or notification workflows.
• Patch immediately and audit JSONPath expressions if …symfony/json-path evaluates expressions from untrusted sources.
• Maintenance window is enough if … none of the four bridges sits in the Composer tree and JsonPath is not fed from end-user input. The regular Composer patch from the 20 May wave pulled the sub-packages anyway.
• Not deferrable: there is no workaround for the webhook HMAC bypasses other than temporarily closing the endpoint.

Mittelstand (Symfony and Sylius platforms)

Anyone who ran the Composer update stream during the 20 May wave already has the patch in. What remains is the verify pass per active webhook bridge: check the secret in the app configuration against the value in the provider dashboard; for Twilio additionally trusted_proxies. A smoke test per provider gives certainty.

Enterprise (with custom webhook parsers for other providers)

If you have written your own webhook parser classes for providers Symfony does not cover (Sipgate, MessageBird, Vonage, Plivo, local DACH providers), check the pattern in your own implementation: does doParse() receive the secret and compare it against the provider signature? If not, the custom code has the same class of bug as the Symfony default before 7.4.12. The fix commits (4e0467e Mailtrap, 8545fb2 Twilio) show the pattern: hash_equals() for constant-time comparison, RejectWebhookException on signature mismatch, opt-in only where no secret is explicitly configured.

Kubernetes and containerised setups

Image rebuild against the updated composer.lock (usually already part of the 20 May wave), staged rollout. For Twilio, set the TRUSTED_PROXIES environment variable in the deployment manifest against the ingress cluster IPs if not already done.

Declarative stacks (NixOS, Talos, Flatcar with Wolfi images)

Same as the 20 May wave: rebuild against the updated Composer lock, new image tag, staged rollout.

What I did concretely

The Symfony patch stream went through my setup via the 20 May Renovate wave. The webhook parser bridges and symfony/json-path are sub-packages under symfony/* and were pulled along with the core update to 6.4.40 / 7.4.12 / 8.0.12. composer audit as a CI gate was green after the 20 May rebuild and has stayed green. I do not run a manual composer show sample per tenant — the component inventory lives in the SBOM (CycloneDX) generated automatically per build, not in an ad-hoc run today.

What the four webhook bridges require additionally, and what Renovate cannot cover, is the configuration verification per webhook bridge in production. From 7.4.12 on, the HMAC check becomes active by default. If a secret was configured and its value has drifted between the app configuration and the provider dashboard (or vice versa), legitimate provider posts now hit RejectWebhookException. That drift cannot be found through code inventory — only through comparison against the provider dashboard and a smoke test (provider backend → „Send Test Event“). For Twilio the framework.trusted_proxies check sits on top. Where the SBOM shows one of the four bridges as in production, this verify step is due today.

What I take from the wave: it does not hit the Symfony core but four provider bridges in parallel, all reported by the same researcher (Himanshu Anand), all with the same bug in doParse(Request, #[SensitiveParameter] string $secret). Such class-level findings appear when somebody walks through a component family systematically — that deserves attention beyond the patch itself. At the bridge layer, the 20 May fix makes Symfony structurally better: the HMAC check now sits in the default path, the previously recommended practice has become a contract in code. For my own platform discipline, the wave confirms what the 20 May post already described: inventory via SBOM, patches via Renovate, audit gate via composer audit. The manual step stays where configuration sits outside the code tree — secret values in the provider dashboard, proxy topology, environment variables.

Technical deep-dive on the Twilio HMAC: the signature is HMAC-SHA1 over URL || sort(post_params), base64-encoded. Any drift between the URL Twilio sends and the URL Request::getUri() returns in the app breaks verification. Behind a reverse proxy this is a configuration point; in container setups it is often the only stumbling block after the patch. Mailtrap, Mailjet, and LOX24 are simpler here: Mailtrap signs HMAC-SHA256 over the raw body (URL irrelevant), Mailjet compares Basic-Auth credentials from the URL (sender controls the form), LOX24 checks a token in the X-LOX24-Token header (no URL involved).

Conclusion

The four entries pulled today are not a second wave. They are four advisories from the same layer as 20 May, reported by the same researcher, all with the same bug in doParse(Request, #[SensitiveParameter] string $secret): the secret was passed in but never evaluated. The actual update arrived in composer.lock with the 20 May wave. What remains is the verify pass per webhook bridge in production — secret in the app configuration against the value in the provider dashboard, plus trusted_proxies for Twilio. The actual structural lesson: not a single bridge was broken, the whole bridge class did not have HMAC verification in its contract. The fix in 7.4.12 makes the verify sharp in the default path. Anyone running their own provider bridges should now audit the pattern in their own implementation.