The Methodology Behind CVE-2026-11395: An Unauthenticated SSRF Hiding in Plain Sight

Sports analytics and vulnerability research are the same job. You're looking for the gap between what a system claims to guarantee and what it actually does. This is the security side of that coin.

There's a specific half-second when an SSRF confirmation request actually lands — before your brain catches up, your stomach already knows. You're staring at a log line that shouldn't exist, and for one beat you're not sure if you're looking at a bug or a mistake you made in your own test rig. Then you check it again, and it's real, and now you've got a decision to make about what to do with it. That half-second is why I do this. Earlier this year it led to my first published CVE — CVE-2026-11395, an unauthenticated Server-Side Request Forgery in the CF7 to Webhook plugin for WordPress, affecting every version up to 5.0.0. CVSS 7.2, High. The plugin runs on north of 30,000 sites. I'm not going to hand you a working exploit chain here — that's not something I'd put on the public internet regardless of what any disclosure policy technically allows. What I want to walk through instead is the methodology: how I look at plugins like this one, why the bug was sitting there in plain sight, and what it taught me about where these things actually live. If you're trying to break into vulnerability research, this is closer to useful than a payload would be anyway — payloads get patched, methodology doesn't.

How a routine recon sweep found it

I didn't set out looking for this specific plugin. It came out of a broader recon sweep — I run scripts against batches of WordPress plugins looking for patterns worth a closer look by hand. The scripts don't find bugs. They triage which of the thousands of candidates deserve my actual time, which is a very different job. CF7 to Webhook got flagged for the reason most of my real finds get flagged: it makes outbound HTTP requests, and it lets an admin configure part of that request dynamically. User-influenced input plus outbound network calls is close to the top of my personal watchlist, because that combination is exactly where SSRF and IDOR bugs like to nest. The script doesn't tell you there's a bug. It tells you where to go look — same as a scouting report doesn't tell you who's going to miss a tackle, just which matchup to actually watch on Sunday.

Why plugins, and why webhooks specifically

If you're hunting bugs in WordPress, the core is a bad place to spend your time. It's been beaten on by thousands of researchers for two decades — anything easy to find there got found years ago. The plugin ecosystem is different: tens of thousands of them, wildly uneven code quality, and a huge chunk exist specifically to bridge WordPress to some other service — Zapier, webhooks, CRMs, payment processors, whatever. I've burned entire weekends auditing plugins that turned out clean, which is its own kind of useful. You start to feel the difference between code that was written carefully and code that was written to ship by Friday. That bridge is the interesting part. Any time a plugin's whole job is "take data from over here and send it over there," you've got two trust boundaries touching each other, and somebody had to write the code that hands data across that seam. That's where I focus — not the core, not the popular security plugins everybody already picked clean, but the connector code nobody thinks is exciting enough to audit twice. Think of it like scouting: everybody already knows what the star player does. You spend your film time on the backup right tackle nobody's game-planned for, because that's where the actual mismatch shows up on Sunday. Plugin connector code is the backup right tackle of the WordPress ecosystem.

What CF7 to Webhook actually does

CF7 to Webhook lets a site admin wire up Contact Form 7 so that whenever someone submits a form, the plugin fires an outbound HTTP request to a webhook URL — Zapier, Make, whatever automation tool the site owner's using. The design decision that mattered here: the plugin lets the admin build that webhook URL using CF7 field placeholders. Instead of a hardcoded destination, part of the URL can be dynamically filled in from whatever the form submitter typed.