No Human Reviews Anthropic AI Vulnerability Reports, and 363 Projects Have Applied

Anthropic opened free vulnerability scanning to open source projects on October 8, 2026. It is called OSS Scanner. Anthropic's frontier models read a registered repository on a recurring schedule, look for security vulnerabilities, and email the maintainer a report with reproduction code and a candidate patch attached. The shape is borrowed from OSS-Fuzz, which Google has run since 2016, but where fuzzing throws random input at a binary, this reads the source.

Two things change on the receiving end. The email goes out without a single human having looked at it. And the vulnerability described in it never becomes a public advisory.

Where the 88% comes from

The accuracy evidence Anthropic published is 97 reports checked by hand by external penetration testers. Those 97 critical- and high-severity reports came from 48 projects, and 85 of them, or 88%, met the bar in Anthropic's coordinated vulnerability disclosure (CVD) process. Of the remaining 12, eleven described real bugs that duplicated either a known issue or another finding from the same scan, and exactly one was a false positive.

It is worth being precise about what 88% measures. It is the share of reports sent that were correct, not the share of vulnerabilities present in the code that the scanner found. Anthropic has not published the latter. That makes it incomparable with the 26% recall number from GitHub's AI code review benchmark, where first-place Copilot surfaced 26% of known defects, covered two days earlier: the two numbers have different denominators.

Two conditions are attached to that validation set. It covered only critical and high severity, and it was measured on an early version. No independent audit has been published. Anthropic states that in production it expects a true-positive rate above 90%.

Every maintainer assessment available comes from Anthropic's own announcement. Todd Ouska of wolfSSL wrote that all but 2 of 74 reports were valid and that 5 of them became CVEs. Anton Arapov of OpenSSL Corporation said the reports were "as good as what we get from humans, sometimes better". Daniel Stenberg of curl said it helped find several issues in curl worth addressing, though which CVEs those were has not been disclosed.

Stenberg's quote carries weight because he has been the most prominent objector to AI-sourced bug reports. In July 2025 he disclosed that roughly 20% of that year's security reports to curl were AI slop, and at the end of January 2026 he shut down curl's bug bounty entirely, saying the goal was to remove the incentive for low-quality reports "whether AI generated or not". That is the person Anthropic is now quoting approvingly.

The announcement also carries Anthropic's own list of weaknesses. Maintainers told them that severity ratings came in inflated and that the scanner sometimes misread a project's threat model.

No human review, and no disclosure

This is the sharpest break from how vulnerability reporting normally works. The repository README puts the reason and the consequence in one sentence.

Because of this, we do not place a 90-day disclosure deadline on these findings, nor do we disclose them.

The normal path runs like this. A security researcher reports a vulnerability, a 90-day clock usually starts, and when it expires a public advisory goes out with a CVE number attached. That is how everyone who depends on the library learns whether they are affected. OSS Scanner does not start that clock, because no human reviewed the finding. The report ends in the maintainer's inbox.

There is one exception. Section 5 of the OSS Scanner terms states that if Anthropic later manually validates a report and notifies the participant, it may disclose under its CVD policy 90 days after that notice. Nothing triggers this automatically; it runs only when Anthropic separately chooses to intervene.

What that design leaves for everyone downstream is unambiguous. Fixes that originate in OSS Scanner never appear in a CVE feed. If your dependency scanner only watches advisory databases, vulnerabilities patched through this path will not register, and the only trace is a release note and a commit message.

363 application PRs in three days, 21 registered

Applying means opening a PR against the anthropics/oss-scanner repository. Here is the state of that repository as read through the GitHub API at 21:00 UTC on October 10, 2026, less than three days after the repository was created at 17:25 UTC on October 8.

21 projects have completed registration in the projects/ directory. The list includes cryptographic libraries such as OpenSSL, NSS, and Botan; developer tooling such as Homebrew, nvm, mise, and sccache; and libraries that handle untrusted input directly, such as libtorrent, libheif, neqo, and pion-dtls. nestjs, nx, napi-rs, uppy, go-jose, nuclei, zmap, uutils-coreutils, anti-xss, and prevail are also on it.

The registration file itself is short. This is the whole of projects/openssl/project.yaml as OpenSSL submitted it.

repo: https://github.com/openssl/openssl#master
primary_contact: openssl-security@openssl.org
homepage: https://openssl-library.org
disabled: false

The 257 open PRs are a queue. Anthropic says it accepts only established projects critical to infrastructure and user security, case by case, and names two criteria: exposure to remote attack (whether the library processes untrusted input) and the number of users and dependent projects. The 80 PRs closed without merging are the ones those criteria filtered out.

What to check before you apply

Four access conditions, and no regional restriction.

Open the terms and you can see where the price of free is written down. The service incorporates Anthropic's Consumer Terms of Service by reference, not a commercial agreement. Reports are Anthropic's confidential information, are provided "as is", and may be used only to find and fix vulnerabilities in that project. Sharing is limited to authorized maintainers of that same project. Anthropic's total liability is capped at $1,000 (section 7). Section 8 says Anthropic may suspend the service or any individual registration at any time.

The README holds one condition that is easy to miss. The email address in project.yaml becomes public, and Anthropic explicitly advises using a security-only alias that is safe to publish. You can include a PGP public key to receive encrypted reports, but doing so blocks the auto_ccs field for adding carbon-copy recipients.

The scanner runs like this. It builds the project inside an isolated virtual machine with the network on, then cuts the network and runs the audit. If the build fails, an error email goes to the contact address. So everything the tests need has to be fetched during the Dockerfile stage. The repository ships tools/check, which builds the image exactly the way the scanner does and then drops you into a network-less shell; that process installs Claude Code inside the image, which is also how the real scan is configured.

If you are a lead maintainer, run tools/check <name> before opening the PR to confirm your tests pass in a network-less container, and submit the optional threat_model.md alongside it. That file is where you write your severity conventions: whether post-authentication SQL injection is high or critical, how far to escalate a buffer overflow with no demonstrated exploit. Inflated severity and misread threat models are the two weaknesses Anthropic itself admits to, and this file is the only input that reduces either.

If you are not a maintainer, the thing worth checking is your dependency tracking. Among the 21 registered projects, OpenSSL, NSS, Botan, go-jose, libheif, and libtorrent are common dependencies. When an OSS Scanner fix lands in one of them, it arrives as a commit with no CVE number and no advisory, which means a scanner that watches only advisory feeds will never see it.