Claude found 4,500 lines of OpenSSH code reachable before login, and the fix shipped in 10.6

What Anthropic found in OpenSSH

Anthropic says Claude found about 4,500 lines of experimental post-quantum signature code in OpenSSH that any client could reach before logging in, even on servers that had switched the algorithm off. In a 20 October research post from its Frontier Red Team, written by Chris Rohlf, the company describes using Claude to map which code an attacker can touch and then move unneeded code behind a security check. OpenSSH shipped the resulting fix in version 10.6 on 6 October.

The code implemented ML-DSA-44, a post-quantum signature algorithm. It was new and experimental in OpenSSH 10.4 and not enabled by default. But according to Anthropic, the SSH daemon parsed whichever key type a client sent, and for certificates also verified the embedded certificate authority signature, before it checked whether that key type was allowed. That held even when an administrator had explicitly excluded the algorithm.

Anthropic says those 4,500 lines made up about 16% of OpenSSH's own pre-authentication code in a default sshd. "There is no good reason for this complex, memory unsafe code to be reachable when it hasn't been enabled by the configuration," the post says. No vulnerability in the ML-DSA code itself is described; the concern is that any future bug there would have been reachable by anyone on the network.

How the fix took two releases

Anthropic reported the issue with patches, and OpenSSH 10.5, released on 11 August, moved the allowed-algorithm check ahead of key parsing. The 10.5 release notes say this "removes at least some key parsing and verification paths from the pre-auth attack surface" and credit Christopher Paul Rohlf of Anthropic. The same release fixed double frees in ssh-keygen, also credited to Rohlf, which the notes say were impossible to reach outside a test harness.

Claude then found two gaps in the 10.5 check. The first was a mismatch between what a client claimed and what it sent: the check looked at the algorithm name the client advertised, but the parser was chosen by a type string inside the key data. A client could advertise ssh-ed25519, pass the check and still have an ML-DSA key parsed. The second involved certificates, which are enabled by default. Given an attacker-supplied certificate, sshd would decode the embedded CA public key and run a full signature verification with it, for any supported algorithm, before consulting its configuration. Anthropic says that made every public-key signature verifier in the binary reachable by any client that completed a key exchange.

Anthropic built a proof of concept and worked through several iterations of a fix with the maintainers. The final change, listed in the OpenSSH 10.6 release notes, checks key and CA signature types against the configured allow lists "during key parsing ... as early as possible," and credits Chris Rohlf "in collaboration with Claude and Anthropic Research." Anthropic says the fix removed roughly a fifth of the code an unauthenticated client could previously reach in a default build, almost all of it the ML-DSA code.

Release 10.6 also turned the hybrid ssh-mldsa44-ed25519 algorithm from an experimental vendor extension into a standard name, telling users that keys made with the old experimental support must be regenerated. Certificates signed with an allowed CA algorithm are still parsed and verified, Anthropic notes; the difference is that the check now runs first.

The wider study: 25 projects and 493 issues

OpenSSH was one of 25 open-source projects Anthropic analysed, together more than five million lines of code in C, C++, Java, PHP and Python. Claude built an inventory of over 17,000 configuration options, of which 3,842 related to a security-relevant control or feature, and reported 493 issues in total. Anthropic does not name the other 24 projects.

It sorted the projects into three groups: public software meant to serve anyone, such as a DNS resolver; gated software meant only for authenticated users; and private software for an operator's own environment. All eleven gated projects had code that was unintentionally reachable before login. In that group Claude found 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. Anthropic says none was immediately exploitable on its own.

The most striking findings came from configuration interactions. Claude found 162 security-sensitive option combinations that software accepted without an error, a warning or documentation of how they interact. In 94 of them, the combination silently turned off a security control. One pair, in which a setting meant to delay a client certificate check actually disabled it, had been present for 21 years, meaning a server configured to accept only trusted clients would accept anyone.

A pattern that failed open in four projects

One mistake turned up independently in four unrelated projects. An administrator writes an access rule using a hostname or wildcard pattern instead of an IP address. Whether the server ever learns a client's hostname depends on a separate reverse-DNS option, which most projects leave off. With lookups off, the server compares the hostname rule against a bare IP address as text, which can never match. A deny rule therefore never fires and the list fails open.

Some of the projects document that hostname rules need DNS lookups, Anthropic says, but none says that a deny list written this way lets everyone through. In another project, an option requiring TLS client certificates was honoured on most network endpoints but silently ignored on a few, depending on which form of the setting name an administrator used, and nothing was logged.

Shrinking code instead of hunting bugs

Anthropic's argument is that shrinking reachable code is a better use of AI than hunting bugs one at a time. Fixing a single vulnerability says nothing about the ones that remain, while moving code behind authentication lowers the severity of every unknown bug in it at once, including any already being exploited. That framing contrasts with the company's OSS Scanner bug-report service, launched on 8 October, which sends model-found vulnerability reports to projects that opt in.

Anthropic says it has combined the techniques into a reusable Claude skill that it is working to add to OSS Scanner. The skill runs three passes, each starting with a fresh context: code reachable in the default configuration but unused, code that runs before authentication or protocol state checks, and option combinations that weaken a control. Each finding is confirmed with a dynamic trace. For default-configuration findings, Claude writes a gate and runs the project's own tests plus a black-box regression suite, requiring identical results; any change that would alter non-default behaviour is left to a human.

What OpenSSH says about AI reports

The OpenSSH maintainers have their own view of the AI wave. Both the 10.5 and 10.6 release notes say the team has received "a large number of security bug reports, many of which are findings from AI models or made with AI assistance," many of which turn out to have no security impact under a realistic threat model. They welcome such reports, especially with human triage, test cases and proposed fixes, and say they will make more frequent releases because bugs found by AI tools are often rediscovered independently, suggesting attackers can find them too. Other projects have reacted more sharply: curl is moving low and medium severity reports into public issues to cope with the volume.

The OpenSSH work fits that preferred pattern: a human researcher at Anthropic using Claude, reporting with patches and iterating with maintainers over two releases, rather than sending raw model output.

Limits and open questions

The figures are Anthropic's own. It has not published the list of projects, the individual findings beyond OpenSSH, how many of the 493 issues maintainers accepted, or how much the analysis cost, though it says the approach is economical. It also does not say which Claude model it used. The OpenSSH release notes confirm the changes and Anthropic's role, but not the 4,500-line or 16% measurements.

Attack surface reduction also has limits Anthropic acknowledges: it makes vulnerabilities harder to reach rather than removing them, and some reachable code is meant to be reachable. The company's broader security work, from automated red-teaming to models that find flaws faster than companies can patch them, has pushed firms such as Bank of America to hire extra contractors for patching.

Why it matters

OpenSSH is among the most audited C code in the world, and it still shipped thousands of lines of experimental parsing code that any client could reach before a configuration check. "If unnecessary reachability survives there, it can survive anywhere," Anthropic writes.

For administrators the practical step is simple: OpenSSH 10.6 includes the fix, and the configuration findings are a reminder to check that hostname-based deny rules and certificate requirements actually do what they appear to. For defenders more broadly, the post argues that AI can make software safer without finding a single bug, by trimming what attackers can touch.