PHP2Shell was exploited four days before the patch existed.

PHP2Shell was exploited four days before the patch existed. Roughly 1.57 million hosts are still unpatched

This week gave us a real-world test case. Microsoft reported that from October 10 to 14, the China state-aligned group Storm-0940 launched an automated password-spray attack against 327 accounts across eight organizations. That's over 151,000 failed logon attempts. The outcome? No successful logins, no tokens issued, no directory changes. Lockouts stopped about 98 percent of the attempts. In other words, decades of investment in identity controls did exactly what they were supposed to do.

But the story doesn't end there. The same group obtained credentials for ConnectWise's multi-tenant Microsoft 365 applications and, within minutes, signed in to hundreds of customer tenants. There was no password to guess; applications don't use them. No MFA prompt, since MFA is designed for people, not software. No lockout, because the attack succeeded on the first try. The attacker didn't break through our identity controls. They simply walked around them, using a route those controls were never built to cover.

Here's the order, based on urgency rather than severity score. All four have been exploited in the wild. The recap table includes two more, one with a CVSS of 10.0, but you have little choice about these four. Always double-check every detail against the vendor advisory before acting.

• PHP: CVE-2026–109618 and CVE-2026–109619, CVSS 9.2 (v4.0). Exploited four days before the patch existed. Amazon Threat Intelligence detected an exploitation attempt on October 17, while the flaws were under embargo; the embargo broke on October 20, and the emergency releases shipped on October 21. Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with backports for the end-of-life 7.4, 8.0 and 8.1 branches; SecurityWeek says nearly all releases back to 5.4 are affected. Censys counted about 2.58 million internet-facing PHP hosts on October 21, roughly 1.57 million of them unpatched. Do not wait for a KEV entry. Wiz, OpenAI, and Calif found it independently and reported it to the PHP Foundation on August 11.
• Plex Media Server: CVE-2026–96652 (5.3), CVE-2026–96654 (6.9), CVE-2026–96655 (5.3) and CVE-2026–96656 (8.6). Exploited one day after the write-up went public. Chained, they grant code execution with the Plex service's privileges and no valid credentials; BleepingComputer reports the researcher scored the full chain 9.8. The team fixed it in 1.43.3.10861, released in early August. Details went public October 16, and in-the-wild exploitation followed on October 17, dropping the XMRig miner and a proxy backdoor. CISA's federal deadline for CVE-2026–96656 and CVE-2026–96654 is October 23, with the other two due November 3. If yours is exposed on port 32400, assume compromise. Zach Main reported it and also published detections.
• Arista VeloCloud Orchestrator: CVE-2026–114625, CVSS 9.9. Zero-day, exploited, patched October 22. SQL injection in the on-premises orchestrator, the management plane for an organization's SD-WAN. Neither outlet I read publishes a fixed build string; get it from the advisory. The reporter isn't credited in the reporting I read.
• Siemens Software Center: CVE-2026–110936, CVSS 8.4 (v4). Exploited. An uncontrolled DLL search path allows a local authenticated attacker to execute code. Advisory SSA-580366; affected version 3.5.8.7, fixed in 4.0.9.8. Siemens confirmed in-the-wild exploitation on October 19, and CISA added it to KEV. The delivery route is the interesting part: the ClickFix platform Forescout calls Romulus, with lures distributed partly through custom ChatGPT GPTs. Siemens states no Siemens system, product, or update channel was breached. Reported by Jose Oregon of Huntress.

Prioritize PHP above everything else, not because of the CVSS score, which is almost routine these days, but because of timing. Attackers were exploiting the vulnerability before anyone outside the embargo even knew it existed. Rapid7's latest analysis shows the average time from disclosure to exploitation is just three days, and 71 percent of high-severity flaws are hit within a week. Think about your emergency patching process: if it requires a ticket, approval, and a maintenance window, it probably can't keep up.

Sources: SecurityWeek and SecurityWeek on the pre-patch exploitation · Krebs on Security · CyberScoop · BleepingComputer on PHP · The Hacker News and BleepingComputer on Plex · The Hacker News on Arista · SecurityWeek on Siemens · SecurityWeek on Rapid7

Attackers obtained ConnectWise Cloud Backup (formerly SkyKick) credentials and six sibling Cloud Management identities covering Exchange Online, Teams, SharePoint Online, Graph, and Partner Center. Huntress confirmed unauthorized sign-ins in 173 tenants per The Hacker News, or 162 per BleepingComputer and CyberScoop; sign-in activity touched almost 1,000 Entra tenants with roughly 300 succeeding. Microsoft attributes the campaign to Storm-0940 and says it used ARTEX, an open-source multi-agent LLM penetration testing framework, to attempt sign-ins to more than 2,250 tenants, describing over 200 sign-ins in under four minutes using four application credentials.

The most important detail here isn't how many accounts were touched; it's how you fix the problem. As Nicholas Koken at Todyl points out, revoking user sessions won't stop this kind of access. Resetting passwords, revoking sessions, and re-enrolling MFA are habits built for human accounts. They don't help when a service principal has a valid client secret. Even disabling the compromised integration isn't enough: new secrets, changed role assignments, and mailbox forwarding rules can all persist after the connector is shut down. ConnectWise's own guidance spells this out.

A quick note on the numbers, since they're reported inconsistently: confirmed and suspected cases aren't the same. Microsoft's figure of 2,250 refers to attempts, not successful compromises, and they haven't said how many customers were actually affected. ConnectWise says it hasn't seen successful threat activity in the environments it monitors, but that doesn't mean individual partner tenants weren't hit, a technically accurate answer that leaves the real question open. If you're a ConnectWise partner, only your own sign-in logs from October 15 count as evidence.

Sources: CyberScoop and CyberScoop on the Storm-0940 attribution · Microsoft Security, the primary source for the password-spray figures and the ARTEX detail · The Hacker News · BleepingComputer · Dark Reading. Dark Reading's standfirst says 2,200 tenants, whereas its body and Microsoft say 2,250

BeyondTrust disclosed CVE-2026–102764, a CVSS 9.3 authentication bypass via spoofing in Remote Support, affecting all versions up to and including 26.2.3. Mandiant and the Google Threat Intelligence Group attribute exploitation to the suspected China-nexus actor they call ARMORY CASTLE, previously UNC5221. First known exploitation was August 29; the patch shipped October 8. That is forty days. Shadowserver counts over 1,400 BeyondTrust remote support instances exposed online, and CISA set a federal deadline of October 19.

The real issue isn't just patching. This appliance is designed so a help desk technician can reach any endpoint and authenticate as a privileged user, which means it stores, brokers, or injects credentials for everything it touches. That's why BeyondTrust's most important instruction sounds tedious: rotate every credential the appliance ever stored or injected. Not just its own credentials, every single one it handled. If your team patched this in October and closed the ticket, ask yourself on Monday whether anyone actually rotated them, and whether anyone can even list all the credentials involved.

One claim I want to flag, not repeat. Ed Skoudis wrote in SANS NewsBites that BeyondTrust's high-severity detections fired in real time, but a third-party triage tool automatically closed them as false positives, and that a separate intelligence-driven hunt ultimately found the intrusion. If accurate, that is the sharpest cautionary tale of the week. I read the full Mandiant and GTIG write-up, and it doesn't address this at all, and none of the outlet articles I read mention it, so I am attributing it to Skoudis rather than stating it.

Sources: Google Threat Intelligence Group and Mandiant, the primary write-up · SecurityWeek · The Hacker News · CyberScoop · BleepingComputer. The Skoudis detail is from SANS NewsBites 28.78, cited as text because NewsBites uses click-tracking links

For each incident, ask yourself: what did the attacker actually get their hands on? In ConnectWise, it was four application credentials. For BeyondTrust, it was whatever credentials the remote support appliance stored or injected. At eMudhra, eight intermediate CA keys were so weak that a researcher cracked them in under a second. OVHcloud lost control of a contributor's GitHub account, which was then used to swap out five CLI releases for malicious ones. LiteLLM had a leaked token. UpdraftCentral lost its own management keys. In six out of seven cases, the breach hinged on a secret that no human logs in with, that no MFA policy protects, that password rotation never touches, and that triggers no alert when used, because its job is to be used. Compare that to the 151,000 failed attempts against human accounts that went nowhere. The controls we built for people are holding up. The identities we never thought of as identities are wide open.

Let's pause this week and challenge the main narrative: AI-driven attack automation. Yes, ARTEX hit 2,250 tenants, and advanced models are finding vulnerabilities like PHP2Shell. The scale is real and deserves attention. But what did automation actually accomplish? On offense, it made a failed campaign bigger, not better. On defense, it helped find the worst vulnerability before attackers did. Rapid7's data shows AI played a role in only 8 percent of incidents last quarter. The breach that mattered relied on stolen secrets and a standing consent grant-the same technique that would have worked years ago. The machines made things faster, but they didn't make them possible.

Here's another challenge, this time to my own advice. Telling people to inventory all their non-human identities rarely works. You end up with a spreadsheet that's accurate for a few weeks, but nobody revokes anything because every entry supports a workflow someone depends on. So let's narrow it down. Don't try to inventory everything. Instead, identify the integrations with application-level permissions to read all mail or all files, not delegated, but application permissions. There are probably fewer than you think, maybe three to a dozen, and that small group carries most of the risk. For each one, ask two questions: can we revoke it ourselves right now, and would we notice if it started reading everything at three in the morning?

Which third-party applications right now have a token that lets them read our mail or files without anyone logging in? Who approved each one, when does its credential expire, and if that vendor's secret leaked tonight, could we cut it off ourselves before they told us?

Pick one integration and answer all four questions. If you have to guess on the last one, that's your assignment for the week. Is it a guess for you? I'm interested in what you find.

Originally published at https://www.linkedin.com.