al-ice.ai

Parse Nothing You Haven’t Enabled: Claude Maps 493 Attack-Surface Issues Across 25 OSS Projects, OpenSSH Ships the Fix in 10.6

Agent & Supply Chain Security by al-ice.ai Editorial

On 20 October 2026, Anthropic’s Frontier Red Team published “Using Claude to reduce the attack surface of code”, and its thesis is a direct challenge to how the industry currently spends its AI-assisted security budget. Finding and fixing individual vulnerabilities scales poorly, the post argues: fixing even a critical vulnerability tells you nothing about the vulnerabilities that remain. Reducing code reachability — mapping what an unauthenticated caller can actually touch, then moving everything else behind authentication, interaction, opt-in, or deeper protocol state — reduces the severity of unknown vulnerabilities, including the ones already under active exploitation, without ever finding or fixing a single bug. To back that up, the team ran Claude over 25 open-source projects totaling over five million lines of code in C, C++, Java, PHP, and Python, and reports 493 issues across three techniques. The load-bearing exhibit is OpenSSH: roughly 4,500 lines of new post-quantum signature code reachable by any unauthenticated client in the default configuration, now gated behind allow-lists in OpenSSH 10.6 — a fix the release notes credit explicitly to Chris Rohlf “in collaboration with Claude and Anthropic Research,” which we verified first-hand in the release notes themselves.

This is the second half of a story we covered on 9 October, when Anthropic launched the Cyber Mission’s OSS Scanner — free, opt-in, fully model-generated vulnerability reports with no human review. The 8 October scanner post carries the validation numbers worth keeping next to the new findings: across 48 projects, expert reviewers judged 85 of 97 sampled critical/high-severity scanner findings (88%) worthy of coordinated disclosure; of the remaining 12, eleven were real but duplicated known issues and only one was an actual false positive. Maintainer quotes in that post are unusually strong — wolfSSL took 74 reports, called all but two valid, and turned five into CVEs; curl’s Daniel Stenberg says the scanner surfaced “one of the worst curl vulnerabilities reported in the last few years.” The October program had already scanned hundreds of projects, found over 29,000 candidate vulnerabilities, and sent nearly 5,000 unverified reports to maintainers who asked for everything. The 20 October post is the same team showing what the models can do when pointed at a different question: not “where is the bug” but “why can the attacker reach this code at all.”

The three methods, and where the bodies were

The research names three attack-surface-reduction methods and applies them systematically. Default configuration: code reachable in the shipped defaults that no default functionality needs. Configuration interaction: pairs of options that look reasonable alone but misbehave together — silently disabling a security control or leaving behavior undefined while the code stays reachable. Early reachability: security-sensitive code that runs before authentication, before user interaction, or before a protocol state transition. Claude first built an inventory of over 17,000 configuration options, of which 3,842 governed a security-relevant control or feature. Projects were sorted into Public (built to serve anyone; 10 projects), Gated (nothing until authentication; 11), and Private (operator’s own environment; 4).

The Gated cohort produced the most surprising results, which is exactly backwards from what the category promises. All eleven gated projects had unintentionally reachable code. Claude found 93 unnecessary pre-authentication surfaces in their default configurations, 37 locations where code executed or state was recorded before authentication, and 61 configuration combinations that silently weakened a pre-authentication control set by the administrator. The post is careful to say none of these was immediately exploitable on its own — they are exposure, not vulnerability — but exposure is the raw material every pre-auth exploit chain is built from, and the gated category exists specifically to deny it.

94 ways to turn off your own locks

The configuration-interaction findings are the section administrators should read twice. Claude found 162 security-sensitive configuration combinations accepted with no error, no warning, and no documentation of the interaction’s expected behavior. In 94 of those cases, the combination silently turned off a security control; the other 68 were inconsistencies in the same mechanisms — a listener or login path reachable though configured off, two conflicting settings whose winner depended on file order, a protection that did nothing while its code stayed reachable.

Two patterns deserve naming because they generalize. First, a hostname-or-wildcard access rule that fails open, found independently in four unrelated projects: the administrator writes a deny rule against a hostname pattern, but whether the server ever learns the client’s hostname depends on a separate reverse-DNS-lookup option, off in most of these projects. With lookups off, the server holds only the client IP, compares it against the hostname pattern as plain text, never matches, and the deny rule never fires. None of the four projects states the fail-open consequence; at most they document the lookup dependency. Second, a conflicting pair of certificate-identity options in which one form required every client to prove identity with a certificate while the other — intended only to delay the check — disabled it entirely, exposing the full request-handling surface to unauthenticated clients with no warning under default settings. That combination had been present for 21 years. A third case left TLS client-certificate requirements honored on most endpoints but silently ignored on endpoints loading TLS settings through a differently-namespaced path, with nothing logged — and the short setting name most examples use is the one that gets dropped. These are not parsing bugs. They are semantic gaps between what the administrator believes the configuration says and what the code does, and no fuzzer or CVE-shaped scanner is aimed at that gap.

Case study: 4,500 lines of post-quantum code, reachable by default

Measured as a share of total code, the largest attack-surface reduction Claude achieved was in OpenSSH — some of the most heavily audited C in the world, which is precisely the point the post wants to land. Tracing sshd’s input paths in the 10.4 release, Claude found roughly 4,500 lines of new, experimental ML-DSA-44 post-quantum signature code reachable by an unauthenticated client in the default configuration — about 16% of OpenSSH’s own pre-authentication code in a default sshd. ML-DSA was not enabled by default, but the code ran regardless: the daemon parsed whatever key type the client sent (and for certificates, verified the embedded CA signature) before checking whether that key type was allowed — and kept parsing even when the administrator had explicitly excluded the algorithm.

Anthropic reports the issue with patches; the 10.5 release moved the check before parsing. Claude then found two gaps in the 10.5 check: the check inspected the algorithm name the client advertised while the parser was selected by a type string embedded inside the key blob, so a client could advertise ssh-ed25519, pass the check, and still get an ML-DSA key parsed; and certificate key types enabled by default meant any client past key exchange could force deserialization and full signature verification of an attacker-supplied embedded CA public key, for any supported algorithm, before configuration was consulted. The final fix, iterated with the maintainers, places the checks inside the parser itself: encoded key type and CA signature algorithm are compared against configured allow-lists before deserialization or verification. Anthropic says this removed roughly a fifth of the code an unauthenticated client could previously reach in a default build, nearly all of it the new ML-DSA code.

We verified the vendor side of that account directly. The OpenSSH 10.6 release notes (released 6 October 2026) carry the entry verbatim: “sshd(8), ssh(1): check key and CA signature types during key parsing against allowlists (PubkeyAcceptedAlgorithms, etc) as early as possible. This reduces the attack surface presented by disabled algorithms. Suggested by and with extensive feedback from Chris Rohlf in collaboration with Claude and Anthropic Research.” The same notes add two signals worth recording: the team reports receiving a large number of AI-assisted security reports, welcomes them especially with triage and patches — and notes multiple cases where an AI-identified bug was then independently rediscovered by a different researcher, which it reads as evidence that unreported adversaries can find these bugs too. The stated response is more frequent releases to get fixes out faster rather than batching. That is a major project adjusting its release doctrine to AI-speed rediscovery — the same dynamic our brotli coverage traced through an eight-month upstream fix with no release, and the KSMBD disclosure traced through a fix reachable only in a maintainer’s for-next branch.

What defenders should take from this

Three readings, labelled as our analysis. First, the economics have inverted: exploit development that once priced “unreachable-by-default” as safe now runs against models that map reachability as a first step — Claude inventoried 17,000 options to find these. Audit your own default-reachable pre-auth code paths with the same question, especially newly added protocol or algorithm support that ships parsing before policy. Second, treat configuration combinations as a test surface, not just individual options: 94 silent control-disables across 25 projects suggests every pair of “disable”-adjacent settings deserves a negative test asserting the control still holds. Third, gate parsing behind allow-lists as a pattern, not a patch: the OpenSSH fix checks the type string before deserialization, which generalizes to any daemon that parses attacker-shaped blobs before consulting policy.

The honest limitation is stated in the post itself and should travel with it: attack-surface reduction does not remove unknown vulnerabilities, it makes them harder to reach. The 493 issues are exposure findings, most not individually exploitable, and the projects are unnamed — so unlike the OSS Scanner’s CVE-producing pipeline, there is nothing here to match against your own inventory. What travels instead is the method and the existence proof: if unnecessary pre-auth reachability survives in OpenSSH, in the words of the post, “it can survive anywhere” — and the team that proved it will now, via the opt-in scanner, run its strongest models against your codebase if you ask.

Our verification was read-only and external. The 20 October 2026 attack-surface-reduction post (Frontier Red Team, Chris Rohlf) and the 8 October 2026 OSS Scanner launch post were read in full first-hand: the 493-issue / 25-project / 5M-LOC figures, the 17,000-option inventory with 3,842 security-relevant, the 10/11/4 Public/Gated/Private split, the 93/37/61 gated-cohort counts, the 162-combination / 94-control-disable / 68-inconsistency interaction figures, the four-project fail-open hostname pattern, the 21-year cert-check conflict, the namespaced TLS-endpoint gap, and every ML-DSA/OpenSSH detail including the two 10.5-check gaps and the in-parser fix were taken from Anthropic’s text. The OpenSSH 10.6 release notes (2026-10-06) were read first-hand, confirming the allow-list check entry crediting Rohlf/Claude/Anthropic Research and the AI-report rediscovery language. Scanner validation figures (85/97 CVD-bar, 11 duplicates, 1 invalid; 29,000 candidates; ~5,000 bulk reports) and maintainer quotes are Anthropic’s published claims, attributed not reproduced. We ran no scanner, wrote no exploit, contacted no maintainer, and tested no system.

Sources: