Never Had a Critical Finding? It Doesn’t Mean You’re Secure.

Never having had a critical finding feels like proof that a program is secure. But that isn’t necessarily true. Here's what that looked like for one team: a critical vulnerability that was discovered in an application that passed every scheduled test and automated scan, until a human researcher found it.

It had been through an annual penetration test. Automated scanners ran continuously in CI/CD. There were no open critical findings, and leadership felt confident about where things stood. On paper, the security program was solid.

That's how most of these stories start.

Walking the App Like a User Would

One of the program's researchers logged in, and nothing looked obviously wrong. No crashes. No loud errors. No glaring misconfigurations, the kind of environment that reassures most teams and doesn't give most scanners anything to flag.

So the researcher slowed down. Instead of starting with payloads and automated tooling, they spent the first hours doing something deceptively simple: clicking through the application as different users, including a standard user, a support role, and an administrator. Each role behaved mostly as expected.

One workflow stood out. A non-admin user could view a page they probably shouldn't have been able to see. Not enough to raise alarms, just enough to be interesting. A scanner wouldn't flag it. It wasn't technically broken. It was permissive.

That page linked to another endpoint, and that endpoint accepted an ID parameter. Changing the ID didn't throw an error. It returned data.

Nothing dramatic at first. A name here. A timestamp there. But mapping the pattern and chaining a few requests together made the picture clear: a low-privileged user could perform actions reserved for administrators.

No exploit kits. No zero-days. Just a researcher willing to keep pulling on a thread. Once Inspectiv's triage team replicated the chain and confirmed it held up, the finding was rated critical: full administrative capability, reachable from a standard user account, with no authentication bypass or custom tooling required.

The Findings That Most Tools Can’t Catch

Over the life of a program like this, findings tend to arrive as a steady trickle rather than a single burst. Most are minor. A handful get caught by automated tools, mostly injection-style issues that scanners are genuinely good at finding.

But, in this case, the most serious findings weren't technical tricks. They were logic failures:

• Access controls that assumed users wouldn't try certain paths

• APIs that trusted the UI too much

• Data exposure that only appeared when endpoints were examined one by one

These issues didn't announce themselves. They revealed themselves slowly, through context, the kind of pattern a curious researcher notices and a scanner has no reason to look for. That kind of thing is common enough to top OWASP's latest rankings: the 2025 Top 10 found that some form of broken access control showed up in 100% of the applications tested, more than any other risk category. The category covers exactly this kind of failure: permissions that technically function but shouldn't, in combination, allow what they allow.

In many cases these overly-permissive endpoints return the application’s most sensitive data to low level users; such as patient records, user data, PDF reports, or other PII treasure troves.

For a closer look at the specific patterns behind that number, see Inside Broken Access Control: Its Three Most Common Issue Patterns.

“We've Never Had a Critical Before”

When Inspectiv shared the validated report, the reaction was familiar: “We’ve never had a critical before.”

Their previous moment-in-time pentest ran as scoped and produced a clean report. It supported compliance requirements. Nothing was done wrong.

But that test wasn't designed to follow curiosity, question assumptions, or sit with an application long enough for a pattern to emerge across roles and requests, months after the engagement ended, on a build that had already changed. A clean report usually means the test ran efficiently and met its objectives. It doesn't always mean the underlying risk has been fully explored.

The best security leaders want to see criticals on their reports. A critical means the testers got far enough in to find something that actually mattered. That's the point of the exercise: surface the damaging thing while it's still yours to fix, before someone with worse intentions finds it.

One Test Is a Snapshot, Not a Guarantee

An annual pentest is a snapshot: a defined scope, a fixed window, a report at the end. That's valuable, and it's also inherently limited. Code ships continuously. Roles and permissions change. New endpoints go live between one test and the next. 

Automated scanning fills part of that gap. Scanners are built to recognize known patterns: a missing header, an outdated library, a classic injection point. They aren't built to notice that a permission technically works but practically shouldn't, or that four unremarkable API calls, chained in the right order, add up to a privilege escalation. That takes judgment, not pattern-matching, which is why it stays a blind spot for most tooling alone.

A 2026 survey of 455 security professionals found that 78% had experienced automated scanning tools missing a critical vulnerability, and support for relying on automation alone fell from 29% to just 9% in a single year. This doesn’t mean that organizations are abandoning automated tools, but rather that they are looking critically at the role automation plays in their security program.

Bug bounty programs and penetration testing as a service (PTaaS) close the point-in-time gap in complementary ways. Bug bounty adds a wide, continuously refreshed set of researcher perspectives testing the same surface from different angles as it changes. PTaaS applies that same structured, methodical rigor of a pentest on an ongoing cadence instead of once a year. A pentest still satisfies what it's scoped for, a compliance requirement, a scheduled checkpoint. What continuous, human-led testing adds is coverage in the months between engagements, which is exactly where a finding like this one tends to live.

How Inspectiv Helps

Inspectiv pairs intelligent automation with best-in-class human researchers to provide continuous testing and find impactful vulnerabilities across your attack surface. Within the first two months of testing, 80% of Inspectiv clients had at least one critical finding surface. Every submission is validated, replicated, and rated for severity by Inspectiv's triage team before it ever reaches your team, so what lands in your queue is a confirmed risk, not a raw report. 

If you want to see what Inspectiv can find in your own environment, schedule a demo.