Three holes, one patched box, root
A fully patched Ivanti appliance was rooted on 3 October by chaining an authentication bypass, a file write, and a privilege escalation that still has no fix. The vendor's own integrity checker reported nothing wrong.
Volexity found the chain and tracked the activity to an actor they label UTA0576. It runs in three moves. The first is an authentication bypass in welcome.cgi that reaches protected CGI files you are not supposed to touch. The second is a file write in wu.cgi that turns that access into code execution. Those two share one identifier, CVE-2026-104935. The third is the ugly one, a privilege escalation in how the dsinvoked broker trusts DSCache configuration data, and it runs commands as root. It has no CVE assigned, it is still unpatched, and Ivanti says a fix is weeks out.
The demonstration was against 22.8R2.4, fully patched at the time, rated CVSS 8.6. "Fully patched" did not mean safe here, because one of the three holes had no patch to apply. The affected builds are 25.1.1.1 and prior, 25.1.2.2 and prior, and 22.8R2.4 and prior. The 22.7 line and below are not affected. Fixes landed in 22.8R2.5, 25.1.1.2, and the 25.1.3.0 or 25.1.3.1 builds.
The box passed its own integrity check while it was owned. There was no web shell and no file left on disk. The attacker re-ran the chain for each command and patched the library code in memory only, so Ivanti's Integrity Checker Tool saw an unmodified system. A clean checker was not evidence of a clean box.
What came out of it was the whole directory, not just the appliance. Volexity documents LDAP domain credentials, LAPS local admin passwords, BitLocker recovery keys, a custom Kerberoasting and credential testing tool, Active Directory metadata pulled out wholesale, password spraying, LDAP packet capture, log mining for usernames, and log tampering to cover the tracks. If this ran against your edge, you are not cleaning one appliance, you are rebuilding trust in a whole domain.
CISA added two of these to its Known Exploited Vulnerabilities catalog on 13 October, with a federal due date of 16 October: the Ivanti bug, CVE-2026-104935, and a Windows Shell bug, CVE-2026-96951. That second one landed in the same week as the largest Patch Tuesday anyone has on record.
I am not going to print one number for that Patch Tuesday, because the people who count for a living did not land on one. Tenable counted 1,407. BleepingComputer counted 1,411. SecurityWeek counted 1,413. Zero Day Initiative counted 1,415, and ZDI's own writeup admits the count is genuinely hard to pin down. Four careful sources, four answers. The honest version of this is the spread, not a single figure picked to sound precise.
The one source that states its boundary is BleepingComputer: its 1,411 is Patch Tuesday alone and leaves out a further 348 that Microsoft fixed earlier in the same month, which puts October closer to 1,759. SecurityWeek says it is more than all of 2025, though it does not print the 2025 figure it is measuring against, so that one is theirs to stand behind, not a settled fact. The breakdown the counts broadly agree on, across 301 products and components: Windows around 1,102, Office 134, developer tools 61, SharePoint 36. Between 69 and 70 are rated critical, depending on who is counting.
Three of the lot were zero days. CVE-2026-96951 is the one being exploited, a Windows Shell command injection at CVSS 8.8 that bypasses Mark of the Web, so a booby-trapped file opens with no SmartScreen prompt, no Protected View, and no warning banner. It still needs the user to open the file, and it reaches Windows 10, Windows 11, and Server from 2012 R2 through 2025. CVE-2026-108398 undermines WDAC enforcement in .NET, was publicly disclosed, and was found by James Forshaw at Google Project Zero. CVE-2026-92707 is a denial of service in MessagePack-CSharp. Neither of those last two is under attack.
In the same stretch, Meta told about 1,500 people their data turned up in a GitHub breach. An outside group used one employee's stolen credentials to reach Meta's GitHub repositories. Meta's own accounting is about 99 percent product source code and about 1 percent personal data, mostly US employees, and much of that was synthetic or anonymised test data that had been committed against policy. Meta says its internal systems and product vulnerabilities were not involved. Notifications started on 13 October.
What to actually do with a week like this: patch the exploited things in the order CISA set, plan around the hole that has no patch, stop trusting a vendor's own checker, and read a disputed count as a dispute instead of a number.
1. Patch the two exploited bugs first, by the sixteenth
CISA put both known-exploited bugs on the clock with the same due date. Treat that date as yours too, federal mandate or not, because "exploited in the wild" means someone already wrote the tool.
# CISA KEV, added 13 Oct, federal due date 16 Oct
# CVE-2026-96951 Windows Shell, Mark of the Web bypass, exploited
# CVE-2026-104935 Ivanti Connect Secure, the auth-bypass + file-write chain
# Ivanti Connect Secure builds
# affected : 25.1.1.1 and prior, 25.1.2.2 and prior, 22.8R2.4 and prior
# not affected : 22.7 and below
# fixed in : 22.8R2.5, 25.1.1.2, 25.1.3.0 or 25.1.3.12. Plan around the third hole, because there is no patch for it
The privilege escalation that turns a foothold into root has no CVE and no fix, and Ivanti puts the fix weeks away. You cannot patch your way out of this one yet, so you shrink what an attacker reaches if they land the first two.
# no patch, so assume the first two can be chained to root
# keep the appliance off the open internet, behind restricted access
# watch for the post-exploitation behaviour, not only the entry
# rotate what a rooted edge box could have read:
# LDAP creds, LAPS passwords, BitLocker recovery keys, Kerberos ticketsDo not wait for a CVE id before you take it seriously. A missing identifier is a paperwork state, not a safety one.
3. A clean integrity check is not a clean box
This is the part worth keeping long after these specific bugs are closed. The attacker patched library code in memory and re-ran the chain per command, left no web shell and nothing on disk, and the vendor's own Integrity Checker Tool reported no modifications. The tool answered "healthy" to a question it could not actually answer.
# a checker that only reads disk cannot see a memory-only implant
# trust memory and network forensics, not a self-check that passes
# capture volatile memory before you reboot (a reboot destroys it)
# diff outbound connections against a known-quiet baselineWhen a health check would let you stand down, prove it with something that would actually fail if the box were owned, not the status call that fails open.
4. Mark of the Web is a seatbelt, not a lock
CVE-2026-96951 strips the warning that normally fires on a file that came from the internet. No SmartScreen, no Protected View, no banner. The thing that catches most people most of the time was simply gone, which is why patching matters more than usual here.
# the bug removes the warning, not the need to open the file
# patch closes the bypass
# until it is patched, the only gate left is the person not opening it5. Read a disputed count as a dispute
Four sources counted this Patch Tuesday and got 1,407, 1,411, 1,413 and 1,415. None of them is wrong. They draw the boundary in different places, which is exactly why one confident number is the least honest way to report it.
# why the totals differ
# Patch Tuesday only, or the whole month?
# BleepingComputer's 1,411 excludes 348 fixed earlier in October
# counting the month puts it near 1,759
# ZDI says the count itself is hard to settle
# report the spread and name the source. do not launder it into one figure.Related: read the log before you believe your own story is the same instinct, that the evidence beats the summary, pointed this time at a vendor's checker instead of your own memory.
Sources
Primary reporting, so you can check the count and the chain yourself rather than taking mine.