It’s the second Tuesday of the month, and that means another Microsoft Patch Tuesday. The new normal is that the numbers are hard to believe. Brian Krebs reports that this month’s release fixes nearly 1,100 vulnerabilities, 63 of them rated critical, and over 500 that let an attacker elevate their privileges. Only one is reported as actively exploited: CVE-2026-124194, a spoofing bug in Outlook.

Microsoft has now shipped more than 5,100 security fixes this year, after more than 1,400 last month, compared to an average of around 100 a month last year. Obviously AI tools get the credit for the volume of bugs fixed, but also of course for the volume of bugs found.

Everyone else is busy too. Apple pushed out-of-cycle updates for at least nine vulnerabilities across its operating systems, including an iMessage flaw which could let a remote attacker join a group chat and read its messages, and backported the fixes to iOS 18.

Chrome 157 fixes CVE-2026-125350, another Chrome zero-day, a week after a Chrome release which fixed more than 200 bugs, Firefox 160 fixes almost 100 CVEs, and Adobe fixed more than 110.

Also since last week, zlib 1.4 shipped with more than a dozen security fixes, eight more vulnerabilities were disclosed in the X.Org server and XWayland, and Microsoft’s own Azure Linux update lists more than 470 CVEs fixed across the open source packages it ships.

And for a perfect encapsulation of 2026, last month’s Patch Tuesday included a remote code execution bug in Windows Paint (CVE-2026-83844), though its description admits the code runs locally. So now I guess you can pop Calc through Paint? Does this count as a win?

Despite the absolute firehose of vulnerabilities, the Krebs article notices that of the roughly 95,000 CVEs assigned this year, only around 200 made it into the CISA list of known expoited vulnerabilities (KEV). If you have to pick and choose which updates are the most critical, start there.

Last week we covered sshole, the bug where OpenSSH on musl libc without PAM accepts any long enough password for accounts that shouldn’t take a password at all. (And we had a serious moment thinking about putting “sshole” in the article title.) It now has a CVE, CVE-2026-123158, and Ars Technica reports that it’s already being exploited.

GreyNoise says honeypots it runs in Southeast Asia were hit by a group it tracks as GT10, which installed Python in order to run a backdoor with Chinese-language comments that appears to have been written with AI. WatchTowr reports exploitation tied to botnets and cryptocurrency, and Previdian has seen attempts from thirteen IP addresses in nine countries.

CISA added it to its KEV catalog on November 9, with a deadline of just three days for federal agencies to patch.

Kevin Beaumont points out that, in practice, the affected population looks like Alpine Linux. Debian, Ubuntu, SUSE, Red Hat, and CentOS aren’t affected, and neither is stock OpenWrt, which uses Dropbear instead of OpenSSH.

The researcher who found the bug suggests checking other musl-based systems like OpenWrt with OpenSSH installed, Buildroot, and Yocto, along with “a lot of the docker images you’ve pulled.” The OpenSSH 10.6p2 release notes credit Özgün Kültekin of Wakefield with the report, and include a notable comment about the current state of things: the OpenSSH team has “seen a number of cases where a security bug identified by

AI tools is subsequently independently discovered by a different researcher,” so they’ll be making more frequent releases instead of batching fixes.

“Type a really long password” as a way past authentication isn’t new, unfortunately. Back in 2014, a five-year-old found he could log into his dad’s Xbox Live account by filling the password verification screen with spaces, and Microsoft added him to its list of credited security researchers.

If you run Alpine anywhere with SSH reachable from the Internet, update OpenSSH, or at minimum turn off password logins with “PasswordAuthentication no”. I suppose it’s the flip side of the password “4” for your certificate authority? (More on this below.)

GitBook, the documentation platform used by a lot of open source and commercial projects, has published a post mortem on a breach on November 2.

An attacker used a flaw in GitBook’s single sign-on flow to create login sessions as GitBook staff, used those sessions to pull the credentials of a misconfigured GitHub App in GitBook’s own organization, used that to get into GitBook’s internal code repositories and eventually a Cloudflare API key, and used that key to get production secrets with full infrastructure access.

If you tried to access documentation or manuals for something and it failed mysteriously, you might now know why.

GitBook took the entire platform offline for about 16 hours while it rotated every secret, revoked API tokens, and rebuilt its infrastructure, which is a painful but correct call when you don’t know what an attacker can still reach. GitBook believes the attack was aimed at a single customer, but is treating all customer data as exposed.

That includes API and integration tokens, session signing secrets, and, most concerning, the ability to act as the GitBook app in any GitHub or GitLab repositories customers had connected to it. GitBook says it can’t determine whether the attacker took any action in those repositories.

Each step in that chain is a familiar mistake, but strung together they go from a login bug to the source code repositories of…