Anthropic used Claude to trim attack surfaces across 25 open-source projects, logging 493 issues

Anthropic has published research showing that its Claude model can be put to work on the defensive side of security, mapping which parts of a codebase are actually reachable and flagging code that is more exposed than a given deployment requires. According to the post on Anthropic's research site, written by Chris Rohlf, Claude analysed 25 open-source projects spanning more than five million lines of code and identified 493 issues of this kind.

The work is a deliberate counterpoint to Anthropic's earlier findings that frontier models can discover and exploit previously unknown vulnerabilities. Demonstrating exploitation, the post argues, is only the starting point for what these models can contribute to cyber defence.

Reducing reachability instead of chasing bugs

The central argument is that patching scales poorly: closing even a critical vulnerability tells you nothing about the flaws that remain. Attack surface reduction takes the opposite approach. It does not eliminate unknown vulnerabilities, but it makes them harder to reach, which lowers their severity, including for bugs that may already be under active exploitation.

In practice, this means moving code behind an appropriate gate: from pre-authentication to post-authentication, from zero-click to one-click, from on-by-default to explicit opt-in, or from the first message of a protocol to a later point in the session state machine. Rohlf also notes that software tends to accumulate layers of abstraction, dependencies and features over time, causing it to behave differently from what its original developers intended, and that attackers routinely study how code behaves in practice rather than how it was designed.

Three ways code gets overexposed

Anthropic's research focused on three techniques. The first, default configuration, targets code that is reachable in a project's shipped defaults even though no default functionality is meant to use it. The second, configuration interaction, looks for pairs of options that seem reasonable individually but cause problems together, such as quietly turning a security control off or leaving a feature's behaviour undefined while its code stays reachable. The third, early reachability, identifies security-sensitive or complex code that runs before a control such as authentication, without any interaction from the victim, or before a protocol state transition.

What Claude found

To test the approach, Claude first built an inventory of more than 17,000 configuration options across the 25 projects, written in C, C++, Java, PHP and Python. Of those, 3,842 governed security-relevant controls or features. The projects fell into three categories Anthropic used to contextualise results: 10 public projects built to serve any user or parse data from unidentifiable parties, 11 gated projects that withhold all functionality until the user authenticates, and 4 private projects deployed in an operator's own environment, where adding authentication is out of scope.

The gated cohort produced the most striking results. According to Anthropic, all eleven gated projects contained code that was unintentionally reachable. Claude identified 93 unnecessary pre-authentication surfaces in default configurations, 37 locations where code executed or state was recorded before authentication, and 61 configuration combinations that quietly weakened a pre-authentication control the administrator had configured. None of these issues was immediately exploitable on its own, but together they leave a far larger attack surface than necessary.

Configuration combinations were the richest vein

Across all project types, Claude found 162 security-sensitive configuration combinations that the software accepted without an error, a warning, or documentation of the expected behaviour. In 94 of those cases, the combination switched a security control off outright. The remaining 68 were internal inconsistencies: a listener or login path staying reachable even though the configuration said it was disabled, or two conflicting settings where which one wins depends on their order in the configuration file. Anthropic concedes some of these combinations may be unusual, but notes that nothing stops an administrator from deploying software configured this way.

One pattern appeared independently in four unrelated projects. An administrator writes a client access rule using a hostname or wildcard pattern rather than an IP address. Whether the server can ever learn a client's hostname depends on a separate reverse DNS option, which most of the projects ship disabled. With lookups off, the server knows only the client's IP address and ends up comparing the hostname-based rule against that address as plain text.

Why it matters

This is one of the clearer demonstrations that frontier AI models can defend software at scale, not just attack it, and Anthropic frames the results as both meaningful and cost-effective. The method also complements traditional patching rather than replacing it: it reduces the blast radius of bugs nobody has found yet, which matters for widely deployed open-source infrastructure where unknown flaws are a given. Finally, the techniques are described in enough detail that maintainers can apply similar configuration inventories and reachability audits to their own codebases without waiting for a vendor to ship it as a product.