Anthropic finds 94 cases where open-source projects drop security controls without warning

Software can expose complex functionality to unauthenticated users even when that functionality is disabled or unnecessary. Anthropic’s Frontier Red Team used Claude to examine 25 open-source projects and reported 493 issues involving unnecessary exposure, conflicting settings, and code running before security checks.

Attack surface reduction means limiting the parts of software an attacker can reach. Instead of waiting to discover a vulnerability, developers can restrict access to unnecessary features or move security checks ahead of complex processing.

Unnecessary exposure and conflicting security settings

The research focused on three types of exposure: code reachable under default settings despite serving no intended default functionality, combinations of settings that weaken protections, and security-sensitive or complex code that runs before an appropriate security check, user interaction, or protocol state transition.

A breakdown of issues discovered per category for each technique. (Source: Anthropic)

All 11 projects intended to restrict functionality to authenticated users contained code that was unintentionally reachable before authentication. Anthropic said the findings in this group were not immediately exploitable on their own, but increased the attack surface available to potential attackers.

Configuration interactions produced some of the most significant findings. Across the projects, Claude identified 162 security-sensitive configuration combinations accepted without errors, warnings, or documentation explaining their combined behavior. In 94 cases, the settings silently disabled security control.

In four unrelated projects, hostname-based access rules depended on a separate setting for reverse DNS lookups. With lookups disabled, the server compared the hostname rule against the client’s IP address. Hostname-based deny rules therefore failed to match, allowing connections that administrators intended to block.

In another example, two settings caused a server configured to require client certificates to accept connections from anyone. Administrators received no warning that the certificate requirement had been dropped. According to Anthropic, the conflicting options had existed in the software for 21 years.

“These techniques don’t remove the unknown vulnerabilities in the code, but they do make the vulnerabilities harder to reach,” wrote Anthropic’s Chris Rohlf.

Reducing OpenSSH’s attack surface

In OpenSSH, which provides secure remote access, Claude identified roughly 4,500 lines of experimental cryptographic code that unauthenticated clients could reach, even when administrators had explicitly excluded the algorithm.

The code implemented ML-DSA-44, a post-quantum signature algorithm. OpenSSH processed the supplied key before checking whether its type was permitted.

Anthropic reported the issue to OpenSSH’s maintainers and supplied patches. OpenSSH 10.5 moved the check ahead of parsing, but Claude subsequently identified two gaps: a client could misrepresent the key type, and certificate processing could still reach signature-verification code before the relevant configuration checks.

Anthropic worked with the maintainers on further changes that placed checks inside the parser. These checked the encoded key type and the certificate’s signing algorithm against configured allow lists before the corresponding processing.

The changes shipped in OpenSSH 10.6 reduced the OpenSSH code reachable before authentication by roughly a fifth in a default build. The benefit came from restricting unnecessary access without needing to find a vulnerability in that code.

How Anthropic applied the approach

Anthropic combined the techniques into a reusable Claude skill that it is working to integrate into OSS Scanner, its free, opt-in security scanning service for open-source projects.

The skill checks for unnecessary code exposed by default, functionality accessible before authentication or other security gates, and combinations of settings that silently weaken protections.

Claude verifies findings through dynamic execution traces. For default-configuration findings, it implements proposed gates and compares modified builds against a baseline using the project’s own tests and a black-box regression suite. The results must remain identical.

Any gate that would change behavior under a non-default configuration is set aside for human review. For the other passes, Claude proposes changes such as moving a configuration check, enforcing protocol state ordering, or rejecting conflicting settings.

The approach can also extend beyond code analysis. Anthropic says Claude can compare runtime logs with configurations to identify unnecessary functionality, such as unused parsers, legacy protocols, and dashboards, that operators could disable to reduce security risk.