Biggest Patch Tuesday ever - October. 4 Windows CVEs contributed : Part-1

October 13, 2026 was a long day for anyone who patches Windows. Microsoft shipped its biggest Patch Tuesday ever: roughly 1,413 CVEs in one release.

September had set the record at 974 just a month earlier. October beat it by about 45 percent. Windows alone took 1,102 fixes, 80 were rated Critical, and one Windows Shell bug (CVE-2026-96951) was already being exploited in the wild.

4 of those CVEs are ours. I found them with the HiveForce Labs team, Hive Pro’s threat intelligence unit. We responsibly reported them to MSRC and reproduced each one end to end on the latest Windows 11 build.

MSRC credits the discoveries to Owais Lone of HiveForce Labs, as listed in Microsoft's Security Update Guide acknowledgements.

How big was it?

If you look after Windows machines for a living, you probably felt October 13, 2026 before you read about it. Microsoft shipped its biggest Patch Tuesday ever, and patch queues everywhere got a lot longer overnight.

Here is how big it was:

The severity split covers the 1,407 CVEs Microsoft rated; the rest carry no rating. Counts also vary a little between trackers, from 1,407 to 1,413. I have used Microsoft's own release notes figure.

So why are the numbers climbing this fast?

A big part of the answer is AI. Monthly CVE disclosures grew about 145 percent between June 2024 and June 2026, as researchers started using AI to find vulnerabilities much faster than before. Even this month's exploited Windows Shell zero-day was reportedly found with an AI model.

Four of those 1,413 CVEs are ours. I found them with the HiveForce Labs team, Hive Pro's threat intelligence unit. We reported them responsibly to MSRC and reproduced each one end to end on the latest Windows 11 build before we sent anything in. Seeing them land in the release notes was a proud moment for the whole team.

MSRC credits the discoveries to Owais Lone of HiveForce Labs, as listed in Microsoft's Security Update Guide acknowledgements.

AI agents played a big part in how we found them. That story deserves its own post, so I wrote one: How the CVEs Were Discovered.

This blog covers the following: the four vulnerabilities with their severity and attack vectors, what they can lead to, how they work, our recommendations, whether attackers can really use them, and whether your EDR will catch them.

The four vulnerabilities at a glance

One thing people asked me early on was whether these four are connected. They are not. These are four separate bugs, each one works on its own, and you do not need one to exploit another.

What they do share is the target: Windows Operating System. In every case the attacker either runs a malicious SSH server or hands you an archive.

The victim is simply the person who connects or extracts. Nobody needs an account on your machine, but each attack does need one action from the user, which in practice is something developers and admins do many times a day.

“One word of caution: do not let the "Important" label fool you. This month's actively exploited zero-day, CVE-2026-96951, was rated Important too.”

Impact: what can these lead to?

When I first got these working, my first thought was not "cool bug". It was "who uses these tools every day?" The answer is what makes them worth your attention.

How I found them

I will keep this light on code. If you want the full research story, including the dead ends, that is what the discovery blog is for.

The ANSI parser (CVE-2026-83754). Microsoft's Windows port of OpenSSH carries its own terminal parser, and almost nobody reviews it. It stores incoming parameters first and checks for space second. Worse, the variable sitting right after the parameter list is the counter that decides where the next write lands. Overflow it once and you steer every write after it. One line of input was enough to prove it. Exploit payload:

ESC[1;1;1;1;1;1;1;1;1;1;4000000000;7m

That one took a night's sleep to see. I had given up for the day, and the answer was waiting for me the next morning.

The console writer (CVE-2026-88157). The client writes server output through a fixed 100 KB buffer and always tacks a zero byte on the end. Fill the buffer exactly and that zero lands one byte too far. The client splits big output into exact 100 KB chunks, so a server just has to talk a lot.

The slash traversal (CVE-2026-83923). Upstream OpenSSH blocks file names containing / or \. Microsoft's Windows build only blocks \. Windows treats both as folder separators, so a server can hand back a name like ../../../../something and walk straight out of your download folder. My test server dropped a file in C:\Users\Public\ on the first try.

The tar escape (CVE-2026-69968). libarchive remembers which paths it has already checked, to save time. Creating a symlink does not clear that memory. So an archive that plants a symlink first, then writes a file "inside" it, gets waved through and lands wherever the symlink points. The moment I saw the one-line fix sitting in libarchive's master branch, everything clicked.

Recommendations

At Hive Pro we recommend a Mitigate First, Patch Faster approach. The order matters. First find out where you are exposed, then reduce the risk right away, then patch as fast as your processes allow.

1. Check your exposure

If you are a Hive Pro customer, you can answer this without scanning a single machine.

• Discover them with Predicted CVEs. Predicted CVEs tell you instantly whether these four vulnerabilities are present in your environment, with no scan needed.

• Validate them with BAS exploits. Run the BAS exploits for all four CVEs in the Hive Pro platform and see whether your controls actually stop them. If you need help, get in touch with your account executive or customer success manager.

• Do not forget this month's exploited zero-day. Our four are not the only ones worth testing. A BAS simulation for CVE-2026-96951, the Windows Shell Mark of the Web bypass that attackers are already using in the wild, is also ready and available to Hive Pro customers. If you only test one thing this month, make it that one.

As soon as MSRC published the CVEs, my first move was to start building these BAS exploits. I wanted our customers covered from day one, not weeks later.

This comes from experience. Before Hive Pro, I worked at product-based companies where the scanner's severity rating decided what got fixed, not whether something could actually be exploited. I watched teams rush to fix a weak cipher finding because it was rated High, while a Medium that gave an attacker far more control sat in the queue.

Personally, I have also seen CVSS mislead in more than one case, and I do not think it can be relied on alone. That is why an exposure-based approach, the way we do it at Hive Pro, makes much more sense to me: find out what an attacker can really do in your environment, and fix that first.

2. Mitigate first, then patch

The simplest fix is to patch all four. The patches ship in the October 2026 Windows cumulative update, so there is no separate OpenSSH package to chase. Push it through Windows Update, WSUS, Intune or whatever you already use.

If the patch rollout will take a while because of internal policies and processes, use these mitigation measures to reduce the risk in the meantime:

• Only download folders from servers you trust. The folder-copy commands (scp -r and sftp get -r) are how CVE-2026-83923 drops files in the wrong place. Until you patch, avoid using them with servers your team does not own or control.

• Open unknown archives in a safe place. If you have to unpack a tar file from outside your organization, do it with a standard user account (not an admin) and inside an empty, temporary folder. That way, even if the archive tries to escape, it cannot reach anything important.

• Stop untrusted accounts from creating shortcuts to other folders. The tar bug (CVE-2026-69968) relies on creating a special kind of shortcut called a symbolic link. Windows controls this with a setting called SeCreateSymbolicLinkPrivilege. Remove it from any account that unpacks outside archives, and the attack simply stops working.

• Leave Windows' built-in terminal support switched on. Modern Windows 10 and Windows 11 handle SSH screen output themselves, which bypasses the buggy code behind CVE-2026-83754 completely. It is on by default, so the main thing is not to turn it off, and to avoid running ssh through scripts that pipe or redirect its output.

3. Watch for risky habits

Some teams are more exposed than others, usually without realising it. Your risk goes up if developers run scp -r from CI pipelines, if service accounts unpack third-party tarballs, or if people run ssh through piped or redirected shells, which quietly routes server output through the vulnerable parser. These are worth a conversation with your engineering teams.

Can attackers really use these?

Short answer: yes, all four. But they are not equally easy, and it is worth knowing which ones to worry about first.

The SFTP traversal is the easy one. One malicious server, one recursive download, and a file lands wherever the attacker wants. Drop it in the Startup folder and it runs at the next logon. No clever exploit needed. This is the one I would patch first.

The tar escape is close behind. Anything that unpacks user-supplied archives on an elevated machine is a target. CI build agents and installers come to mind straight away.

The two memory bugs take more work. The ANSI bug gives an attacker a controlled write inside the SSH client, which a skilled attacker can turn into code execution. The console bug reliably crashes the client, and could go further with careful effort. Harder, yes. Out of reach, no.

Will your EDR catch it?

No. I wish the answer were better, but it is worth being honest about.

SSH traffic is encrypted, so nothing on the network can see a poisoned escape sequence or file name. On the endpoint, a good EDR may flag sftp.exe, scp.exe or tar.exe writing into places like the Startup folder, but the memory bugs stay quiet unless the client crashes or the attacker does something noisy afterwards. Application control helps a little here too: it will not stop the bugs, but it can stop an unknown program dropped into Startup from running.

That is why we recommend SOC teams do proactive, hypothesis-based threat hunting rather than wait for an alert. There is no malicious IP or file hash to block here, because every attacker's server and archive will be different. What stays the same is how these tools behave when something goes wrong.

Threat hunting: what to look for

If you use Microsoft Defender for Endpoint, this query covers the first two hunts:

DeviceFileEvents
| where InitiatingProcessFileName in~ ("scp.exe", "sftp.exe", "tar.exe")
| where FolderPath has_any (@"\Start Menu\Programs\Startup", @"\Users\Public\", @"\Windows\", @"\ProgramData\")
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, ActionType, FolderPath, FileName

Any hit deserves a closer look.

Final thoughts

A huge thank you to the HiveForce Labs team for the long days and the patience, and to MSRC for working through our reports in the middle of a record month.

Safe simulations of all four CVEs are now live in the Hive Pro BAS module, so you can test whether your controls catch them without going anywhere near a real attacker's server.

This is part of something bigger for us: a growing library of zero days, N-days, advanced attack chains and CVE exploits you can run against your own environment, safely, before someone else does.

Curious how we actually found these four, and how much AI agents helped? Read the companion blog, How the CVEs Were Discovered.

Sources

• October 2026 Security Updates, release notes, Microsoft Security Response Center, October 13, 2026
• MSRC Security Update Guide entries: CVE-2026-83754, CVE-2026-88157, CVE-2026-83923, CVE-2026-69968
• Zero-Days Lurk in Microsoft's Overgrown October Patch Tuesday, Dark Reading, October 13, 2026