Anthropic OSS Scanner Launch: curl Vulnerability Claim, AI Report Accuracy and Enrollment

What Anthropic launched​

OSS Scanner is an opt-in vulnerability scanner for the open-source ecosystem, informed by Anthropic's experience using Claude to find vulnerabilities during Project Glasswing. Projects that join get periodic security scans by Anthropic's strongest models at no cost.

The catch is in the process. The service runs fully automated, with no human review before a report goes out. Anthropic says this enables faster and more frequent scanning. The flip side is that some reports will be incorrect or invalid.

Anthropic's explanation for the design is a human bottleneck. It says it has found over 29,000 candidate vulnerabilities in six months but has only been able to manually review about 6,000. Some maintainers have simply asked for everything, validated or not. Anthropic says it has sent nearly 5,000 reports directly to maintainers on that basis.

Its human-reviewed coordinated vulnerability disclosure (CVD) process continues. That process is aimed at projects without the resources to triage reports themselves.

The curl claim, and what is verified​

The headline rests on a quote from curl lead developer Daniel Stenberg in Anthropic's launch post. He said OSS Scanner has helped curl find multiple issues worthy of addressing, including one of the worst curl vulnerabilities reported in the last few years.

Three points are worth keeping apart:

• The quote is Stenberg's, published by Anthropic. The announcement does not say which vulnerability he means, so there is no CVE number or severity to check.
• Stenberg's earlier Mythos account was more muted. On May 11 he wrote about an earlier Mythos scan of curl, arranged through the Project Glasswing and Alpha Omega arrangement rather than through OSS Scanner. That report analyzed about 178,000 lines in src/ and lib/. It listed five "confirmed" vulnerabilities, and curl's security team trimmed that to one. He expected that one to become a low-severity CVE.
• Don't merge the two accounts. Nothing public ties the May low-severity finding to the "worst in years" comment. The October quote may describe a different, later finding.

For the same reason, curl's April CVE-2026-4873 should not be attributed to Anthropic. That low-severity flaw let a TLS-required transfer reuse a cleartext IMAP, POP3 or SMTP connection. The advisory credits a different reporter and was published before the May scan.

Stenberg's May post is also a useful corrective to hype. He said he saw no evidence that the setup found issues to a notably higher degree than earlier tools. He also said AI analyzers are significantly better than traditional ones, and that projects not using them leave openings for attackers. Both views can be true. The tools are useful, and the marketing may still be ahead of the evidence.

How reliable are the reports?​

Anthropic offers some numbers. They are the company's own, so treat them as claims rather than independent audits.

• Penetration-tester check. Anthropic asked the expert penetration testers who review its CVD findings to check 97 critical and high-severity vulnerabilities from an early scanner version across 48 projects. Of these, 85 (88%) met the bar for its CVD process. Of the remaining 12, 11 were real but duplicated known issues or other scan findings, and one was a false positive.
• wolfSSL's experience. Todd Ouska said all but two of 74 reports were valid, and five became CVEs. That is one project's view, not a scanner-wide error rate.
• Maintainer caveats. Anthropic acknowledges that some maintainers say severity ratings can be inflated or that the scanner misunderstood the project's threat model.
• The benchmark. On CyberGym, LLMs went from finding under 20% of vulnerabilities at the beginning of last year to over 85% this year. That measures performance on a benchmark, not the false-positive rate on live code.

Reports cannot be taken as verified findings or tested patches. They are leads that maintainers have to validate. Each report includes a reproducer, an explanation, and a candidate patch when available. A working exploit speeds up triage, but a patch still needs review.

How enrollment works​

This is not a tool you point at arbitrary code. Anthropic's enrollment repository describes the process:

1. Check eligibility. Anthropic says projects should have a "critical impact on infrastructure and user security", with decisions made case by case. Its FAQ says it uses criteria similar to OSS-Fuzz. Those include exposure to remote attacks and the number of dependent users or projects. Core maintainers are validated before enrollment.
2. Open a pull request. Add a directory under projects/<name> in the anthropics/oss-scanner repository. The project.yaml file requires a repository address and a primary contact email. A Dockerfile is also required, in the project's own repo or next to the config. A threat model file is optional but strongly recommended.
3. Know the exposure. The email addresses in the config are public, so a security alias is the sensible choice. Reports can be encrypted with a PGP key, but then go only to the primary contact.
4. Understand the build. The scanner builds the project in an isolated VM with network access, then removes internet access before the audit begins. The Dockerfile therefore has to fetch everything the build and tests need up front.
5. Validate locally. Anthropic suggests running tools/validate.py and tools/check before submitting. Its warning is that tools/check builds the Dockerfile with network access, so only run it on projects you trust.
6. Pause or leave. Setting disabled: true pauses reports, and deleting the project directory withdraws it.

Disclosure and workload​

Unvalidated findings carry no 90-day disclosure clock. Anthropic does not impose a 90-day disclosure deadline on unvalidated findings. Its FAQ says a report later validated through the CVD program could start a 90-day period from the date the maintainer is told a human confirmed it.

The workload is the real issue. Anthropic concedes that many projects are already overwhelmed by the number of reports they are receiving, and says the service suits teams that can already keep up with verified high and critical reports. Stenberg has previously described how costly each security report is for curl's small team. Free scanning shifts effort from finding bugs to validating them.

Why Windows and enterprise admins should care​

This is not a Windows patch story, but the dependency chain reaches Windows environments. curl, OpenSSL and wolfSSL-class libraries are embedded in many applications and appliances. When maintainers get bug leads sooner, fixes can reach downstream software sooner. That also puts pressure on defenders. Fixed releases may arrive faster, and teams will need a way to tell which bundled copies of these libraries they ship.

Practical steps for IT teams:

• Inventory bundled libraries with an SBOM or software composition tool, so you can match new advisories to what you run.
• Watch for faster upstream releases from critical open-source projects, and plan patch cycles accordingly.
• Don't treat every AI-generated report as a CVE. Public advisories will still come from maintainers after validation.

The original Neowin report also links this to record Windows 11 Patch Tuesday volumes caused by AI-found bugs. That causal claim has no support in Anthropic's materials, so treat it as unverified.

Bottom line​

OSS Scanner is a notable attempt to give critical open-source projects free, frequent AI audits. Early maintainer feedback from PostgreSQL, OpenSSL Corporation, wolfSSL and HotCRP is largely positive. The "one of the worst curl vulnerabilities" line is Stenberg's own words, but it is unattributed to a specific bug and so cannot be checked yet. Until curl publishes details, the claim stays a testimonial rather than a verified finding.