We could build a scanner that tries to actually exploit the vulnerabilities it finds, to prove they're real. We chose not to, on purpose.
The tempting shortcut
Actively confirming a vulnerability — attempting the SQL injection, trying the file upload, brute-forcing a login — removes doubt. If it works, you know for certain the site is vulnerable. That's a tempting design, especially for a scanner trying to prove it isn't just crying wolf.
Why we didn't build that
Running exploits against a site you don't operate is a legal and ethical line we're not willing to cross, even with a consent checkbox in front of the form. A checkbox tells us what the person submitting the URL says — it doesn't make an active intrusion attempt against a third party's infrastructure something we're comfortable automating at scale.
There's also a practical reason: active testing can break things. A real SQL injection attempt can corrupt data. A file upload exploit can leave something behind. A login brute-force can lock out legitimate admins or trip a host's abuse detection. None of that is acceptable for a tool meant to run unattended, on request, against sites we've never seen before.
What passive scanning gives up — and what it buys
Passive, version-based detection trades some certainty for safety: a version match is strong evidence, not absolute proof (a site owner might have backported a fix without bumping the version number, for instance). In exchange, we get a tool that's genuinely safe to point at any site you're authorized to test, with zero risk of being the thing that breaks it.
If you want proof beyond a version match, that's exactly what a real penetration test is for — and we're upfront that PatchCheckup isn't a replacement for one. See our methodology page for the full breakdown of what's in scope and what isn't.