Thursday, October 15 — ConnectWise’s Cloud Backup application (formerly SkyKick) began signing into customer Microsoft 365 tenants from a hosting provider address, at an hour when an application has no reason to be doing anything. By the end of that day, the credential had been used to collect Microsoft Graph access tokens in more than a hundred confirmed tenants.

Friday, October 16 — ConnectWise published its first advisory at 17:47 UTC, and Huntress published the technical breakdown. Two of our clients had the application installed.

Saturday, October 17 — an independent researcher known as “Wayne” was running a routine check against the Common CA Database, the public corpus of trusted intermediate certificates, and noticed something odd in eight of eMudhra’s certificates. The P-384 private keys behind them were smaller than 256 — not cryptographically weak, numerically small. A private key of this type is meant to be a random number more than a hundred digits long. These could be recovered by testing a few hundred values.

Wayne did not just report it. He signed the message “We have a problem here — Wayne” with each of the eight keys, proving they were recoverable, and sent the report to Apple, Google, Microsoft, Mozilla, and eMudhra.

Sunday, October 18 — eMudhra revoked the affected certificates, within fourteen hours of being told.

Monday, October 19 — Chrome and Firefox blocked the certificates, and Apple followed the same day. Cloudflare became aware at approximately 17:00 UTC and began patching its own critical services before public disclosure. One of the intermediate certificates had a private key of the number 4. Another was 56. Another was 115.

Tuesday, October 20 — Mozilla’s Dennis Jackson made the incident public on Mozilla’s security policy forum. Microsoft blocked the certificates the same day. Around 15:00 UTC, the two PHP CVE identifiers began circulating on forums and social media — carrying a wrong release time and a wrong severity score of 10.0. The real figure, according to PHP’s own developers, is 9.2. No technical details had leaked yet.

Wednesday, October 21 — PHP released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing CVE-2026-109618 and CVE-2026-109619. The flaws were in PHP’s core engine, in the memory management and error handling that nearly every request touches. Separately, Microsoft and ConnectWise attributed the Cloud Backup campaign to Storm-0940, using the ARTEX agentic AI framework.

The keys sat in live certificates for about a year and a half before anyone noticed. The disclosure came from an independent researcher named “Wayne,” running a routine check against the Common CA Database. He recovered all eight from the public certificates in under a second and signed a message with each to prove it. The affected keys were from a batch of 24 intermediates; six issue TLS certificates for websites and two are used for code signing, and Sectigo had cross-signed all eight in May 2025.

The full ceremony details. According to eMudhra’s own account, the eight certificates were created during a Key Generation Ceremony on April 30, 2025, using FIPS 140-2 Level 3 Hardware Security Modules. A flaw in the ceremony script caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong ones — and because their labels closely resembled the good keys, staff selected the weak ones when preparing the certificates. The specific private key values behind the eight compromised certificates were 4, 56, 115, 66, 155, 156, 230, and 237 — each a nominally valid P-384 key whose scalar value was trivially small.

The response. Chrome and Firefox blocked the certificates the same day the report landed. Apple followed October 19, Microsoft October 20. eMudhra revoked them within fourteen hours of learning about it. The Go project treated it as a vulnerability — CVE-2026-111943 — and shipped emergency releases 1.27.3 and 1.26.10 that reject certificate chains using the eight keys. That mattered more than it sounds: Go underpins Docker, Kubernetes, Terraform, Prometheus, and a large share of cloud-native infrastructure, and applications only pick up the fix when they are rebuilt.

What was still exposed. Browsers are protected. What is not automatically protected is everything with an embedded trust store — older devices, appliances running older operating systems, non-browser clients, and anything using a bundled certificate list from before the blocks. Devices with no reliable revocation mechanism can still trust these certificates. It is not known whether anyone recovered and used the weak keys during the seventeen months before the report.

Cloudflare updated its own shared trust stores, base images, and the WARP and Tunnel clients; most of the platform took care of itself. The parts that needed hands-on attention were ours.

The lesson for us: a trust store is a piece of software too. It ages. It is rarely inventoried. It is very rarely tested. An appliance bought five years ago for $800 carries a certificate list from five years ago, and that list quietly decides who it trusts.

On October 22, eMudhra announced it is leaving the global SSL/TLS certificate business entirely.

What the two bugs actually were. They are related but distinct, and the distinction matters for cleanup:

• CVE-2026-109618 — remote code execution via out-of-memory corruption. If a request hit PHP’s memory_limit at exactly the wrong moment, PHP could abandon the request through a longjmp() and leave partially initialized internal data behind. Later, that data got treated as valid.
• CVE-2026-109619 — remote code execution via stale global state. A fatal error at the wrong point could leave internal state pointing at memory belonging to an earlier request. A later request handled by the same worker could then use that freed memory.

On Apache with mod_php, an unauthenticated request could trigger this before any application code ran. Datadog reproduced it on PHP 8.5.11 with a plain unauthenticated HTTP POST and confirmed the part that keeps people up at night: application-level authentication does not block it. PHP processes the malicious request before your login code ever executes.

The part that should have made the news. A PHP core developer found the first signs of the out-of-memory bug in 2024, while fixing an unrelated issue from PHP’s first external security audit in years. A potential exploit was theorized at the time. But no concrete attack vector was ever produced, so clearer problems took priority. When the security team did pick it up, they drafted several competing fixes — one broke backward compatibility, one introduced a new denial-of-service risk, one would have required changes across thousands of third-party extensions. The team ran on consensus, feared shipping the wrong choice, and the work stalled and restarted for months.

Then it was found for real, and in August 2026 two groups reported it independently: Calif, a California security firm working inside OpenAI’s Patch the Planet program, with a researcher using GPT-5.6 Sol to audit PHP’s source; and Wiz, using Gemini 4 Argon, GPT-5.6 Sol, and their own Wiz Atlas tool. PHP’s own developers rated the flaw 9.2 critical. watchTowr rated it a flat 10.0.

PHP’s Foundation said it plainly: “We won’t pretend otherwise: the delay was a structural failure, caused by both the security team’s decision process and its lack of resources.” The Foundation runs on roughly 13 full- and part-time staff. It has published 15 CVEs since the start of July and worked through more than 100 reports that proved invalid or duplicates.

How the embargo broke. It broke in three steps, and each one made exploitation easier. First, on October 20 around 15:00 UTC, the CVE identifiers surfaced on forums and social media with a wrong release time and a wrong 10.0 score — no technical detail, but the disclosure clock was running. Second, Calif mistakenly published a proof-of-concept video around 20:00 UTC showing the exploit working against real targets; they deleted it, and copies spread. Third, Chainguard published prebuilt container images containing the fix more than six hours ahead of the release, which let attackers study the patch in binary form while everyone else waited. PHP had moved its release up a day, from the 22nd to the 21st, and dropped the embargo to compensate.

The patch. PHP shipped 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Source patches went out for 7.4, 8.0, and 8.1, but those branches are end-of-life and got no binaries. Temporary mitigations were published, and the maintainers were explicit that there was no complete mitigation — updating was the only safe choice.

The application-level guidance. PHP’s remediation guidance notes that the stale state that CVE-2026-109619 exploits can be created by something that happened in an earlier request — an application-level fatal error or timeout. Fixing those in your own code is part of the fix.

Was it exploited? Amazon’s threat intelligence identified a PHP2Shell exploitation attempt dating to October 17 in MadPot telemetry — three days before the public disclosure. Cloudflare reported signs of early exploitation and deployed temporary WAF rules as a stopgap before the patch. watchTowr observed exploitation in the wild through its honeypot network on October 21. CISA had not observed exploitation as of that same day, which is a statement about visibility rather than safety.

How it worked, and why MFA did not help. The credential was a client assertion living in ConnectWise’s own tenant. That matters more than it sounds: application credentials do not authenticate as a user, so there is no user sign-in, no MFA prompt, and no password to steal. The attacker authenticated to the application exactly the way the backup service does, and received Microsoft Graph tokens carrying the application’s existing permissions. On October 15, tenants across multiple partner accounts saw sign-ins from a single hosting provider address at hours when no backup job should be running.

The permissions were broad by design. A backup service that can restore mailboxes, files, and directory data needs to read and write all of it. An attacker holding those tokens can read the same things.

Scope. Huntress confirmed unauthorized sign-ins in 162 tenants as of October 16, with the potential to reach every tenant where the application was consented — the credential works against all of them, not just the confirmed ones. In affected environments the application granted itself Global Administrator, then planted new credentials on other applications to hold the door open.

Who did it. On October 21, Microsoft attributed the campaign to Storm-0940, a China state-aligned group active since 2021, and ConnectWise’s CEO confirmed the finding. Microsoft’s analysis showed the group used ARTEX, an agentic AI penetration testing framework, to automate scanning, password spraying, and OAuth application abuse across hundreds of organizations. In several cases the time from initial targeting to privileged access was under three hours.

That last detail is the one worth sitting with. The same AI-assisted research that made the PHP flaws practical is now showing up in nation-state attack tooling. The barrier to exploiting a decade-old bug, and the barrier to reaching a hundred tenants, both just dropped.

Separately from the Cloud Backup incident, ConnectWise patched a critical ScreenConnect vulnerability — CVE-2026-84869 — affecting versions prior to 26.6.5. Under specific circumstances, files could be transferred and executed through an active remote session without host confirmation. It was rated 9.9, added to CISA’s Known Exploited Vulnerabilities catalog, and exploited in worm-like attacks.

We had already worked this one before it turned critical. When the advisory landed in September, we did not simply patch and move on. We built a ThreatLocker tag, policy, and script to target and remove vulnerable ScreenConnect clients, and we deleted every learned or custom ScreenConnect application across client tenants, leaving only the built-in application with its policies disabled.

The reason to delete the custom applications rather than patch them: a remote access tool that can transfer and execute files during a session is a legitimate tool with a very small blast radius, until it is not. We replaced it with a controlled, managed version.

Here is what changed, and why the legacy estate is where it lands hardest.

Discovery went to machine speed. In January 2026, when OpenSSL shipped a release containing twelve zero-day vulnerabilities, an AI system had already found all twelve independently — and in five cases proposed patches that made it into the official release. In April 2026, Anthropic documented its Claude Mythos Preview identifying thousands of previously unknown vulnerabilities across every major operating system and browser. Its flagship find was CVE-2026-4747, a stack buffer overflow in FreeBSD’s kernel NFS implementation that had survived seventeen years of code review, multiple security audits, and years of fuzzing campaigns — with working exploits generated without human guidance.

The economics are what should stop an administrator cold. One AI agent swarm identified more than a hundred exploitable kernel vulnerabilities across the AMD, Intel, NVIDIA, Dell, Lenovo, and IBM driver codebases over a thirty-day run, at a compute cost of roughly six hundred dollars. Research from 2025 into early 2026 documented AI systems generating working CVE exploits in ten to fifteen minutes, at about a dollar per attempt.

The exploitation window went negative. Mandiant’s M-Trends 2026 report, built on more than 500,000 hours of incident response engagements across 2025, put the mean time to exploit newly disclosed vulnerabilities at an estimated negative seven days — exploitation begins, on average, before a patch exists. CrowdStrike’s 2026 Global Threat Report found the average eCrime breakout time fell to 29 minutes, with the fastest observed at 27 seconds, and one intrusion beginning data exfiltration within four minutes of initial access. Mandiant also found the median time from initial compromise to lateral movement dropped from more than eight hours in 2022 to twenty-two seconds in 2025.

The defender’s side of the ledger has not moved. Qualys’s 2026 Enterprise Patch and Remediation Benchmark found the mean time to remediate critical vulnerabilities in complex enterprise applications reached five months and ten days. At the moment of disclosure, 85% of vulnerable enterprise assets were still unpatched. Three months later, 12% were still exposed. Edgescan’s 2025 statistics put the twelve-month figure at 45.4% of discovered vulnerabilities still unpatched. CISA’s Known Exploited Vulnerabilities catalog carries a two-week remediation mandate for federal agencies, and research from 2024–25 found more than 60% of known exploited vulnerabilities still miss their deadlines.

And this is precisely where legacy lives. The five-month-and-ten-day figure is not spread evenly. It is driven by high-complexity applications — Java runtime environments, .NET frameworks, Citrix Workspace App — where compatibility testing alone consumes weeks. The software that predates AI is disproportionately the software with the longest lead time to a fix, because the fix has to be tested against everything that has piled up around it since 2009.

Then there is the harder half. A large share of the estate has no fix coming at all. End-of-life software is not a patching problem; it is a replacement problem, and replacement needs a date. runZero’s research puts the enterprise-wide end-of-life population tripling, from roughly 5% to around 16%, with about a third of enterprise Windows assets losing support. The PHP story is the same story in miniature: the maintainers were explicit that there was no complete mitigation for the parts of PHP 5.4 through 8.1 that had no supported binaries, and that updating was the only safe choice. The Cyber Hero Team’s advisory made the same point from a different angle — because PHP is embedded across many products and services, controls have to be tailored and tested for each environment rather than applied once.

There is a pattern here that I do not think has been fully absorbed yet. AI-assisted discovery is disproportionately surfacing bugs in old, stable, long-lived code — the seventeen-year-old FreeBSD NFS bug is the emblematic example, and the OpenSSL release is another. That is not a coincidence of where researchers happened to look. It is where the untested decades accumulate. And old, stable, widely-deployed code is exactly the code that has the worst upgrade path.

So the honest uncomfortable conclusion: for a meaningful slice of any environment, there is no patch strategy. The system either gets replaced on a date you chose, or it gets exploited on a date someone else chose. Making that replacement date explicit is the entire job.

The counterweight, honestly stated. AI is helping defenders too, and it would be dishonest to present this as one-sided. Qualys’s Agent Val validates exploitability continuously instead of trusting a static score. The PHP Foundation now scans its own code with Anthropic’s Claude Mythos and validates incoming reports with OpenAI’s Daybreak. Microsoft and GitHub ship AI-assisted auto-remediation. CrowdStrike launched Project QuiltWorks in April 2026 as an industry coalition for exactly this problem, with Accenture deploying twenty-seven agents to automate vulnerability assessment and prioritization across its client base.

The realistic near-term read, from Recorded Future’s H1 2026 trend analysis, is not a sudden flood of fully autonomous exploitation. It is a narrower window in which to decide which vulnerabilities actually matter and remediate them before someone else operationalizes them. And that help only lands if you know what you are running, can tell an exploitable path from a frightening score, and have hours available to act. Which is exactly where legacy estates fail hardest.

Fourth, in full. The research that made the PHP flaws findable was substantially AI-assisted — Gemini 4 Argon and GPT-5.6 Sol reading PHP’s source, at the edge of what human researchers could practically achieve. Three days later, the same capability showed up on the other side of the fence, in the hands of a nation-state group using agentic AI to compromise hundreds of organizations. The practical bar for both finding and exploiting a decade-old flaw dropped in the same week. And AI is already on the defensive side too: PHP’s Foundation now scans its own code with Anthropic’s Claude Mythos and validates incoming reports with OpenAI’s Daybreak. If your risk assumptions were built when that bar was high, they are now too comfortable — and if your security program assumes humans are the only ones reading source code, that assumption expired too. The asymmetry that matters most, though, is not AI against humans. It is AI against process: a machine that finds and weaponizes a flaw in minutes does not have to wait for a change advisory board.