The Day the Internet Broke

On Wednesday, October 21, 2026, governments in at least ten countries, banks, an airline, hospitals, and the Internet Archive took their own websites offline. They were racing to patch two critical flaws in PHP, the language behind a large share of the web, before attackers reached them. The FBI told organizations to patch right away or take systems offline until they could.

The PHP flaws, nicknamed PHP2Shell, got the headlines. The bigger story is the trend behind them. The number of new vulnerabilities is climbing faster than anyone can patch, and the time between a flaw going public and attackers using it has shrunk to days. Some days it is shorter than that. October 21 is what that trend looks like when it lands on a single piece of software everyone uses.

The flood of new vulnerabilities

Every publicly known software flaw gets a CVE number (Common Vulnerabilities and Exposures) so vendors, scanners, and security teams can track it. The count of new CVEs has been rising for years. In 2026 it went vertical.

• All of 2025: about 48,000 new CVEs.
• 2026 through September 30: 72,812 new CVEs, according to security researcher Jerry Gamblin’s monthly tracking. 2026 passed the full 2025 total in August and is on pace for close to 100,000.
• September 2026 alone: 14,943 new CVEs, an average of about 498 a day.
• Microsoft’s October Patch Tuesday (October 13): about 1,416 fixes in a single month, 85 of them critical. PCWorld reported that is more than Microsoft fixed in any previous full year. The previous monthly record, 973, was set one month earlier.
• Oracle’s October Critical Patch Update (October 20): 1,283 new security patches, per Oracle’s pre-release notice.

Our own team sees the same thing in client scans. Hundreds of new CVEs show up every day or two, and each one has to be matched against real devices and software to see if it matters.

The window to patch is closing

A pile of CVEs is manageable if you have weeks to work through it. Attackers are no longer giving anyone weeks.

Rapid7’s Q3 2026 threat report found that attackers began exploiting newly disclosed high and critical vulnerabilities an average of three days after disclosure. 71% of exploitation happened within the first seven days and 90% within 30 days. 79% of those flaws needed no login and no user interaction to exploit.

PHP2Shell went faster than that. Amazon’s threat intelligence team saw exploitation attempts on October 17, four days before the patch existed. Once details leaked on October 20, Cloudflare counted tens of thousands of attack attempts within 45 minutes of the news, hundreds of thousands within two hours, and millions by that evening.

AI is speeding up both sides. The PHP flaws were found by researchers using AI models, and the researchers said AI also helped turn the bugs into working exploits in about a week, work that once took a team months. Attackers have the same tools. A model can read a newly published fix, work out what it closed, and help build an attack against everyone who has not installed it yet.

Why monthly patching no longer works

Most small and mid-sized businesses still patch on a monthly cycle, often tied to Microsoft’s Patch Tuesday. That schedule was built for a world where exploits took months to appear.

Do the math with Rapid7’s numbers. If 90% of exploitation happens within 30 days and you patch once a month, a typical flaw sits open for two weeks or more, well past the three-day average. A flaw that is disclosed the day after your patch window stays open for a month. In practice monthly patching means a business is exposed for most of the period when attacks are most likely.

That is why we are moving client devices to daily patching. Workstations, servers, and the common third-party applications on them check for and install updates every day instead of waiting for a monthly window. Even so, hundreds of new CVEs arrive every day or two. Daily patching shrinks the gap. It does not close it on its own.

What daily patching does not cover

Devices are the part of the problem that automation handles well. Plenty of systems do not fit a daily cycle:

• Firewalls, VPNs, and remote access gateways. These sit on the internet and are favorite targets. Updates often need a reboot and a maintenance window. Ransomware groups are breaking into businesses right now through a Palo Alto GlobalProtect VPN flaw that was patched back in May.
• Websites and web applications. A WordPress site, client portal, or booking page runs on a server that someone has to update, and updating WordPress does not update the PHP underneath it.
• Vendor appliances and line-of-business software. You wait for the vendor to ship a fix, then schedule it.
• Cloud and SaaS platforms. The vendor patches, but you still carry the risk when they are breached. On October 21 the hosting platform Railway told every customer to rotate stored passwords and API keys after an intruder may have read them.
• End-of-life software. Unsupported versions never get a patch. PHP 8.1 and older got no official fix for PHP2Shell.

Vulnerability management when you cannot patch everything

At nearly 500 new CVEs a day, nobody fixes everything first. The goal is to fix the right things first and have a plan for the rest. Most CVEs are never exploited. Rapid7 tracked 43 newly exploited high and critical flaws in all of Q3, out of tens of thousands published. Finding those few quickly is the job.

1. Keep an accurate inventory. You cannot patch software you do not know you run. That includes PHP inside a vendor product, an old test server, and a forgotten VPN appliance.
2. Scan continuously. A quarterly scan is out of date the week it finishes. Scanning needs to run all the time against devices and anything facing the internet.
3. Rank by real-world risk. Put flaws that are being actively exploited (CISA’s Known Exploited Vulnerabilities list is the standard reference) and anything reachable from the internet without a login at the top, ahead of raw severity scores.
4. Patch devices daily and set shorter deadlines for exploited flaws on firewalls, VPNs, and servers: days, not the next maintenance window.
5. Decide in advance who can take a system offline. On October 21 dozens of governments chose a planned outage over the risk of a breach. A business needs someone with the authority to make that call at 9 p.m.
6. Use compensating controls when a patch is not available yet: a web application firewall rule, blocking the system from the internet, or isolating it on the network.
7. Watch for compromise. Attackers sometimes get in before the patch. A security operations team watching around the clock can catch the signs and isolate a device. Patching after the fact does not remove an intruder who is already inside.
8. Retire end-of-life software before the next emergency makes it a crisis.

How we help

Our vulnerability scanning runs continuously across client devices, servers, and internet-facing systems, and findings are ranked by whether a flaw is being exploited in the wild. We are moving client devices to daily patching through remote monitoring, and our team tracks the systems that cannot follow a daily cycle, like firewalls, VPNs, and vendor appliances, so they get patched on a deadline instead of whenever someone gets to them. Our 24x7 security operations team watches for the signs of compromise that a patch alone will not clean up. In a co-managed setup, your IT team keeps control of priorities and change windows while we carry the scanning, tracking, and patching work.

If your business still patches once a month, or you are not sure what is running on your network, we can help you find out where you stand. Read more about our cybersecurity services or managed IT services.

Call us at 405-253-5101 or schedule a discovery call.