Anthropic: Claude found 493 attack-surface issues across 25 open-source projects, led by OpenSSH fixes

Anthropic used Claude to analyze 25 open-source projects and found 493 attack-surface issues. The largest result was in OpenSSH, where the work led to fixes in versions 10.5 and 10.6. The company published the early results on October 20 (US time), according to Japanese-language outlet ITmedia, which reported on the research on October 22. The post was written by Chris Rolf of Anthropic's Frontier Red Team, which handles AI risk assessment (name rendered from the Japanese katakana in the ITmedia article).

The approach

Attack surface is the range of code an external attacker can reach. Anthropic says finding and fixing vulnerabilities one at a time does not scale: fixing one serious flaw reveals nothing about the rest. The alternative is to shrink what attackers can reach, for example by moving features that do not need to be exposed behind authentication or disabling them by default. According to Anthropic, this makes undiscovered vulnerabilities harder to exploit and lowers their severity.

Scope and findings

Claude analyzed 25 open-source projects written in C, C++, Java, PHP, Python and other languages, totaling more than 5 million lines of code. Of the configuration items it identified, 3,842 were security-relevant. The analysis examined three questions:

• Can unnecessary code be reached from outside under default settings?
• Are there settings that cause problems when combined?
• Does complex processing run before authentication or similar checks?

The analysis produced 493 issues in total. Key results:

• Authentication-dependent projects: In all 11 projects that assume authentication, Claude found code that was unintentionally reachable from outside.
• Silent misconfigurations: 162 setting combinations were accepted with no error or warning. In 94 of them, a security feature was unintentionally disabled.
• Certificate check bypass: In one case, combining a setting that requires client-certificate authentication with another setting dropped the certificate check, allowing anyone to connect. This inconsistency had persisted for 21 years.

Rolf says none of these is immediately exploitable on its own, but each widens the entry points more than necessary.

OpenSSH

The biggest result came from OpenSSH. In version 10.4, about 4,500 lines of experimental code for the post-quantum signature scheme ML-DSA-44 were reachable by pre-authentication clients. The scheme is not enabled by default, and the code stayed reachable even when an administrator explicitly excluded it. Those roughly 4,500 lines amount to about 16% of the code that runs before authentication in a default OpenSSH configuration.

Anthropic reported the issue to OpenSSH developers with a proposed fix, and version 10.5 addressed it. Claude then found two ways around the 10.5 mitigation. After further iteration with the developers, about one fifth of the code reachable by pre-authentication clients was removed, and that fix shipped in version 10.6. OpenSSH 10.6 was released on October 6.

Rolf notes that OpenSSH is among the most carefully audited codebases in the world. Because unnecessary reachable paths remained even there, he says they can remain anywhere.

Packaged as a reusable skill

Anthropic is packaging the method as a reusable "skill" and working to integrate it into OSS Scanner, its vulnerability discovery service for open source. The skill runs the three analyses in order and verifies each finding by running the program. For fixes involving default settings, it runs the project's tests to confirm default behavior does not change. Changes that affect non-default behavior are left to human judgment by design.

What this means

The research shifts the question from "where are the bugs" to "what does an unauthenticated attacker need to reach at all." The OpenSSH case shows the practical value: Claude flagged experimental, default-off code that was still reachable before authentication, and the resulting changes shipped upstream in two releases. The design choice to verify findings by execution, run project tests for default-setting fixes, and defer non-default changes to humans addresses the risk that automated hardening alters existing behavior. Anthropic describes these as initial results, and no timeline for the OSS Scanner integration has been stated.