The four-day patch window: when disclosure becomes a starting pistol

The four-day patch window: when disclosure becomes a starting pistol

January 31, 2026. An autonomous research agent run by Hacktron AI sweeps BeyondTrust's Remote Support and Privileged Remote Access products, looking for variants of an old bug. It finds one: unauthenticated OS command injection, CVSS 9.9. No credentials, no user interaction, commands as the site user.

The same day, Hacktron reports it. BeyondTrust confirms it and starts writing the patch. February 2, every cloud customer is patched automatically. February 6, the advisory and the CVE go public. February 10, four days after disclosure, the first exploitation attempt lands. By day seven, Google's threat researchers count six separate clusters inside customer environments, dropping SNOWLIGHT, SPARKRAT and cryptominers.

Run that timeline back and look for the mistake. There isn't one. The finder reported responsibly. The vendor patched in two days, which by industry standards is sprinting. CISA added it to the Known Exploited Vulnerabilities catalog on February 13. Every actor in the chain did the textbook thing, and the window between "advisory published" and "initial-access crews inside" still collapsed to four days.

The old bug had siblings

The flaw, CVE-2026-1731, is a close relative of CVE-2024-12356, the vulnerability Silk Typhoon used to breach the U.S. Treasury in December 2024. GreyNoise's analysis found both bugs on the same /nw WebSocket endpoint, just on different code paths. The December 2024 patch fixed the code path attackers used back then. It did not cover the sibling.

Finding that sibling is exactly what Hacktron's agent was built for. They call it variant analysis: take the anatomy of a known bug, then sweep a codebase for the same shape everywhere else. A human researcher does this too, one product at a time, between meetings. An agent does it across versions and products while you read the advisory. Around 11,000 instances of this software face the internet, about 8,500 of them self-hosted and waiting for a human to click update.

The numbers behind the feeling

If four days feels fast, that feeling now has a dataset. In late September, Google's Threat Intelligence Group published disclosure and exploitation counts for January 2025 through August 2026:

• Monthly CVE disclosures doubled inside 2026, from 5,045 in January to 10,740 in August.
• Vulnerabilities observed exploited in the wild went from an average of 10.5 per month in 2025 to 18 per month in 2026. The 141 distinct exploited bugs in the first eight months of 2026 already beat the 127 for all of 2025.
• Zero-day exploitation barely moved: 8 per month on average in 2025, 11 in 2026. Help Net Security reproduces the full table.

That last line is the interesting one. The growth is not coming from exotic new zero-days. It is coming from n-days, the bugs that already have a patch, and GTIG's read is blunt: threat actors find it more efficient to point LLMs at version diffs, advisories, and proof-of-concept code than to hunt for new bugs. Reading diffs got cheap. The cheap move won.

Two honest caveats before you quote these numbers in a meeting. Only 0.23 percent of 2026 disclosures, roughly one in 431, were observed exploited at all, so this is a signal about which bugs to care about, not a wall of fire. And GTIG's "discovered by AI" labels are heuristics: CVE records have no field for AI attribution, and big providers often fix AI-found bugs in production without ever requesting a CVE. The real AI-discovery count is higher than the counted one, by an amount nobody can currently measure.

One more datapoint from the same shop: in their May threat tracker, GTIG described intercepting a criminal actor holding a zero-day exploit script with high-confidence LLM generation markers, before it was ever used. Defense found the AI-written weapon first. That will not always be the order.

The bugs AI finds are the ones attackers want

Of the vulnerabilities GTIG flagged as likely AI-discovered, half lead to remote code execution. Across the rest of the ecosystem, the baseline is 26 percent. AI-discovered bugs also skew away from junk: 39 percent low-risk versus 69 percent for everything else.

That is not because models are magic. It is scope. Agents get pointed at privileged boundaries and infrastructure software, the exact places initial-access crews shop, and they turn out to be good at the memory corruption and logic flaws that static analyzers shrug at. SecurityWeek's writeup covers the same shift.

So your patch SLA math is now fighting a different opponent. A 14-day SLA for internal services is fine. A 30-day cycle for anything that terminates requests from the internet is a bet that the crew weaponizing the advisory is slower than your change advisory board, and GTIG just watched that bet lose in four days.

What to actually change

1. Create a same-day patch class. VPN concentrators, remote support and PAM appliances, API gateways, AI gateways: anything internet-facing that brokers access gets patched on advisory, not on cycle. The change freeze is a suggestion for this class, and you should get that exception agreed in writing before you need it.
2. Triage by exploitation signal, not CVSS. You cannot patch ten thousand CVEs a month, and you do not need to: about one in 431 shows real exploitation. Watch the KEV catalog and vendor advisories, and let threat-intel-driven triage, GTIG's own recommendation, decide your weekend.
3. Fix the inventory, because inventory is the real bottleneck. BeyondTrust auto-patched its cloud fleet two days after the report. Every victim afterward was a self-hosted box nobody had on a list, the gap Rapid7 flagged the week the advisory dropped. If you cannot enumerate your internet-facing surface in an afternoon, that is the project, before any of the rest.
4. Read the finder line in advisories. Names like Hacktron AI and AISLE in the acknowledgments now signal a bug class that skews pre-auth and RCE-heavy. Treat those as pre-weaponized regardless of the severity score.
5. If you do research, tighten your disclosure hygiene. The variant of the bug you just found has maybe weeks before someone else's agent sweeps the same code. Report fast, keep embargoes short, and assume the public advisory is the starting pistol for everyone, including you.

Your agent stack is in this dataset too

GTIG counted 2,076 vulnerabilities in AI-related software over the same twenty months, more than 1,500 of them in 2026 alone, about half in orchestration frameworks. A handful are already exploited, and the profile should look familiar by now: command injection in a LiteLLM MCP test endpoint, arbitrary file writes in Langflow upload handlers. The gateway you stood up so your agents could call tools is perimeter middleware now, same as the BeyondTrust box, same four-day math when its turn comes.

BeyondTrust's cloud fleet was fully patched four days before the advisory went public. The first attackers came four days after. The gap between those two sentences is not vendor speed or attacker skill. It is whether anybody owns the box, and in 2026 that question gets answered inside a week.