← Back to feed

Anthropic published a security research paper today by Chris Rohlf outlining what happens when Claude is pointed at large open source codebases and asked to map unnecessary attack surface. The results are specific: across 25 projects representing more than five million lines of code, Claude identified 493 distinct issues — not by finding individual CVEs, but by identifying code that was reachable when it should not have been.

The distinction matters. Vulnerability-by-vulnerability patching scales poorly: fixing one critical flaw tells you nothing about the ones remaining. Attack surface reduction operates at a different level, restricting or removing code paths before an attacker finds a way through them.

What Claude Was Looking For

Rohlf’s team focused Claude on three categories of unnecessary exposure:

• Default configuration: Code reachable in the shipped default state that no default functionality actually uses
• Configuration interaction: Pairs of settings that look valid in isolation but, combined, silently disable a security control or leave behavior undefined
• Early reachability: Security-sensitive code that executes before authentication, before victim interaction, or before a protocol state transition where it should not yet be reachable

Claude built an inventory of over 17,000 configuration options across the 25 projects. Of those, 3,842 touched a control or feature with security relevance.

The Numbers by Project Category

Projects were split into three categories — Public (designed to serve any user), Gated (authenticated users only), and Private (operator-controlled environments). 10 were Public, 11 Gated, 4 Private.

The gated cohort produced the most significant findings:

• All 11 gated projects had code reachable before authentication that should not have been
• 93 unnecessary pre-authentication surfaces in the default configuration
• 37 code locations that executed, or recorded state, before authentication completed
• 61 configuration combinations that silently weakened a pre-authentication control set by the administrator

The configuration interaction findings cut across all project types. Claude identified 162 security-sensitive configuration combinations that were accepted without error, without warning, and without documentation of the expected behavior. In 94 of those cases, the combination silently turned off a security control. The other 68 were inconsistencies within the same security mechanism — a listener or login path remaining reachable even though the configuration said it was disabled, or two conflicting settings where which one took precedence depended on their order in the config file.

Why This Approach Beats Patch-By-Patch

The paper’s core argument is about scale. Vulnerabilities of the type these findings represent — unnecessary reachability, silent config interactions, pre-auth code exposure — often exist in software for years without being discovered, because reviewers focus on logic flaws rather than systematically mapping what code is reachable and why.

Claude’s approach inverts that: build a complete map of configuration options and their security relevance, then check every combination. A human reviewing the same codebase would identify some of these issues, but not 162 configuration pairs across 25 projects in a single pass.

None of the individual findings are immediately exploitable on their own, which is exactly why they persist. They expand the attack surface without triggering standard severity thresholds. Combined with an actual vulnerability, each one represents a path an attacker could use that a defender might not have anticipated.

Anthropic says developers can apply the same techniques to their own code. The research does not announce a product — it describes a methodology and publishes the findings to establish what Claude can do in this space.