Don't Fix Bugs, Shrink the Target: Claude Cuts the Attack Surface of OpenSSH and 24 Other Open-Source Projects

The one-liner: instead of fixing bugs one by one, make them unreachable

On October 20, 2026, Chris Rohlf of Anthropic's Frontier Red Team published Using Claude to reduce the attack surface of code, a defense-oriented AI security study with a different premise: instead of hunting individual vulnerabilities, use Claude to systematically shrink the attack surface — move code that shouldn't be exposed out of attackers' reach. Claude scanned 25 open-source projects (over five million lines across C, C++, Java, PHP, and Python) and found 493 attack-surface issues.

The headline case is OpenSSH — some of the most heavily audited C code on Earth. In release 10.4, Claude found roughly 4,500 lines of experimental post-quantum signature code (ML-DSA-44) reachable by an unauthenticated client in the default configuration — about 16% of sshd's pre-authentication code. OpenSSH 10.6 has merged the fix, removing roughly a fifth of the code reachable before authentication.

Anthropic's line to remember: "If unnecessary reachability survives there, it can survive anywhere."

Three ways to "shrink the target": default config, config interaction, early reachability

The methodology matters more than the numbers. Claude was asked to examine code through three fixed lenses:

1. Default configuration. Code reachable in the shipped defaults but unused by any default functionality. The study sorted projects into Public (serves anyone), Gated (serves authenticated users), and Private (operator's own environment) — each with a very different legitimate exposure. A lot of exposure turned out to be pure historical inertia.

2. Configuration interaction. Options that look reasonable alone but silently disable a security control in combination. The nastiest category in the study: Claude found 162 security-sensitive configuration combinations accepted silently — no error, no warning, no documented interaction behavior. In 94 of those, the combination directly turned off a security control; the other 68 were inconsistencies in the same security mechanisms.

3. Early reachability. Complex, security-sensitive code that runs before a hard gate (authentication), without user interaction, or before a protocol state transition. All eleven Gated projects had unintentionally reachable code: 93 unnecessary pre-authentication surfaces, 37 places where code executed or state was recorded before authentication, and 61 configuration combinations that silently weakened a pre-authentication control. As the post stresses, none were immediately exploitable alone — but they inflate the attack surface far beyond necessity.

To power these checks, Claude first inventoried 17,000+ configuration options across the 25 projects, 3,842 of them security-relevant — a "configuration map" many of these projects never had.

Breakdown of Claude's attack-surface findings (selected). Source: Anthropic, "Using Claude to reduce the attack surface of code" (Oct 20, 2026).

Four chilling details

Detail 1: a 21-year-old silent failure. In one project, a conflicting pair of options had coexisted for 21 years: the admin believed every client had to present a certificate, while a second option — intended only to defer the check — disabled it entirely. A server configured to accept only trusted clients therefore accepted connections from anyone. No warning; the docs never mentioned the certificate requirement was dropped.

Detail 2: fail-open hostname rules. Claude independently found the same pattern in four unrelated projects: admins wrote access rules with hostnames/wildcards, but reverse DNS lookups were off by default — so the server only ever had the client's IP. A hostname pattern can never match an IP, so deny rules never fired and the list failed open. Docs mentioned the DNS dependency; none stated the fail-open consequence.

Detail 3: TLS client certs that depend on the namespace. One project shipped with authentication off by default, expecting the admin to enable it. The TLS-client-certificate option was honored on most endpoints but silently ignored on a few that loaded TLS settings through a different namespace — a certificate-less client could complete the handshake and open a session, with nothing logged. The long setting name worked everywhere; the short form from the docs' own examples was dropped on the affected endpoints.

Detail 4: OpenSSH's fix got bypassed — twice. Release 10.5 moved the algorithm-allowlist check before parsing; Claude then found two bypasses: the check looked at the algorithm name the client advertised, but the parser was chosen by a type string embedded inside the key blob (advertise ssh-ed25519, send an ML-DSA key anyway); and on the certificate path, the embedded CA signature was fully verified before the configuration was consulted. The final fix moved the checks inside the parser itself: compare against allowlists before deserialization or verification. Shipped in 10.6.

Our take: defense's third path — and the lesson vibe coders most need

AI security news has run on two tracks: the offense track (AI agents breaching a hundred corporate sites) and the bug-hunting track (PHP2Shell, AI helping defenders find flaws). Anthropic's post opens a third: don't find the bug — shrink the target.

The philosophy is hardcore: fixing one critical vulnerability tells you nothing about the vulnerabilities that remain; removing unnecessary reachable code reduces the severity of all unknown vulnerabilities at once — including any already being quietly exploited. You can't count unknown bugs, but you can measure attack surface.

For vibe coders, the practical lessons run deep:

First, "default config" ≠ "secure config." AI-generated projects have a bad habit: scaffolds ship with admin panels, debug endpoints, and sample routes enabled, and nobody turns them off at launch. If Claude can find 93 unnecessary pre-auth surfaces in top-tier open-source code, your vibe project has more. An exposure inventory before launch is the highest-ROI security move there is.

Second, config combinations are AI's amplifier. Humans used to hand-write configs, so combinations were bounded; now AI generates dozens of env vars and feature flags in one go — combinatorial explosion. The 162 silently-accepted combos teach one rule: any security-relevant option that can be "set but not in effect" without an alert is a time bomb. Give your project an iron rule: every such option gets a self-check that screams when it's not in effect.

Third, you can run this yourself. Anthropic packaged the three-pass scan as a reusable Claude skill (headed for the free OSS-Scanner): pass one for default-config reachability, pass two for code before hard gates, pass three for control-silencing combinations — each pass starting from an empty context and confirming findings with dynamic traces. Even without the skill, the "three-pass review" works as a prompt for your own project — and a Claude Code pass beats eyeballing.

Scope note and transparency

This is news about a specific study Anthropic published on October 20; our previously published AI coding agent security piece is a guide (prompt injection, permissions, sandboxing for the agent itself) — news vs. methodology, distinguished up front. It is also distinct from OpenAI's misalignment-report series (model behavior disclosures, a different topic).

Transparency: all figures (25 projects / 493 issues / 17,000+ options / 93 / 37 / 61 / 162 / 94 / 4,500 lines / 16% / ~1/5) are Anthropic's self-reported numbers, not independently reproduced; the original post explicitly states these findings were not immediately exploitable on their own, and this piece does not inflate their severity. The OpenSSH fix shipped in 10.6 — publicly verifiable.