Anthropic says Claude found 493 attack-surface issues across 25 open-source projects. An attack surface is the code and behavior a system exposes to users or software before security checks take effect. The count describes exposure and configuration findings; Anthropic says findings in the 11 projects it classified as Gated were not immediately exploitable on their own.
What Claude’s analysis covered
The projects represented more than 5 million lines of code and included C, C++, Java, PHP, and Python. Anthropic says Claude inventoried more than 17,000 configuration options, of which 3,842 concerned security controls or features.
Anthropic grouped the projects into 10 Public, 11 Gated, and 4 Private. Across those groups, the analysis examined code reachable under default settings, interactions between configuration options, and sensitive code that could run before gates such as authentication.
What the findings measured
For the 11 Gated projects, Anthropic reported three distinct kinds of exposure: 93 unnecessary pre-authentication surfaces in default configurations, 37 locations where code ran or state was recorded before authentication, and 61 configuration combinations that weakened a pre-authentication control. These findings describe routes into code or behavior, not individual demonstrated exploits.
Separately, Anthropic reported 162 security-sensitive configuration combinations that were accepted without a warning or documentation of expected behavior. In 94 cases, the combination silently disabled a security control; the other 68 involved inconsistencies.
A configuration combination can change how software behaves when settings interact. For example, a setting that appears to enable a security control may be undermined by another option. Anthropic’s totals distinguish those configuration problems from the pre-authentication findings, so the categories should not be added together as if they measured the same thing.
How the OpenSSH fix changed across versions
In its OpenSSH case study, Anthropic traced an issue from version 10.4 through changes it says shipped in 10.5 and 10.6. In the default 10.4 daemon, an unauthenticated client could reach about 4,500 lines of experimental ML-DSA-44 signature code before the relevant configuration check. ML-DSA-44 was not enabled by default. Anthropic says those lines made up about 16% of OpenSSH’s pre-authentication code.
Pre-authentication code runs before a user proves their identity. Keeping unnecessary parsing or verification code reachable at that stage expands the software an unauthenticated client can interact with.
Anthropic says an initial change in OpenSSH 10.5 moved a configuration check ahead of parsing. Follow-up analysis found gaps involving a mismatch between the advertised algorithm and the key type encoded in the key, as well as certificate CA-signature verification. Anthropic says the final changes shipped in OpenSSH 10.6: the parser checks encoded key types and certificate CA-signature algorithms against configured allow lists before deserialization or signature verification.
Anthropic estimates that the final changes removed roughly one fifth of the code previously reachable by unauthenticated clients in a default build. That figure refers to the previously reachable code, not the entire OpenSSH codebase.
How Anthropic says it checks proposed changes
Anthropic says the reusable analysis skill confirms findings with dynamic program traces. For changes affecting default-configuration gates, it compares a modified build with the baseline using the project’s test suite and a black-box regression suite. Changes that affect non-default configurations are left for human review.
Anthropic says it is working to integrate the skill into OSS-Scanner. That integration is in progress.
