- Anthropic reports that Claude analysed 25 open-source projects and found 493 issues. In 94 cases, a combination of settings silently turned off a security control.
- The finding shifts attention from unfound bugs to code that stays reachable when the configuration says it should not be. Anthropic says shrinking that reach lowers the risk from unknown flaws.
- Ask vendors and internal teams what runs before login, and which security settings can be overridden without a warning.
A control that is on paper but off in practice
In a pattern Anthropic describes, an administrator writes a rule to block a list of machines. The rule is saved. No error appears. The rule then blocks nobody.
Anthropic says this pattern appeared independently in four unrelated open-source projects. The lesson is broader than one bug. A security setting on a screen states an intention. It does not prove behaviour.
This shows that unknown flaws are only half of the problem. The other half is how much code an outsider can reach in the first place.
What Anthropic did
Anthropic ran its Claude model across 25 open-source projects. It puts their combined size at more than five million lines. The languages include C, C++, Java, PHP and Python.
Claude built a list of over 17,000 configuration options. Of these, 3,842 related to a security-relevant control or feature.
It then looked for three kinds of exposure. The first is code reachable in the default setup that no default feature needs. The second is pairs of settings that look fine alone but cause trouble together. The third is complex code that runs before a security check, such as a login.
Anthropic reports 493 issues in total. This is the company's own research. WebPulse has not verified the findings independently.
How a deny rule fails
The name-based rule shows the mechanism. Suppose an administrator blocks clients by hostname or a wildcard pattern, not by numeric IP address. To apply that rule, the server must know the client's hostname.
It learns the hostname only through reverse DNS lookups. A separate option controls those lookups. Anthropic says most projects had that option off.
With lookups off, the server holds only the client's IP address. It compares the hostname pattern to that address as plain text. A name pattern cannot match a number, so the deny rule never fires.
The list then "fails open", which means it lets everyone in. Anthropic says some projects document that name rules need DNS lookups. It found none that warned a deny list written this way would let everyone in.
94 silent failures
Claude found 162 security-sensitive setting combinations that the software accepted without an error or warning. None came with documentation of how the settings interact.
Of the 162, 94 switched a security control off. The other 68 were inconsistencies. In one, a login path stayed reachable although the configuration said it was disabled.
Anthropic describes one case that lasted 21 years. An administrator could require every client to present a certificate. A second option, meant only to delay that check, removed it entirely. A server set to accept only trusted clients would accept anyone.
Code that was meant to sit behind the certificate check was therefore open to any stranger who connected. Neither a warning nor the documentation told administrators that the requirement had vanished.
Anthropic adds a caveat. Some of these combinations may be unusual or rarely used. Nothing, however, stops an administrator from deploying them.
Heavily reviewed code had the same gap
Anthropic says all eleven projects built for authenticated users had code reachable before login. It adds that none of these issues was immediately exploitable on its own.
The largest cut, measured as a share of code, came in OpenSSH. Claude traced how the OpenSSH 10.4 server handles incoming input. It found about 4,500 lines of new, experimental code for ML-DSA-44, a signature method designed to resist quantum computers.
An unauthenticated client could reach that code in the default setup. It stayed reachable even when an administrator had explicitly excluded the algorithm. The server parsed the key first and checked afterwards whether the type was allowed.
By Anthropic's count, the code made up about 16% of the code OpenSSH itself runs before login in a default server.
Anthropic reported the problem with patches. In OpenSSH 10.5, the test of whether a key type was permitted began to run before the key was processed. Claude then found two gaps. A client could misstate its key type, and certificates could still trigger signature checks before the configuration was consulted.
Release 10.6 closed both gaps. Anthropic says the work removed roughly a fifth of the code an unauthenticated client could previously reach in a default build.
The idea for leaders: shrink the target, not just the bug list
Anthropic argues that fixing flaws one at a time scales poorly. Each fix says nothing about the flaws that remain.
Cutting what an attacker can reach lowers the risk from all unknown flaws at once. That includes any already being exploited quietly. In Anthropic's words, the techniques "don't remove the unknown vulnerabilities" but make them "harder to reach".
Anthropic also notes that attackers can find flaws given enough time, especially with frontier AI models. The same class of tool can be pointed at defence. Here it was used to map reach rather than to hunt for bugs.
Questions to put to your team
Ask which services accept connections before anyone has logged in. Ask what code those connections touch.
Ask whether any security setting can be overridden by another setting without a warning. Ask how the team confirms that a deny rule actually blocks traffic, rather than trusting that it was saved.
Put the same questions to vendors about the open-source parts of their products. Anthropic has packaged its method as a reusable Claude skill. It plans to build the skill into OSS Scanner, a free service open-source projects can opt into.
When a fix would alter a non-default setup, Anthropic says the skill hands the decision to a person.
A setting that reads as secure is only a claim. The test is what the running system does when a stranger connects.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Anthropic.
