The patch is out — and attackers are already racing to exploit it

A vendor fix used to signal the end of a security risk. Today, the patch disclosure is the starting gun — and your standard change-management window is the head start attackers count on.

When WordPress shipped version 7.1.2 Opens a new window on September 22, 2026, it patched CVE-2026-87902 — a flaw that let attackers run code on vulnerable sites without logging in . The vendor did everything right: coordinated the fix, pushed the update, and told users to update immediately.

The defensive playbook broke anyway. Cybersecurity firm Patchstack Opens a new window recorded the first malicious probing at 11:49 UTC that same day — just hours after the patch landed. Within 24 hours, routine probing turned into automated attacks trying to plant malicious files on servers.

This isn’t a WordPress failure. It’s the reality of modern patching: the moment a fix goes public, it becomes a roadmap. While your team waits on testing, approval, or the maintenance window, attackers are already scanning your endpoints. The announcement meant to secure the ecosystem simultaneously serves as a blueprint for bad actors. For lean IT teams, the paradox is blunt: the public advisory designed to protect your environment is what marks it as a target.

Navigating the dangerous gap between patch release and system update requires rethinking how organizations manage vulnerability disclosures.

When one attacker’s exploit becomes everyone’s problem

The WordPress timeline is worrying enough, but the risk compounds when an exploit spreads across multiple threat groups.

Take the BlueMoon exploit kit, which chained Chrome and Windows vulnerabilities. Proofpoint Opens a new window researchers initially tracked a single espionage group using the tool. Between August 28 and September 3, 2026, three additional espionage clusters adopted the exact same tactics — all while enterprise updates stayed stuck in testing and approval .

“In the BlueMoon case, the same capability was shared across multiple threat actors rather than each group developing the exploit chain independently,” Mark Kelly, staff threat researcher at Proofpoint, told Spiceworks via email. “This pattern has been observed in the Chinese cyberespionage ecosystem before and suggests a closed distribution channel for exploits that are soon to be patched.”

Proofpoint also highlighted a critical operational blind spot: the patch gap. One of the Chrome fixes appeared in the public Chromium source code before reaching the stable browser channel. Attackers monitoring those commits analyzed the fix and built working exploits before enterprise change-management boards could even schedule an emergency maintenance window.

That flips the traditional patch timeline. The moment code changes go public, defenders are just starting their deployment reviews while attackers are already weaponizing the fix.

Why the hours after disclosure matter

Recent incidents expose a lopsided race. Once a vendor releases a fix, the difference between the old version and the new one becomes public. Anyone can compare the two, identify the broken elements, and devise ways to exploit them.

This hits open-source projects like Chromium hardest. The BlueMoon campaign saw the public repository fix the underlying bugs long before those patches made it to the browser builds that most users actually run. Attackers simply used the public commits to construct working exploits during that window.

Here’s why the race is lopsided: defenders put patches through governance, testing, and staged rollouts. Attackers take the same patch and pull it apart automatically.

AI makes that gap wider. “This is particularly true for patched vulnerabilities, as it is much easier to quickly compare a software update against the version to find a vulnerability and weaponize it with AI assistance than to discover an entirely new one,” Kelly explains. “As a result, N-day vulnerabilities are likely to be weaponized faster.”

An N-day flaw is one that is publicly known and patched by the vendor but not yet applied across every downstream system. While Proofpoint noted no direct evidence of AI usage in the BlueMoon kit itself, generative models inherently lower the barrier for analyzing code changes and refining exploit payloads.

For IT and security leaders, this shifts the benchmark for patch management. A vendor releasing a fix is only step one; the true test is whether your deployment speed can outpace an attacker weaponizing that same disclosure.

What to do instead of “just patch faster”

Telling an IT team to “patch faster” ignores reality. In a production environment, deployment delays aren’t caused by laziness — they’re necessary controls protecting business continuity, from compatibility testing to change-management windows.

The problem arises when every vulnerability follows the exact same rigid workflow regardless of active risk. Even WordPress built version 7.1.2 as a targeted security-only release, allowing sites with auto-updates enabled to bypass standard update queues.

Unexploited flaws can follow routine patch cycles. Flaws under active exploitation require a different gear. Catalogs like CISA’s Known Exploited Vulnerabilities Opens a new window (KEV) provide the signal needed to fast-track emergency updates — and CVE-2026-87902 landed on the KEV list on September 25, just three days after disclosure.

Effective security teams don’t need to force a faster version of an already strained patch cycle. They need a system that shifts gears based on threat intelligence — fast-tracking actively targeted bugs, applying temporary mitigations, or increasing monitoring while full updates are tested.

When asked how defenders should handle the window between an upstream fix and downstream deployment, Kelly is clear: treat the risk as starting the moment a patch commit hits an open-source repository, not when the finished product ships. Attackers start building exploits from the commit alone.

That is the modern reality of patching. Resilience means narrowing the gap between public disclosure and internal protection. Monitor active exploit feeds, adjust deployment speed to match real-world risk, and never let a static calendar determine your security posture.