Why Automated Scanners Miss Critical Vulnerabilities

Every AppSec team eventually has the same uncomfortable meeting. The scanner says the app is clean. The pentest report, three weeks later, has fourteen findings — two of them critical. The CISO wants to know how both reports can be right. They can, and understanding why is the difference between a mature security programme and an expensive compliance checkbox.

Automated scanners — Nessus, Nuclei, OWASP ZAP, Burp’s active scan — are excellent at what they do. They’re also incapable of finding a large and growing category of real bugs. Here’s where the gap sits, and what you should do about it.

What scanners actually do

Scanners work by sending known-bad payloads to your endpoints and matching responses against signatures. Nuclei ships with thousands of YAML templates describing CVEs, misconfigurations, and default-credential checks. Nessus has a similar engine with tens of thousands of plugins. ZAP and Burp’s active scanner do a crawl, identify parameters, and mutate them with payloads for SQL injection, XSS, open redirect, and the rest of the classics.

If the bug matches a pattern — a response contains the reflected payload, a delay-based SQLi fires, a known vulnerable path returns an expected banner — the scanner catches it. If the bug requires understanding what the application is trying to do, the scanner is blind.

That’s the category gap. Scanners do syntax. Humans do semantics.

1. Business-logic flaws

Business logic is the set of rules your application enforces because someone wrote code to enforce them. A scanner has no idea what those rules are. It can tell you a checkout form has a quantity field, but it doesn’t know that quantity shouldn’t be negative.

Classic examples we see regularly:

• Negative quantities in a cart. User adds 2 of Item A (₹1000 each) and -1 of Item B (₹500). Total comes out to ₹1500. Refund processor pays ₹500 to the attacker’s saved card.
• Promo code stacking. A coupon allows one use per account, but the app checks after applying the discount. Send 20 concurrent requests and all 20 apply.
• Workflow bypass. A three-step KYC form can be completed out of order by hitting the final submission endpoint directly. The intermediate validation never runs.
• Price manipulation via client-side state. Price is calculated client-side and passed to the server, which trusts it.

A scanner cannot find any of these because to find them you need to know what the app is supposed to do. A tester spends an hour understanding the flow, then thirty minutes breaking it.

2. Chained low-severities

Scanners produce flat lists of findings. A human looks at a flat list and starts chaining. Two informational findings plus one low can become a critical in the right combination.

Common chains we exploit:

• SSRF into cloud metadata. The scanner finds an SSRF and flags it medium — “can reach internal hosts”. The tester confirms the app runs on AWS EC2, hits http://169.254.169.254/latest/meta-data/iam/security-credentials/, pulls IAM role credentials, and uses them to read an S3 bucket full of customer PII. Same bug, two orders of magnitude more impact.
• HTTP parameter pollution into IDOR. The app deduplicates query parameters server-side but the WAF checks only the first instance. ?userId=self&userId=12345 bypasses access control because the WAF sees “self” and the backend reads 12345.
• Open redirect into OAuth token theft. Alone, the open redirect is a low. Chained with a misconfigured OAuth redirect_uri allowlist, it becomes account takeover.
• Cache key confusion. A CDN caches based on path only. An authenticated page with PII gets cached and served to unauthenticated users. Scanner sees two HTTP 200s; tester sees a privacy incident.

Chains require context the scanner doesn’t have — what the backend framework dedupes, where the app is hosted, which OAuth provider it uses, what the CDN’s cache key rules are.

3. Authentication-flow flaws

Auth is where the biggest silent failures live. SAML, OAuth, and OIDC are each dense enough specifications that most implementations get at least one thing wrong. Scanners have limited coverage here.

SAML assertion replay. If the SP doesn’t validate the assertion’s NotOnOrAfter correctly, or doesn’t enforce single-use, a captured assertion can be replayed. Scanners don’t parse SAML flows deeply enough to check.

JWT alg confusion. A server expecting RS256 but accepting HS256 can have its own public key used as an HMAC secret by the attacker. Scanners catch alg: none sometimes; confusion attacks need manual work.

OAuth state parameter. Missing or predictable state means CSRF-to-login — the attacker logs the victim into the attacker’s account or vice versa, enabling session fixation-style attacks.

Password reset token issues. Tokens that don’t expire, don’t invalidate on use, or leak via Referer headers. Reproduction is trivial once you spot the flaw; finding the flaw requires reading the whole reset flow carefully.

MFA bypass. A 2FA check that can be skipped by removing the otp field, or where rate-limiting applies only to the login endpoint and not to the OTP-verify endpoint, or where the OTP is validated client-side.

Most auth flaws are one careful read of the flow away from discovery. Scanners don’t read.

4. Race conditions

Race conditions are bugs that only appear when two operations run at almost exactly the same moment. Scanners fire requests sequentially and wait for responses. Attackers fire twenty requests simultaneously and see which ones got through.

• TOCTOU in file upload. The app checks the extension of an uploaded file, then moves it to a public directory. Between those two operations, the attacker swaps the file. Single-request tools won’t see this; Burp’s Turbo Intruder or a simple Python script with asyncio will.
• Concurrent coupon use. A gift card with ₹500 balance can be redeemed twenty times if twenty concurrent requests race past the balance check before any of them update the database row.
• Double-spend in wallets. Same pattern in fintech. Transfer ₹1000 to two destinations simultaneously from a ₹1000 balance, both succeed, balance goes to -₹1000.
• Signup race for reserved usernames. Register “admin” during a one-second window where the reservation list is being refreshed.

Turbo Intruder’s single-packet attack and Python’s aiohttp are standard tooling. Reproduction sketch: send 30 identical requests in one TCP packet using HTTP/2 multiplexing, observe whether the server’s locking holds.

Where scanners earn their keep

This isn’t an argument against scanners. Scanners do several things manual testing can’t, and any mature programme runs both.

Scanners give you coverage breadth. A pentester will look hard at your top 20 endpoints; Nuclei will hit 2000 and catch the forgotten Jenkins on a dev subdomain with default credentials. Scanners detect regressions — a nightly Nuclei run against production flags the day a new deploy reintroduces a known bad header. Scanners handle compliance checkboxes cheaply — if your auditor wants proof that TLS 1.0 is disabled on every edge asset, a scan is the right tool. Scanners also maintain an inventory of versions, banners, and exposed services that a pentester doesn’t have time to rebuild from scratch each engagement.

The right mental model: scanners are smoke detectors. They catch the known shape of fire quickly across a large building. A pentester is an arson investigator, sifting through specific rooms for how the fire could start. You need both. You also need someone who knows the difference — so when the scanner says clean, you don’t send it to the board as “we have no bugs”. You send it with “we have no known-pattern bugs, and a pentest is how we find the rest”.

At ZynoSec, every Kavach Sentinel finding is human-validated before it reaches the client dashboard. That’s the gap we close — automation for breadth, humans for judgement.