AI security

On October 20, Anthropic's Frontier Red Team published research in which its own model, Claude, reviewed 25 open-source projects (more than five million lines of C, C++, Java, PHP and Python) and flagged 493 attack surface issues. The research comes from the AI vendor itself, the results have not been independently tested, and Anthropic does not name most of the projects. It also says that most findings are not exploitable vulnerabilities on their own: they are code that runs when it does not need to, or settings that quietly do less than the administrator thinks.

The one project the research names is OpenSSH. On versions 10.4 and 10.5, about 4,500 lines of experimental post-quantum signature code could be reached by unauthenticated clients, even on servers where the administrator had excluded the algorithm. OpenSSH 10.6, released on October 6, closes that gap. The other findings are a checklist for any service where you rely on a configuration option to switch something off.

What the study looked for

Attack surface reduction does not hunt for individual bugs. It asks which code an attacker can reach, and removes or gates the code that a given deployment does not need. A bug in code an unauthenticated client cannot reach is far less severe than the same bug sitting in the login path.

Claude worked in three passes, each with a fresh context. The first looked for code reachable in the shipped default configuration that no default feature uses. The second looked for complex or sensitive code that runs before a hard gate such as authentication, or before a protocol reaches the right state. The third looked for pairs of options that are reasonable alone but weaken a control together. Anthropic says each finding was confirmed with a dynamic execution trace, and any proposed gate that changed non-default behaviour went to a human.

The findings

Anthropic grouped the projects as 10 public services, 11 gated services meant for logged-in users and 4 private operator tools. All 11 gated projects had code reachable before login. Claude counted 93 unnecessary pre-authentication surfaces in default configurations, 37 places where code ran or state was recorded before authentication, and 61 option combinations that silently weakened a pre-authentication control. Anthropic stresses that none of these was immediately exploitable alone, and that the unneeded code was a small share of each project.

Of 3,842 security-relevant options, Claude found 162 combinations that the software accepted with no error, no warning and no documentation. In 94 of them, a security control was silently disabled. The other 68 were inconsistencies: a listener that stayed reachable after being disabled, settings whose precedence depended on their order in the file, or a protection that did nothing while its code stayed reachable.

Anthropic describes three of them without naming the projects:

• In four unrelated projects, access rules could name hosts or wildcards, but resolving names depended on a reverse DNS option that most of them had off. With lookups off the server only has the client's IP address, a hostname pattern never matches an IP, and the deny list fails open.
• In one project, an option required every client to present a certificate. A second option, meant only to delay that check, disabled it. Together they were accepted without warning, so a server set up to trust only known clients accepted anyone. The two options had coexisted for 21 years.
• In another, a client certificate option was honoured on most endpoints but dropped on a few that read TLS settings from a different configuration namespace. The short form of the setting, used in most examples, was the one ignored, and unauthenticated clients could open sessions there with nothing logged.

The OpenSSH case

OpenSSH 10.4 added experimental support for ML-DSA-44, a post-quantum signature algorithm, in about 4,500 new lines. It was not enabled by default. But when a client offered a public key during authentication, sshd parsed whatever key type the client sent, and for certificates verified the embedded certificate authority (CA) signature, before checking the type against PubkeyAcceptedAlgorithms. Anthropic puts that new code at about 16% of the pre-authentication code in a default sshd.

The first fix, in OpenSSH 10.5 (August 11), moved the check ahead of parsing. Claude then found two gaps. The check compared the algorithm name the client advertised, while the parser was chosen by a type string inside the key itself, so a client could announce ssh-ed25519 and still send an ML-DSA key. And certificate key types, enabled by default, still had their CA public key decoded and its signature verified before configuration was consulted, which left every signature verifier in the binary reachable by any client that completed key exchange.

OpenSSH 10.6 puts the check inside the parser: the key type and the CA signature algorithm are compared with the configured allow lists before anything is decoded or verified. The 10.5 and 10.6 release notes credit Chris Rohlf of Anthropic with the changes. Anthropic says the result removes roughly a fifth of the code an unauthenticated client could reach in a default build. The release notes list no CVE for these changes, and neither OpenSSH nor Anthropic describes an exploitable bug in the ML-DSA code. The 10.6 notes also credit the same work with a configuration fix: options that accept none, such as AuthorizedPrincipalsFile, treated it as a literal file name when set inside a Match block.

What to do

For OpenSSH:

1. Run sshd -V and ssh -V. Upstream 10.6 is the fixed release; on distribution packages, check your vendor's advisories, since fixes are often backported without a version change.
2. Before upgrading from 10.4 or 10.5, remove any ssh-mldsa44-ed25519@openssh.com entries from sshd_config and sshd_config.d. 10.6 renamed the algorithm, and an unknown name in the config stops sshd from starting. Our OpenSSH 10.6 post covers the key cleanup.
3. Check the configuration sshd actually uses, not the one in the file. sshd -T prints the effective settings, and sshd -T -C user=alice,addr=203.0.113.10,host=jump.example.com shows the result after Match blocks apply for that connection. sshd uses the first value it reads for most keywords, so a line in an included file can silently override one further down.
4. If you use from="hostname" in authorized_keys or Match Host, check UseDNS. It defaults to no, and the sshd_config manual says only addresses, not host names, may be used in those places while it is off. Replace hostname rules with addresses or CIDR ranges.

For every other service you run, test what the configuration claims, because in the 94 silent cases nothing at startup or in the logs said a control was off. When a feature, listener or algorithm is switched off, connect and confirm it really refuses: scan the port from outside, send a request for the disabled feature, and confirm the server rejects it before doing any work. Where a client certificate is required, try a connection without one on every endpoint, not only the main one. Wherever a deny list names hosts, confirm reverse DNS lookups are on, or rewrite the rules with IP addresses.

For maintainers, Anthropic's suggestions are specific. Check allow lists before parsing input, not after. Reject or warn at config load when two options conflict, and document how they interact. Make sure every endpoint reads security settings from the same place. Anthropic says it has packaged the three passes as a Claude skill and is working to add it to OSS-Scanner, its free, opt-in scanning service for open-source projects.

We test this kind of gap in network penetration testing and review exposed services and their settings in attack surface management. If you want a second pair of eyes on your SSH or service configuration, open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Anthropic: Using Claude to reduce the attack surface of code, OpenSSH release notes, sshd_config manual, sshd manual, Help Net Security, The Next Web, Mallory.