The Internet Is on Fire. Here's What to Check Right Now

October 20 and 21 were rough. A critical PHP bug leaked before its patch. A popular AI library shipped malware. A certificate authority lost control of its keys. Node.js and Oracle both dropped big security releases. TechCrunch called it the internet having a very bad cybersecurity day.

These incidents aren’t connected. They just happened to land together, and most teams are affected by at least two of them. I spent the last day working through the mess. This is the guide I wish I’d had when I started.

Things are still changing. Check the linked advisories for the latest versions before you act.

Update, October 22: two more landed overnight. A batch of Linux kernel vulnerability reports went out on a public mailing list before fixes were ready, and ISC disclosed four high-severity bugs in BIND, the DNS server. See #8 and #9.

The Short Version

If you only have ten minutes, use that table. The rest of the post explains what happened and ends with one checklist for the work underneath.

1. PHP2Shell

Two critical bugs in the PHP engine (CVE-2026-109618 and CVE-2026-109619) let anyone run code on your server without logging in. The details leaked before the planned disclosure, so PHP rushed out patches on October 21. Exploit attempts appeared before the patch did. Botnets are now scanning for PHP servers. Some organisations, including government services, took their sites offline rather than keep running unpatched.

Affected: anything running PHP. Only 8.2 and newer get fixes.

What to do:

• Upgrade to 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
• On 8.1 or older there’s no patch. Put the site behind a WAF or take it offline, and plan the upgrade now.
• Find the PHP you forgot about. Check your CMS, admin panels, old marketing sites, WordPress subdomains and base images that ship PHP.
• Turn on your WAF provider’s PHP2Shell rules while you patch.
• Look for web shells, new files in web roots, odd cron jobs and crypto-miner CPU spikes.

Read more: The Hacker News, Tenable’s FAQ

2. Node.js: Brotli RCE and TLS Bypasses

The October 21 release fixes ten CVEs. Four are high severity. The worst is a bug in the Brotli decoder that can let an attacker run code when your app decompresses data they control. Two others let attackers bypass TLS hostname checks. The release also blocks the compromised eMudhra certificates from #4.

Affected: every Node line. Node 20 and older are end-of-life and get no fix.

What to do:

• Upgrade to 22.23.4, 24.22.1 or 26.12.1.
• Still on Node 20? This is the push to move. Every future Node advisory is now unpatched for you.
• Check the Node version that’s actually running, not the one in your package.json. Base images, CI runners, serverless runtimes and build boxes often fall behind.

Read more: Vercel’s advisory

3. LiteLLM 1.107.0: A Poisoned Release

Attackers got into LiteLLM’s release pipeline. They published 1.107.0 with a credential stealer and a remote access trojan. It stayed on PyPI and Docker for a few hours on October 21, including under the latest, main-latest and main-stable tags. The malware targets cloud, browser and AI provider credentials. Stolen credentials were reportedly used within hours.

Affected: anyone who installed 1.107.0 or pulled those Docker tags during the window. That includes AI gateways and internal tools built on LiteLLM.

What to do:

• Search lockfiles, images and running containers for litellm==1.107.0. Check when your images were last pulled.
• Don’t just uninstall. The malware hides in .pth and sitecustomize.py files, then runs every time Python starts. Rebuild from a clean image.
• Pin to 1.106.2, and pin containers by digest instead of tag.
• Treat every secret on an affected machine as stolen. From a clean machine, rotate cloud, AI provider and source control keys. Then check their logs.

Read more: LiteLLM’s incident report, Wiz’s analysis

4. eMudhra: Eight Compromised CA Keys

The private keys for eight eMudhra intermediate certificates were generated with weak randomness. Anyone holding the keys could issue a valid HTTPS certificate for a site they don’t own. Chrome, Firefox, Apple and Microsoft have already blocked them. There’s no public evidence that anyone abused them.

Affected: browsers are fine. The risk is everything else that makes TLS calls, including language runtimes, HTTP clients, appliances, IoT and old CA bundles.

What to do:

• Update runtimes that carry their own trust list. Node, Go and the JDK have added blocks.
• Update OS CA bundles on servers and in container base images.
• If you use eMudhra certificates yourself, check whether they chain to an affected intermediate. Replace them if they do.

Read more: The Hacker News, Mozilla’s bug report

5. Oracle’s October Patch Update

Oracle’s quarterly update landed on October 20 with over a thousand fixes. Java SE alone gets 55 security patches. Most can be exploited remotely without logging in. The JDK also blocks the eMudhra certificates.

Affected: anyone running Java, including the Java bundled inside build tools, CI servers and vendor appliances.

What to do:

• Move to the October release of your Java line: 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33 or 8u511.
• Start with your CI server. It’s probably the most exposed Java process you own, and it holds every deploy credential.
• Check for bundled JREs. Plenty of tools ship their own.

Read more: Oracle’s advisory, Java SE release notes

6. Exploited Zero-Days: BeyondTrust and Plex

BeyondTrust patched a critical zero-day in its Remote Support product. Attackers have been exploiting it since August. Separately, four Plex Media Server bugs known as Plex2Shell are being actively exploited.

What to do:

• Running BeyondTrust Remote Support? Patch it, then look for signs of compromise back to August. Remote support tools can reach every machine they manage.
• If anyone on your team runs Plex on a machine that also has work access, get it patched.

Read more: TechCrunch’s roundup

7. Keep an Eye on Your Vendors

TechCrunch also reported a breach at TiDB Cloud on October 19. Few details are public so far. For every cloud service you use, know which credentials the vendor holds and how quickly you could rotate them.

Update, October 22

8. Linux Kernel: Vulnerabilities Posted in Public

Overnight, Trend Micro’s Zero Day Initiative posted several Linux kernel vulnerability reports to the public kernel mailing list instead of the private security list, apparently by accident. Phoronix has the details. So the bug details are public before most of the fixes are ready.

The two worst are remote code execution bugs in the kernel’s SMB server code, ksmbd and SMB Direct. Both are rated CVSS 9.0. The rest are local privilege escalation bugs in the networking code and the VMware graphics driver, plus an information leak in the NVMe target code. At the time of writing, they weren’t patched in mainline yet. There’s no word on exploitation.

Affected: the remote risk is mostly limited to machines running ksmbd, the in-kernel SMB file server. Most servers don’t. The local bugs matter anywhere untrusted code shares a kernel with something sensitive. Think containers, CI runners and multi-tenant boxes.

What to do:

• Check whether the ksmbd module is loaded. If you don’t need it, unload it and block it from loading.
• SMB should never be open to the internet. Check that port 445 is closed from outside.
• Watch your distro’s security feed for kernel updates over the next few days. Have a reboot plan ready.
• On shared hosts and CI runners, don’t run untrusted jobs on the same kernel as anything sensitive.

9. BIND: Four High-Severity DNS Bugs

ISC disclosed four high-severity bugs in BIND 9 on October 21. The worst is CVE-2026-94300, rated CVSS 8.1. It lets an attacker corrupt memory by replaying GSS-TSIG signed messages, which could lead to remote code execution. The other three let a crafted query crash or exhaust a server. Two only affect resolvers with specific RPZ or redirect zone setups. ISC says it isn’t aware of any active exploits. There are no workarounds.

Affected: anyone running BIND 9 from 9.11 up to 9.18.50, 9.20.29 or 9.21.26. GSS-TSIG is most commonly used for Active Directory style dynamic DNS updates, so start with those setups.

What to do:

• Upgrade to 9.20.30 or 9.21.27.
• On 9.18 or older, no fixed release is listed. Plan the move to 9.20.
• Don’t forget BIND inside appliances, routers and old internal DNS boxes.
• On a managed DNS provider? Check their status page. This one is mostly on them.

Read more: ISC’s advisory, SecurityOnline’s summary of all four

The Checklist

Each event has a different fix, but the work underneath is mostly the same. This is the order I’d use.

Today

• Scan yourself from outside. Use a machine that isn’t on an allowlist. That’s what attackers see.
• Check what’s actually running. Look at live servers, containers, base images and CI runners. Don’t trust the repo.
• Rank by reachability. Does your code call the vulnerable path? Can outside input reach it? If not, it can wait.
• Block at the edge first. Use your proxy, CDN or WAF now. Fix the code after.
• Rotate exposed secrets. Rotate anything from a machine that ran a bad package. Use a clean machine.

This Week

• Look for intruders. Check login history, new accounts, cron jobs, unexpected services and changed binaries.
• Harden forgotten boxes. Check CI servers, jump hosts and the secrets manager. Turn off password SSH and patch OpenSSH.
• Confirm backups exist. Focus on the boxes nobody checks.
• Block the cloud metadata endpoint. Most apps don’t need it. Attackers in a container go there for credentials.
• Delete what nobody uses. Check access logs first. Deleted code has no CVEs.

Make It Stick

• Pin everything. Pin packages by version and images by digest. Moving tags helped LiteLLM’s bad release spread.
• Put dates on end-of-life. Node 20 and PHP 8.1 got nothing this week. Find everything else that’s out of support.
• Staging first, always. Watch it before shipping to prod. Reboot nodes one at a time.
• Get a second reviewer. Rushed fixes break things. Have a person or a different AI model review changes to prod.
• Keep one list. Use one ticket with two sections: done and to do.

A note on failed logins: tens of thousands of failed SSH attempts is normal internet noise. One successful login you can’t explain is not.

This Will Happen Again

The PHP bugs were reportedly found with AI help. Attackers use the same tools. Researchers expected mass exploitation of PHP2Shell within minutes of the patch going public. The time between a patch landing and someone scanning for it keeps getting shorter.

The teams that handled this week calmly already knew what they were running. Their versions were pinned, and they could move a change through staging to prod in a day. That’s the work to do before the next bad week.