AI and the Rise of Patch-Gap Abuse

Microsoft Edge Security and Microsoft Threat Intelligence recently disrupted several sustained attack campaigns against Chromium-based browsers. This activity reveals a disturbing trend in which threat actors exploit recently fixed vulnerabilities to target users running versions of Edge and Chrome that have not yet received the fixes. Microsoft thanks our partners at Proofpoint and Volexity for their contributions to this work.

In two exploit chains, attackers paired remote-code-execution vulnerabilities in V8’s Maglev compiler with escapes from V8’s internal sandbox, illustrating the risk created when public Chromium fixes have not yet reached users.

Evidence suggests AI may be accelerating this patch-gap abuse. This post explains what happened, how attackers reverse-engineer public code changes, and how Edge is working to shorten patch delivery.

The most immediate defence remains straightforward: install browser updates promptly and restart when required.

What happened

The following is a breakdown of one recent exploit campaign that was discovered and disrupted by Microsoft in early September 2026.

On 1 September, Microsoft confirmed active exploitation of a V8 remote-code-execution vulnerability and began an expedited Stable response. Because the fix had not yet shipped in Chrome Stable, Edge independently isolated and backported the change rather than taking all unreleased changes from Chromium’s release branch. The first fix began rolling out in Microsoft Edge 152.0.4191.62 on 2 September.

On 3 September, threat intelligence confirmed that attackers were also using an escape from V8’s internal sandbox, prompting a second expedited update. Edge backported the additional fix, integrated the updated V8 version into the Edge release branch, and completed validation that day. Microsoft Edge 152.0.4191.66 began rolling out with the additional fix on 4 September; Chrome’s corresponding Stable update followed on 8 September.

The exploit chain had three stages. Attackers first exploited a remote-code-execution vulnerability in Maglev, one of V8’s optimising just-in-time (JIT) compilers, to execute code inside V8. They then used a sandbox-escape vulnerability to break out of V8’s internal sandbox while remaining inside the browser’s renderer process. A further exploit was still required to escape the renderer sandbox and reach the operating system; in one recent example, attackers used an N-Day vulnerability in Windows for this final stage.

Rollout timing varied by platform and device. A release date does not mean protection is active everywhere: users still need to receive the update and restart the browser.

Reverse-engineering code changes

Chromium-based browsers share a common open-source code base that includes V8, the engine responsible for executing JavaScript and WebAssembly. Security fixes to shared components such as V8 can benefit the wider ecosystem, but protection does not move directly from an upstream code change to every user. At least two gaps must be closed: first, the interval between a fix becoming available in Chromium and a browser vendor integrating, validating, and shipping it; second, the interval between that browser release and the updated version running on a user’s device.

Once a security-relevant code change is public, attackers can examine the pull request, infer the underlying vulnerability, and develop an exploit. That exploit can then target users across both exposure windows: browser releases that do not yet contain the fix, and devices that have not yet received it or restarted.

This is patch-gap abuse. The technique is not new, but the speed and expertise required is changing. AI-assisted analysis and exploit development could compress work that once took weeks into hours, increasing the chance that a usable exploit emerges while either exposure window remains open.

The activity we investigated illustrates that risk. Attackers targeted Edge and Chrome releases that had not yet received the relevant Chromium fixes; after the fixes shipped, any devices that had not yet updated and restarted remained exposed.

Getting fixes into Edge sooner

The first gap closes only when an upstream Chromium fix is integrated, validated, and shipped in a protected Edge release. We have shortened that path: when active exploitation warrants it, we can isolate and expedite an individual fix rather than waiting for the next routine integration of Chromium changes.

Microsoft Edge 152.0.4191.66 demonstrates this approach: Edge isolated, validated, and shipped the V8 sandbox-escape fix without waiting for Chrome’s corresponding Stable release.

Shipping closes the first gap, but it does not protect every device immediately. Rollout timing varies by platform, and a release date should not be read as the point when every device has installed and restarted into the update. The second gap begins here. Further details are available in the Edge security release notes and Chrome release announcement.

Our primary responsibility is to shorten the first gap: the time between an upstream fix and a protected Edge release. The longer that interval remains open, the longer attackers can target browser versions that do not yet contain the repair.

Microsoft Edge may now ship critical security updates before the corresponding CVE information is published. This allows us to deliver protection as soon as a validated fix is ready, without waiting for coordinated disclosure to complete. Users and administrators should therefore apply Edge updates promptly rather than waiting for a CVE publication or detailed security announcement.

Closing the gap on your device

Once a patched version of Edge is available, closing the second gap depends on getting that release onto devices and restarting the browser. We are looking to roll out instant updates to shorten this interval further by accelerating the path from release to the new version running on a device. Users and administrators still play an important role by keeping automatic updates enabled, monitoring the version running, and accelerating urgent security releases.

• Do not wait for a CVE announcement. Apply browser updates promptly, including releases without prominent security headlines.
• Keep automatic updates enabled. Visit edge://settings/help to check your update status, and restart when prompted.
• Enable Edge’s new “Instant updates”. Open Help and feedback > About Microsoft Edge, then toggle Instant updates.
• Consider Enhanced Security Mode. Choose an appropriate configuration and review exceptions, accounting for compatibility and performance needs. We’ll share more news on this shortly.
• For managed environments, track running versions—not just downloaded updates. Keep validation and deployment windows short, with a way to accelerate urgent security releases. As instant updates become available, incorporate them into deployment policy while continuing to verify that protected versions are running.

A fix only protects users once it reaches the browser they are running. Faster releases, instant updates, layered mitigations, and prompt user and administrator action all help close the gaps attackers are trying to exploit.