Claude uncovered 493 security issues across 25 open-source projects, including safeguards that appeared enabled while software still permitted unintended access. Some problems had remained hidden in code for years.
Anthropic's AI research examined how security settings interact and how much code remains accessible before authentication. Findings included protections that failed without warning, leaving software exposed beyond its intended restrictions.
One discovery prompted OpenSSH developers to revise security checks in the widely used remote-access tool. Other cases raised concerns about weaknesses that administrators might never notice through routine configuration reviews.
Configuration conflicts left security checks disabled
Servers configured to require valid client certificates could still accept connections without them because of a configuration conflict that had persisted for 21 years. Instead of delaying verification as intended, a separate setting disabled the check entirely, without warning administrators.
Claude analyzed more than five million lines of code and cataloged over 17,000 configuration options, including 3,842 associated with security functions. Its investigation identified several problems involving combinations of settings that software accepted without errors:
- 94 silently disabled controls. Of 162 security-sensitive configuration combinations accepted without warnings or documented behavior, 94 turned off an existing protection.
- 68 inconsistent configurations. Other combinations left disabled login paths accessible or allowed the order of settings to determine which restriction prevailed.
- Four projects with ineffective deny rules. When reverse DNS lookups were disabled, servers compared hostname-based restrictions against numerical IP addresses. Since the patterns could not match, the intended access rules failed to block connections.
According to Anthropic, the investigation included tracing software execution to assess whether the suspected configuration weaknesses affected actual security checks.
OpenSSH fixes reduced code reachable before authentication
Across 11 projects designed for authenticated users, Claude detected 93 unnecessary areas of code accessible before login.
OpenSSH, a widely used tool for secure remote access, left roughly 4,500 lines of experimental post-quantum signature code reachable by unauthenticated clients in version 10.4, even when the algorithm was disabled. Its server parsed incoming keys before checking whether the signing method was permitted.
Developers moved the algorithm check ahead of key parsing in version 10.5, but two gaps remained. Clients could advertise an approved algorithm while submitting a different key type, while certificate processing could still verify signatures before enforcing the configured restrictions.
Version 10.6 introduced additional checks inside the parser, reducing code accessible before authentication by approximately 20%, based on Anthropic's measurements.
Reducing pre-authentication code exposure can limit potential attack paths, although the presence of reachable code does not, by itself, establish an exploitable vulnerability.
Security teams need to validate deployed protections
For enterprises relying on remote-access gateways and internet-facing services, Claude's findings expose a gap between approved configurations and actual software behavior.
A server may have current patches and correctly documented restrictions, yet interactions between its settings could still permit unintended access. Routine security reviews may not detect the discrepancy.
Consider an organization using certificate-only authentication to protect a critical service. A controlled connection attempt without valid credentials would reveal if the server enforces the restriction under its deployed configuration. Including such checks in vulnerability assessments can uncover problems that conventional CVE scans and patch inventories might miss.
For security teams managing extensive infrastructure, attack surface management can help identify externally accessible systems where these weaknesses would carry the greatest risk.
AI-generated findings still need verification against affected software versions, but confirmed exposure can justify remediation even without a published CVE.
As automated research uncovers more overlooked issues, security teams will need to distinguish theoretical weaknesses from demonstrable exposure. Evidence of exploitability, affected configurations, and potential business impact should guide which fixes receive immediate attention.
More cybersecurity news: An AI-powered security testing tool has surfaced in cyberattacks against Japanese businesses, raising concerns about its misuse.