Microsoft FORGE Finds 140 Windows CVEs, Submits 155 Open-Source Reports

Microsoft’s FORGE researchers helped discover 140 Windows CVEs addressed between May and September 2026 and submitted 155 internally validated reports across 23 open-source projects. Those are different kinds of output. A product-security team running Windows or depending on Linux and open-source libraries still has to get each relevant defect reproduced against its own build, fixed and released.

The October 7 account from Microsoft FORGE Lab describes the bottleneck: an agent can send candidate bugs to reviewers faster than engineers can validate and service them. Microsoft runs MDASH and is evaluating its own research system; treat these totals as first-party measurements of FORGE’s work. Its strongest lesson is blunt: “A reproducible defect is not yet a serviced fix.”

The counts belong to different stages

Microsoft says the 140 Windows CVEs were addressed in security releases, including 52 in September’s release. The monthly totals track announcement and servicing cohorts, rather than when the bugs were discovered. In open source, the team submitted 155 internally validated reports; 93 reports across 14 projects or project families had documented maintainer acknowledgement or acceptance at the time of writing. The 155 already includes 39 reports from an internal hackathon.

A confirmed candidate can still wait on a maintainer, a compatible patch, regression testing and a release. Microsoft reports that an internal abstract-syntax-tree method reduced duplicate findings by about 45% across repeated scans of the same code. Fewer duplicates leave reviewers more time for new causal claims. For 182 confirmed Linux kernel crash findings, Microsoft reports an average of $3.61 in model cost and 21.5 minutes to generate a proof of concept per successful case. Those averages include attempts for successful cases and exclude initial screening, filtered candidates, human investigation and patch preparation.

Two curl bugs demand separate checks

In curl’s CVE record for CVE-2026-9545, HTTP/3 early data may send request bytes to an impostor server before certificate verification fails. The described condition combines a cached SSL session with the CURLSSLOPT_EARLYDATA bit in CURLOPT_SSL_OPTIONS. Sensitive request data may leak when the first transfer reached the real server and the later connection reaches the impostor. The record credits Microsoft’s Eunsoo Kim as finder and Stefan Eissing for remediation.

The record for CVE-2026-13608 describes a different failure: libcurl’s OpenLDAP SASL negotiation can interpret an incomplete handshake as successful cryptographic verification. An attacker in the network path could inject a premature response and bypass full peer validation. That record credits Eunsoo Kim as finder and remediation developer. Inventory the libcurl build loaded by each application and identify HTTP/3 early-data use and LDAP SASL use separately.

The curl records specify affected version ranges and branch fixes. For CVE-2026-9545, they list affected 8.11.0 through versions before 8.14.2, 8.15.0 through versions before 8.16.1, and 8.17.0 through versions before 8.20.1. For CVE-2026-13608, they list affected 7.82.0 through versions before 8.14.2, 8.15.0 through versions before 8.16.1, 8.17.0 through versions before 8.20.1, and 8.21.0 through versions before 8.22.0. Match your packaged libcurl build and any vendor backport against the applicable branch advisory; check the library loaded by the application rather than a command-line binary elsewhere on the host.

Reproduce against the build that ships

Microsoft describes project-specific provers, harnesses and trigger finders as the bridge from a plausible source-code path to a reproducible failure. A component team needs the binary, configuration and runtime conditions for the artifact its customers actually receive. Reviewers can then reject duplicate or unreachable claims, hand a confirmed causal path to the component owner, and turn a reproducer into a regression test. Failed validation also needs a reason, such as an unreachable path or a build that lacks the affected feature, so another scan does not send the same claim back through triage.

In the Linux kernel record for CVE-2026-64563, a restart of an rhashtable walk after a table resize can leave a stale iter->p; rhashtable_walk_next() then reads freed memory. The record identifies local netlink diagnostics and TIPC socket walks as affected callers, with a KASAN use-after-free trace. It lists fixed stable-branch points including 6.6.151, 6.12.103 and 6.18.42. Check your running kernel against your distribution’s patched build and the affected call path. Use the actual built kernel and backport record when scoping your hosts.

Carry each finding into release

For your own intake queue, record the candidate’s affected component, reachable build, reproducing evidence, owner and disposition. Deduplicate repeated reports before spending component-engineer time. Then connect an accepted report to the patch review, regression result and release artifact that carries the fix. Microsoft’s suggested measurements include queue age, rejected and duplicate reports, reproduction success, patch rework and time from validated defect to release. A raw finding count hides the gap between discovery and delivery.

For curl dependencies, change state by updating affected library branches to a fixed vendor build and retesting the relevant HTTP/3 early-data or LDAP SASL path. For the kernel finding, schedule the patched distribution kernel for affected hosts and confirm the running build after reboot. If a backport changes the version string, use the vendor’s patch record and build identity. Verify that the fixed component is present in the deployed artifact and that the regression test runs against that artifact. A passing source-level test on an older build is a different result from a shipped fix.