Why Vulnerability Scanners Miss Real Attacks

What a scanner actually does

A vulnerability scanner checks configuration against known-bad patterns: is a header missing, is a dependency outdated, is a key present in a bundle it shouldn't be. This is valuable — most real incidents start with exactly these mistakes — but it's fundamentally a lookup, not an attack.

What that lookup can't catch

Business logic flaws

A checkout flow that lets a user apply the same discount code twice by hitting "submit" rapidly isn't a missing header or an outdated package — it's a sequencing bug that only shows up when something actively tries the sequence.

Chained exploits

A low-severity information leak on its own might be a non-issue. Combined with a separate endpoint that trusts that leaked information, it becomes a full account takeover. A scanner evaluates each finding independently — it has no way to notice the combination.

Authorization logic, not just authentication

A scanner can confirm a route requires a valid session. It generally can't confirm that a valid session for User A doesn't also grant access to User B's data — that requires actually attempting the access with a real, different account.

Anything that requires state

Race conditions, workflow-step skipping, and time-of-check-to-time-of-use bugs all require multiple requests in a specific relationship to each other. A single-request scan can't construct that.

The fix isn't a better scanner — it's a different kind of test

None of the above is a scanner failing at its job; it's outside the job. Closing this gap requires something that actively attempts exploits rather than matching patterns — an autonomous AI pentest, or a human one. See AI Pentesting.