Claude Attack Surface Reduction: 493 Issues in 25 Projects, and 4,500 Unneeded Lines in OpenSSH

Anthropic has published a research post arguing that the cheapest way to make software safer is not to find more bugs, but to make fewer of them reachable. In Using Claude to reduce the attack surface of code, security researcher Chris Rohlf reports that Claude analyzed 25 open-source projects, more than five million lines of code, and flagged 493 attack surface issues. The headline case study: about 4,500 lines of experimental post-quantum signature code in OpenSSH that an unauthenticated client could reach even though the feature was off.

This is a preview of data, not a product launch, and every number below is Anthropic's own, from a single vendor-authored post. The OpenSSH fixes, however, are public in the project's release line, which makes this one of the more checkable AI-for-defense claims of the month.

TL;DR

What is attack surface reduction?

Anthropic defines it as using AI models to map the code that is reachable, then removing or restricting access to anything a given deployment does not need to expose. Patching one critical vulnerability, the post argues, "tells you nothing about the vulnerabilities that remain." Reducing reachability works on the vulnerabilities nobody has found yet, including ones that may already be exploited quietly.

Concretely, the technique moves code behind a better 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 deeper in its state machine. Software accumulates abstraction layers, dependencies and features over time, and attackers win by studying what the code does in practice rather than what its authors intended.

This sits next to Anthropic's other defensive work. If you have followed the Anthropic OSS-Scanner offer of free AI vulnerability scans for open-source maintainers, this research is the methodology piece: where that program finds bugs, this one shrinks what attackers can touch.

The three methods Claude used

Anthropic focused on three ways to find unnecessary exposure:

1. Default configuration. Code reachable in the shipped default setup that no default functionality uses.
2. Configuration interaction. Option pairs that seem fine alone but, together, silently disable a security control or leave a feature's behavior undefined while its code stays reachable.
3. Early reachability. Security-sensitive, complex code that runs before a control such as authentication, without victim interaction, or before a protocol state transition.

The team also sorted the 25 projects into three cohorts to make results interpretable: 10 Public projects (built to serve anyone who can reach them, like a DNS resolver parsing upstream answers), 11 Gated projects (authenticated users only) and 4 Private ones (operator-internal, where adding authentication is outside the software's scope). You would expect a Public project to expose a lot by default; you would not expect that of a Gated one.

What did Claude find?

Claude first built an inventory of more than 17,000 configuration options across the projects, of which 3,842 related to a security-relevant control or feature. Then it found 493 issues. Anthropic highlights these themes:

• Every gated project had unintentionally reachable code. All eleven did, though never a large percentage of any project's lines. In the gated cohort Claude found 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-authentication control. Anthropic stresses that none was immediately exploitable alone.
• Configuration interactions were the most impactful. Claude found 162 security-sensitive combinations accepted without an error, a warning or any documentation. In 94 of them the combination silently turned off a security control. The other 68 were inconsistencies, such as a login path staying reachable though configuration said it was disabled, or two settings whose precedence depended on their order in the file.
• A fail-open deny list pattern appeared independently in four projects. An administrator writes an access rule using a hostname or wildcard. Whether the server ever learns the client's hostname depends on a separate reverse DNS option, usually off. With lookups off the server compares the pattern to a bare IP address, a hostname pattern can never match an IP, so a deny rule never fires. Some documentation mentions the DNS dependency, but none says a deny list written this way fails open.
• A 21-year-old conflict. In one project, requiring every client to present a certificate, combined with an option meant only to delay that check, disabled the check entirely. A server configured to accept only trusted clients would accept anyone, exposing a large body of request handling code. The combination was accepted with no warning under default settings, and had been present for 21 years.
• A namespace trap. In another project, a TLS client-certificate option was honored on most endpoints but silently ignored on a few that loaded TLS settings through a path with a different namespace. One spelling of the setting works everywhere; the shorter form that most examples use is dropped on the affected endpoints, with nothing logged.

The theme is mundane but important: much real-world insecurity is a config file doing something its author did not expect, not a memory-corruption exploit.

Case study: OpenSSH and ML-DSA-44

The project where Claude achieved the largest reduction as a share of total lines of code was OpenSSH, a codebase the post calls high quality and heavily audited. Claude traced the daemon's input paths in the 10.4 release and found roughly 4,500 lines of new, experimental code for ML-DSA-44, a post-quantum signature algorithm, that an unauthenticated client could reach in the default configuration.

ML-DSA was not enabled by default, but the code ran regardless, even when an administrator explicitly excluded the algorithm. The daemon parsed whichever key type the client sent and, for certificates, verified the embedded CA signature. Only afterward did it check whether that key type was allowed. Anthropic's words: "There is no good reason for this complex, memory unsafe code to be reachable when it hasn't been enabled." Those 4,500 lines are about 16 percent of OpenSSH's own pre-authentication code in a default sshd.

The fix took three rounds, according to the post:

1. Report and patch. Anthropic reported the problem with patches, and the 10.5 release moved the allow-list check ahead of parsing.
2. Gap one: the client's claim versus its payload. The 10.5 check looked at the algorithm name the client advertised, but the parser was chosen by a type string inside the key blob. A client could advertise ssh-ed25519, pass the check, and still send an ML-DSA key to be parsed.
3. Gap two: certificates. Certificate key types were enabled by default, so for an attacker-supplied certificate sshd would deserialize the embedded CA public key and run full signature verification for any supported algorithm before consulting configuration. The user key path was gated behind the allowed public keys; the CA path was not, so every public-key verifier in the binary was reachable by any client that completed key exchange. Anthropic built a proof of concept and iterated on a fix with the maintainers, which now compares the encoded key type and the certificate's CA algorithm against the configured allow lists before deserialization or verification.

The final change removed roughly a fifth of the code an unauthenticated client previously could reach in a default build, nearly all of it the new ML-DSA code. Per Anthropic, the maintainers shipped these changes in version 10.6. Release notes are on the OpenSSH site; check them yourself before relying on the version numbers, since this article cites them from Anthropic's post.

How the reusable Claude skill works

Anthropic combined the techniques into one reusable skill and says it is working to integrate it into OSS-Scanner. It runs three passes, each starting with an empty context window plus a short note from the prior pass:

In every pass Claude inventories entry points and confirms each finding with a dynamic trace of the program. For default-configuration findings it designs and implements a gate, then runs the project's own test suite and a black-box regression suite against the baseline, requiring identical results. Any gate that would change a non-default configuration is set aside for a human. For the other two passes it proposes edits such as reordering a check, adding a state-ordering guard, or rejecting a bad combination at config load.

The fresh-context design matters: it keeps one pass's assumptions from contaminating the next, a pattern familiar from the multi-pass agent setups covered in Armadin's AI attack swarms, where the same tooling logic runs on the offensive side.

Why this matters

Anthropic's earlier cyber posts mostly showed what models can break. This one shows the defensive mirror, and the economics are the point: the post's argument is that a defender who removes unneeded reachability reduces risk from all unknown bugs at once.

• For maintainers: the cheapest wins are not exotic. Check what code runs before authentication, and what happens when two security options are set together.
• For platform and security teams: Anthropic suggests Claude can also compare runtime logs with configuration to disable unused parsers, legacy protocols and dashboards at little cost.
• For the debate on AI-found bugs: maintainers are already strained by machine-generated reports, as in the Google open-source bug bounty freeze over AI slop reports. Here the output is a patch plus test-suite evidence, a closer fit for what maintainers can use.
• For AI code review generally: the Postgres 19 delay tied to AI code review findings shows maintainers will act on credible AI findings, at a cost.

Claimed versus verified

Two caveats worth stating plainly: the post discloses no false-positive rate, and it notes that some flagged combinations may be non-standard in practice, though nothing stops an administrator from deploying them. Treat the 493 as findings, not confirmed vulnerabilities.

What to do with this today

1. Audit pre-authentication code paths in anything you expose to the internet; ask what executes before a user proves identity.
2. Test option pairs. For security controls, write a config-matrix test that sets them together and asserts the control still fires.
3. Reject silently conflicting settings at load time, with an error rather than a precedence rule.
4. Verify deny lists end to end. If a rule uses hostnames, confirm reverse DNS is actually on, or use IP ranges.
5. If you run coding agents on your own repos, treat their config as attack surface too; the same logic that finds reachable parsers finds over-permissive agent permissions. AgentBeam, built by the explainx.ai team, stops AI agents before they take dangerous actions.

For related Anthropic defensive programs see the cyber verification program tiers tied to Glasswing and the mission-critical infrastructure defense program with 11 partners. For how fast AI-found bugs turn into exploits, read VulnCheck's exploit-rate analysis.

Related reading

• Anthropic OSS-Scanner free scans for maintainers
• Anthropic cyber verification program and Glasswing
• Anthropic mission-critical infrastructure defense program
• VulnCheck on AI-found bugs and exploit rates
• Armadin AI attack swarms
• Google OSS VRP freeze over AI slop reports
• Postgres 19 delayed by AI code review findings

Details reflect Anthropic's October 20, 2026 post and may change as the research expands; check OpenSSH release notes for current version behavior.