Anthropic used Claude to cut OpenSSH's pre-login attack surface and report 493 issues in 25 open-source projects

Anthropic's Frontier Red Team has published research on using Claude to shrink the attack surface of software, not just to hunt individual bugs. Across 25 open-source projects and more than 5 million lines of code, the team says it found 493 issues, from deny rules that silently never match to code that unauthenticated users could reach in a default configuration. The most concrete result is in OpenSSH, where the work led to roughly one-fifth of the code an unauthenticated client could previously reach in a default build being removed from that path. The post is Anthropic's own description of its work, and it is explicitly "initial research", so several numbers cannot be checked independently.

Key points

• Anthropic's post of 20 October 2026, by Chris Rohlf of its Frontier Red Team, describes using Claude to map and reduce what code a deployment exposes, across 25 open-source projects and more than 5 million lines in C, C++, Java, PHP and Python.
• Claude catalogued over 17,000 configuration options, of which 3,842 were security-relevant, and Anthropic reports 493 issues in total.
• In OpenSSH, about 4,500 lines of experimental ML-DSA-44 (post-quantum signature) code were reachable by unauthenticated clients in a default sshd, which Anthropic puts at roughly 16% of the default pre-authentication code.
• OpenSSH's own release notes credit Chris Rohlf for fixes in 10.5 (11 August 2026) and in 10.6, and say the project is receiving many AI-found reports, which is why it will release more often.
• Anthropic gives no false-positive rate and does not say how many of the 493 issues were reported or fixed outside OpenSSH.

What happened

Most AI-security work to date has focused on finding vulnerabilities: point a model at code, get a bug. Anthropic's post argues for a different target. Instead of finding and fixing each flaw, ask which code a deployment exposes at all, and remove or restrict whatever the deployment does not need. If a bug sits in code that an attacker cannot reach, its severity falls, including for bugs nobody has found yet.

The team ran three kinds of analysis. The first looks at code reachable in the shipped default configuration that no default functionality needs. The second looks at configuration interactions: pairs of options that are reasonable alone but, together, do something like silently switch off a security control. The third looks at early reachability, meaning complex or security-sensitive code that runs before authentication, before any victim interaction, or before a protocol reaches a later state.

The 25 projects were grouped by who they serve. Ten are "public" (they serve any reachable user or consume data from unknown parties), eleven are "gated" (they serve authenticated users, with no functionality before login), and four are "private" (they serve an operator's own environment, with authentication optional and outside the software's scope).

Anthropic reports that all 11 gated projects had code that was reachable without authentication when it was not meant to be. In those projects it counts 93 unnecessary pre-authentication surfaces in default configurations, 37 places where code ran or state was recorded before authentication, and 61 configuration combinations that silently weakened a pre-authentication control. It notes that this reachable code was a small share of each project's total lines, and that many of the gated-project findings would not be immediately exploitable on their own.

On configuration interactions, Claude found 162 security-sensitive option combinations that the software accepted without any error, warning or documentation. Of those, 94 silently disabled a security control and 68 were inconsistencies, such as a listener that stayed reachable after being configured as disabled, or a setting whose effect depended on the order of lines in a file.

type: bar
title: Configuration-option combinations accepted silently, by outcome
unit: combinations
source: Anthropic, "Using Claude to reduce the attack surface of code" (20 Oct 2026)
Silently accepted in total | 162
Silently disabled a security control | 94
Inconsistencies (e.g. disabled listener still reachable) | 68

Three specific patterns stand out. A hostname-based deny rule never matches when reverse DNS lookups are off, which is the usual setting, so the deny list quietly fails open; Anthropic says this pattern appeared in four unrelated projects. In one project an option meant to delay a client-certificate check actually disabled it entirely, and Anthropic says that had been the case for 21 years. In another case a client-certificate requirement was ignored on some endpoints because of a difference in configuration namespaces.

Background

Attack-surface reduction is an old idea in security engineering: turn off what you do not use. OpenSSH is a well-known example of the habit. The project's 10.6 coverage notes that OpenSSH 10.0 moved user-authentication code into a separate binary so the crucial pre-authentication code lives in its own address space, as reported by Help Net Security.

What is new is the idea of using a language model to do the tedious cross-referencing: reading thousands of options, tracing which code paths they gate, and checking combinations no human would try. It arrives while maintainers are already feeling the effect of AI-assisted bug hunting. The OpenSSH release notes for 10.5 and 10.6 both say the team has received many security reports from AI models or AI-assisted work, that many have no security impact under a realistic threat model, and that AI-found bugs have been independently rediscovered by other researchers. As a result the team will make more frequent releases rather than batching fixes. The notes welcome such reports, especially with human triage, test cases or proposed fixes.

How it works

Anthropic describes a reusable "skill" that runs three passes, each starting with a fresh context window plus a short carry-over from the previous pass: default-configuration reachability, code running before hard gates or protocol-state transitions, and configuration combinations that disable or weaken controls. Findings are confirmed with dynamic traces. A change that touches only default configurations must pass the project's test suite and a black-box regression suite with identical results. Changes that would affect non-default configurations are left for a human to decide. Anthropic says it is working to integrate the approach into OSS-Scanner.

The OpenSSH case study

OpenSSH 10.4 (released 6 July 2026, according to the OpenSSH release notes) added experimental support for a composite signature scheme combining ML-DSA-44 and Ed25519, off by default. Anthropic says Claude found about 4,500 lines of that experimental code that an unauthenticated client could reach in the default sshd configuration, roughly 16% of OpenSSH's pre-authentication code in a default build. Anthropic reported it with patches.

OpenSSH 10.5 (11 August 2026 per the release notes) added a check of the public-key type against allowed algorithms before parsing the peer's key, which the notes say removes "at least some key parsing and verification paths" from the pre-authentication attack surface. Anthropic says its follow-up review found two gaps: the check trusted the algorithm name the client advertised rather than the key type embedded in the key, and the certificate CA signature path was not gated. The final fix, Anthropic writes, moved checks inside the parser so key types and CA signature algorithms are compared against allow lists before deserialisation or verification, removing about a fifth of the code an unauthenticated client could previously reach in a default build. The release notes credit fixes to Chris Rohlf in 10.5 and to Rohlf "in collaboration with Claude and Anthropic Research" in 10.6.

One thing to note: Anthropic's account places the final changes in release 10.6, while the 10.6 notes we read list no explicit pre-authentication change and say 10.6 enables ssh-mldsa44-ed25519 by default, dropping the @openssh.com suffix, so users must regenerate keys made under the experimental support (Help Net Security). We read only part of the very long notes page, so we cannot say where each change landed; check the release notes for your version.

What it means

For maintainers, the lesson is that configuration is part of the attack surface. Bugs like "this option silently does nothing" or "this deny rule never matches" are not memory-safety flaws and do not show up in fuzzers, yet they can turn a hardened-looking setup into an open one. A deny list that fails open when reverse DNS is off is the kind of thing an administrator would never notice.

For administrators, the practical takeaway is to re-read security-relevant options after upgrades, to prefer allow lists over deny lists, and to test that a control actually blocks what you think it blocks.

For the wider industry, the work is a reminder that AI-assisted security has two sides. The same models that surface bugs for attackers can be pointed at the structure of a program, and the OpenSSH maintainers say attackers who do not report bugs "are likely to be able to discover these bugs too", as relayed by Help Net Security. Reducing reachability is a defence that does not depend on winning that race.

What we don't know yet

• How many findings are real. The post gives no false-positive or validation rate and no per-project breakdown beyond category counts.
• How many were fixed. Apart from OpenSSH, Anthropic does not say how many of the 493 issues were reported to maintainers or fixed.
• Which projects. The post groups the 25 projects by category; the list of names and the individual fixes outside OpenSSH are not in the material we read.
• Whether the method works without the skill. Anthropic says the methodology is likely effective without its packaged skill but provides no separate evidence.
• Release placement. As noted, the exact release in which each OpenSSH change landed differs between Anthropic's telling and the release notes we read.

What to watch next

Watch for the packaged skill appearing in OSS-Scanner, for named fixes in other projects, and for OpenSSH's promised faster release cadence. Also watch whether other vendors publish comparable numbers with false-positive rates, which would let readers judge how much of the 493 is signal.

Sources

• Anthropic, Using Claude to reduce the attack surface of code (primary source)
• OpenSSH, release notes
• Help Net Security, OpenSSH 10.6 enables a post-quantum signature algorithm, so experimental keys need replacing