Date: 2026-06-16 Target: Symfony Mailer+Notifier webhook-signature CVE cluster (CVE-2026-45755 Mailtrap, CVE-2026-47212 Twilio never-verify; CVE-2026-48747 Mailomat algo-downgrade). Verdict: WALK CLEAN (17 bridge parsers audited, pure static, no standup).
Audited all 17 *RequestParser.php (Mailer + Notifier bridges) at HEAD for the 3 cluster bug-classes:
(1) never-verifies-a-signature, (2) HMAC algorithm read from the request (downgrade), (3) non-timing-safe compare.
- HMAC bridges (AhaSend/Resend/Mailgun/Sweego/MailerSend/Mailchimp/Vonage/Mailtrap/Twilio): fixed algo
('sha256'/'sha1') + hash_equals. Correct.
- Mailomat: $algo still parsed from header BUT check forces 'sha256' !== $algo reject AND always computes
hash_hmac('sha256',...) -> downgrade CLOSED. Complete.
- Sendgrid: ECDSA openssl_verify. Lox24: shared-token hash_equals($secret,$provided). Both correct.
- Postmark + Smsbox: NO signature check, but auth = IpsRequestMatcher (documented provider IPs); those
providers don't offer an HMAC -> by-design IP-auth, NOT the Mailtrap/Twilio bug (those providers DO sign).
- Signed-data scope varies per bridge (body vs URL vs headers+timestamp) = each provider's documented scheme,
not a Symfony inconsistency (the bridge must hash exactly what the provider hashes). Provider-protocol variance.
Set-difference EMPTY -> no un-patched sibling.
My validated centralized-vs-per-handler predictor said: PER-HANDLER-SCATTERED fixes yield findings (missed siblings); CENTRALIZED fixes walk. Symfony's bridge parsers are architecturally the MOST scattered case possible - every bridge has its OWN parser, NO shared verify helper, NO choke-point. By architecture alone the predictor screams "incomplete-fix-prone." Yet it WALKED CLEAN. => Scattered architecture is NECESSARY but NOT SUFFICIENT for an incomplete fix. The missing axis is maintainer-sweep discipline: when a cluster CVE lands, does the maintainer POINT-FIX the reported handler (Gitea feed, Filebrowser cleanup -> missed siblings -> our hits) or SWEEP the whole sibling set (Symfony fixed all bridges in the cluster release)? Refined predictor (triage order): 1. Is the fix centralized (shared helper/sink)? -> walk. 2. If scattered: did the fix commit touch ONLY the reported handler, or ALL siblings of that class? - only-reported -> HUNT the siblings (high yield). - swept-all-siblings -> walk (Symfony pattern). => READ THE FIX COMMIT'S FILE LIST, not just the architecture. A scattered surface + a broad sweep = clean.
Pure-static cross-sibling set-difference on a CVE CLUSTER = high-EV, ZERO-standup hunt. Recipe: sparse-clone only the sibling dirs -> fingerprint every sibling on the bug-class dimensions (here: hash_hmac present? hash_equals? algo hardcoded-vs-from-request? what data is signed?) -> read ONLY the anomalies. 17 parsers triaged in one pass, no docker/PHP runtime. Use this for any "cluster of N related CVEs in per-X handlers" lead (Symfony bridges, AWS SDK signers, OAuth providers, payment-webhook verifiers).