There is a class of bug we hunt that no monitoring system you have is going to catch. The server takes the request, mutates state it shouldn't, returns 200 OK, and from inside the application nothing happened. Every scanner sees a clean response. Every WAF sees a request matching no rule. Every SIEM sees a normal log line. The bug is real. It just isn't anywhere your tooling is looking.

It is the most reliably mispriced class of finding in our corpus.

Why other classes show up

Every other security event eventually trips something. SQL injection slows queries. Auth bypass hits the auth library's failure counters. Path traversal pings the file system audit. Brute force hits rate limits. The standard defender stack is built on the assumption that something inside the application has noticed something is wrong.

The 200 OK bug breaks that assumption. The application did exactly what the request asked. The request asked for something the application's rules said was fine, so the rules fired and the response was clean. From inside the application, nothing happened.

A common shape: an endpoint takes a parameter that should be treated as a system-owned identifier. The server treats it as caller-controlled input. The mutation succeeds. The caller's next request carries a capability they didn't have before. The accounting that would have caught it lives in a different service that doesn't know what just happened.

Why commodity stacks can't see them

Every layer in the standard defender stack is reading the wrong signal. A frontier model handed a response and asked "is anything wrong" assesses it on its surface. Status is 2xx. Body is well-formed. Latency is normal. The answer is no. The answer is correct, given what the layer is looking at. The bug isn't in the response. The bug is in the silent disagreement between what the application thought it did and what it actually did.

Catching that disagreement requires holding a counterfactual. What would this response have looked like if the operation behind it had refused? The counterfactual isn't in the response. It is built from having read enough responses on this endpoint to know what a refusal would have echoed back.

That counterfactual is what our practice exists to produce. It is expensive to build. It doesn't generalize between targets. Every new surface starts at zero and stays there until enough reads accumulate that the wrong response becomes visible. The reason the class is mispriced isn't that anyone's tooling is broken. It is that the counterfactual lives at a level commodity tooling, by structure, cannot reach.

How we catch them

We read responses. Slowly. The kind of slowly that doesn't show up on anyone's procurement budget.

A scanner sees 200 and moves on. We sit with the response and ask whether the operation behind it actually did the thing it claimed to do. Often the response is missing something a correct one should have. A field that should echo back the canonical identifier. A count that should have moved. A timestamp that should have updated. Sometimes it has something it shouldn't. A hint that the operation matched a record the caller had no business naming.

The signal is small. The fact that the signal is there is the whole vulnerability.

What to do about it

For every state-mutating endpoint, define an invariant the response should establish. Then test it.

"The caller's identifier shows up in the response, exactly."

"The mutation count is one."

"The returned record is owned by the caller's tenant."

Most teams test that the response code is 2xx and stop. That isn't a test. It is a check that the framework still works.

The bugs in this class survive because the response code is the only thing anyone looks at, including in CI. Move the assertion up a layer, into the semantics of what the response means, and the class mostly collapses.

You're not going to instrument your way out of it from below. WAF rules, SIEM correlations, behavioral analytics, none of those have the semantics. The semantics live in the application code. The check has to live there too.

The findings that don't show up anywhere are the ones that pay. Most of the industry, by omission, has decided not to look for them. That is the structural opening our work runs through.