On October 20 Chris Rohlf of the Frontier Red Team published numbers from an experiment that asks a different question than most security work. Not: which bug is in this code? But: which code is reachable at all, and does it need to be?
Shrinking the surface instead of counting bugs
The reasoning is uncomfortable and correct. Closing one vulnerability tells you nothing about the ones still there. Reduce code reachability, though, and you reduce the severity of the flaws you haven’t found yet, including any under active exploitation. The bugs stay in the code; they just get harder to reach.
The team handed Claude three methods. Code reachable in the shipped default configuration that no default functionality actually needs. Pairs of options that look sensible alone and break something together. And security-sensitive code that runs before authentication or before a protocol state transition.
What came back
25 projects, over five million lines, across C, C++, Java, PHP and Python. Claude built an inventory of more than 17,000 configuration options, 3,842 of them security relevant, and reported 493 issues.
The projects fall into three buckets: public, gated (nothing works until you authenticate) and private. All eleven gated projects had unintentionally reachable code. Specifically: 93 unnecessary pre-authentication surfaces in the default configuration, 37 places where code ran or state was recorded before authentication, and 61 configuration combinations that silently weakened a pre-auth control an administrator had set.
The most interesting bucket is the interactions: 162 security-sensitive combinations accepted with no error, no warning and no documentation of what they do together. In 94 of those, the combination silently switched a security control off.
The pattern that turned up four times independently
An administrator writes an access rule for remote clients using a hostname or a wildcard instead of an IP address. When a client connects, the server compares the rule against that client’s hostname — assuming it knows it, which depends on a separate reverse DNS option. In most of these projects that option was off.
So the server only has the IP, and compares the rule against it as plain text. A hostname pattern can never match an IP address. The deny rule never fires and the list fails open. Some projects note in their docs that hostname rules need DNS lookups enabled. None of them say that a deny list written that way lets everyone through.
This finding is duller than an exploit, and worth more
In the same week, AI turned up an RCE flaw in PHP that reaches 70 percent of all websites. That’s the story everyone reads. This one saves more servers.
Defenders aren’t short of bugs to fix. Their problem is that after each fix they know exactly as little as before. A configuration that quietly disables a control appears in no CVE database, and costs you precisely when the next CVE lands. Ninety-four of those across 25 projects isn’t a research note. It’s a homework list.