Black October: PHP CVEs, LiteLLM supply-chain attack and weak CA keys make the case for passkeys

Four incidents behind the nickname

October 2026 has picked up the nickname "Black October" in security circles. A dev.to post documents the incidents behind the label and argues the month should also be the moment people finally move off passwords and SMS-based codes.

According to the post, four events define the month:

• PHP2Shell: two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, reported on October 21. Because PHP runs roughly 70% of websites, the exposure is enormous.
• A LiteLLM supply-chain attack: the project's release infrastructure was compromised, also on October 21, and malicious PyPI packages stayed downloadable for under two hours.
• Weak certificate authority keys: a researcher reported that the private keys behind eight eMudhra intermediate CA certificates were so feeble — one reportedly amounted to little more than the number 4 — that fraudulent certificates could be forged.
• Password interception over Tor: from October 2, attackers used 333 compromised Tor exit relays to divert SSH connections to interception servers and harvest passwords.

Passkeys help, but only after patching

The author is blunt that passkeys solve none of the incidents above. They will not fix a vulnerable PHP runtime or neutralise a tainted dependency, and anyone whose conclusion is "passkeys make me safe" should go patch first.

What passkeys remove, the post argues, is a whole category of attacks that keeps feeding incidents like these: stolen, phished and replayed passwords. A passkey is a key pair scoped to one site, with the private half kept on your device and the server holding only the public half. A database breach therefore leaks nothing an attacker can log in with, a phishing page cannot capture a credential bound to the real domain, and there is no code to hand over to an interception server.

Adoption figures quoted from the FIDO Alliance's 2026 index point the same way: 36% of successful sign-ins now happen with a passkey, succeeding 93% of the time versus 78% for passwords and conventional multi-factor authentication.

Why SMS codes fall short

The post saves its sharpest criticism for text-message 2FA, listing five failure modes: SIM swaps that reroute codes to an attacker's phone, interception through telecom weaknesses such as SS7 abuse, real-time phishing that relays a fresh code to the genuine site (which the author calls the most common case), malware that reads messages or notifications, and push fatigue, where repeated approval prompts wear someone down.

The root issue is that a six-digit code is simply text, and text can be typed anywhere, including into the wrong site. Passkeys close that hole through origin binding: the browser or operating system signs only for the real domain, so a lookalike page gets nothing at all. The author connects this to August 2026 campaigns such as Mirage2FA, which operated 4,532 phishing domains, and the Kali365 device-code attacks, both of which defeated factors that passkeys would have blocked.

The limits

The argument comes with caveats. Account recovery that falls back to SMS or email can sidestep a passkey entirely. Synced passkeys raise the stakes on your Apple or Google account. And local compromise remains a separate problem: SpecterOps' "Pass-the-Passkey" research, presented at Black Hat in August, catalogued more than 20 techniques across Windows 11, Entra ID, browsers and password managers, including CVE-2026-34348, which Microsoft patched in July. The author's summary is that the cryptography itself was never broken — attackers were simply pushed toward costlier, on-device operations.

On tooling, the post recommends Apple's iCloud Keychain for Apple-centric users, and points to Google Password Manager, cross-platform managers such as 1Password, Bitwarden, Dashlane and Proton Pass, hardware keys like YubiKey, and Windows Hello as alternatives. Its bottom line: any second factor beats none, and SMS still beats a bare password.

A short checklist

The post's closing advice is concrete: patch PHP, Node.js and GitLab where you run them; rotate any secrets that touched LiteLLM; enable passkeys first on email, your Apple or Google account, GitHub and your password manager; keep a backup recovery path such as a second device or hardware key; and add WebAuthn support if you build authentication.

It also notes that most of the affected software is open source with stretched maintainers, and that this year's Hacktoberfest — now run by Major League Hacking and DEV with DigitalOcean — no longer rewards pull-request volume. OpenSSF's newcomer guide, cited there, cautions that leaning on AI coding tools for a first contribution does more harm than good.

Why it matters

Black October exposed two layers of risk at once: infrastructure flaws that only patching fixes, and credential theft that no patch schedule fully covers. Passkeys shrink the second layer and are now mainstream enough — over a third of successful sign-ins — to be a default recommendation rather than an early-adopter option. But the caveats matter as much as the promise: recovery paths, cloud account security and endpoint malware are where passkey deployments actually succeed or fail.