Anthropic has launched OSS Scanner, a free, opt-in service that periodically examines open-source code with its strongest models, including Claude Mythos. The service sends findings directly to maintainers without human review, accelerating delivery while leaving project teams responsible for checking reports and proposed fixes.
Launched on October 8, 2026, the program targets established projects with a critical impact on infrastructure and user security. According to MarkTechPost, 114 projects had been accepted from about 650 applications by October 19, when Anthropic reported 77 critical and 803 high model-rated findings. Those classifications are model assessments, not evidence that attackers have exploited the issues.
Faster reporting brings a triage tradeoff
In its launch announcement, Anthropic said its models had identified more than 29,000 candidate vulnerabilities over six months, but human reviewers had triaged approximately 6,000. Maintainers requesting all available findings had already received nearly 5,000 reports without prior validation.
OSS Scanner formalizes that option. Anthropic will continue its existing coordinated vulnerability disclosure process for human-verified findings, particularly for projects that lack resources to triage raw reports. The automated service is intended for teams already able to keep up with verified high and critical vulnerability reports.
Anthropic tested an early scanner version by asking expert penetration testers to review 97 critical and high findings across 48 projects. Of those, 85—88%—met its coordinated disclosure standard. Another 11 described real problems but duplicated known issues or other scan findings; one was invalid. Some maintainers nevertheless reported inflated severity ratings or misunderstandings of their projects’ threat models.
Maintainer feedback also points to useful results. Todd Ouska of wolfSSL said all but two of 74 reports were valid and five became CVEs. Anthropic said its initial testing across dozens of projects produced hundreds of reports, including vulnerabilities it was able to chain into unauthenticated remote code execution exploits. These were demonstrated capabilities during testing, not reports of attacks in the wild.
How projects enroll and receive findings
Under Anthropic’s service documentation, core maintainers enroll by submitting a pull request to anthropics/oss-scanner, adding projects/<project>/project.yaml. The configuration supplies the repository and primary contact, plus a repository-relative Dockerfile path. Alternatively, maintainers can place a file named Dockerfile beside the configuration and omit that field.
Anthropic reviews eligibility case by case, considering factors including exposure to remote attacks, dependencies, usage and security importance. New projects and forks that are not distinctly different generally do not qualify.
The Dockerfile builds with network access and prepares dependencies. Scanning agents then operate inside hardened sandboxes with Internet access disabled. The pipeline uses agents to double-check bugs, analyze root causes and propose patches, but findings receive no human triage before delivery.
Reports arrive by email with a self-contained reproducer and an explanation. Where possible, they also identify the introducing commit through bisection and include a candidate patch. Subsequent scans look for newly introduced vulnerabilities and issues earlier scans missed; their frequency varies with workload and other factors.
An optional threat-model file lets maintainers define adversarial inputs, exclusions, severity criteria and reporting preferences. Without it, the scanner makes its own judgments about ambiguous cases.
Human checks still govern enrollment and recipients: Anthropic verifies maintainer identity, security contacts and the intended repository scope. Optional GPG encryption is available, but encrypted reports go only to the primary contact and cannot include additional CC recipients.
Unvalidated findings carry no 90-day disclosure deadline. If Anthropic later validates a report through its human-reviewed process, a 90-day period may begin when the maintainer is notified of that validation. Projects can pause automated reports with disabled: true or withdraw by removing their project directory through a pull request.
curl fix illustrates the findings—and their conditions
One vulnerability highlighted in reporting on the service is CVE-2026-92392, a High-severity HTTP/2 upload use-after-free affecting both libcurl and the curl command-line tool. curl’s advisory says the flaw occurs when an upload mishandles a server’s HTTP/2 RST_STREAM with reason HTTP_1_1_REQUIRED or REFUSED_STREAM, freeing a struct Curl_easy object that remains in use.
The issuer lists curl 8.12.0 through 8.22.0 as affected, with maintenance-branch exceptions: versions 8.20.2 and later in the 8.20.X branch, 8.16.2 and later in 8.16.X, and 8.14.3 and later in 8.14.X are not affected. Versions before 8.12.0 and versions 8.23.0 onward are also unaffected.
curl says remote code execution has been demonstrated under specific conditions. The malicious server must account for the exact curl version’s object and structure layout, architecture, a compatible libc allocator and heap layout, nghttp2 and OpenSSL/TLS 1.3 behavior, a pinned CA bundle and input-dependent allocation geometry. The exploit also depends on two parallel transfers and their scheduling and timing, calibrated libc leak and symbol offsets, and a current short-command constraint of approximately 23 bytes.
The issue was reported to curl on September 15, 2026. Version 8.23.0 and the advisory were released on October 14. curl recommends upgrading to 8.23.0, applying the patch locally or avoiding HTTP/2.
