Graphic showing various types of websites offline as the result of critical security patches
Tags: , , , ,

On Wednesday, October 21, a strange thing happened: some of the most visited websites in the world went dark on purpose.

Wikipedia warned of outages and took supporting services offline. The Netherlands pulled its national digital ID service and the website of its House of Representatives. French authorities took local government sites down, including one for the Paris police. Several Pokémon apps went into emergency maintenance.

Nobody had been hacked yet. Everyone was racing to make sure they wouldn’t be.

The cause was a pair of flaws in PHP, the programming language underneath a large share of the web. The details leaked a day before the fix was ready, and the US National Security Agency told organizations to patch immediately or pull vulnerable systems offline.

If you’ve noticed your developer, your host, or your IT team sending more “urgent update” emails than usual, this is why. PHP was the loudest event of the past ten days, but it was far from the only one.

Ten days, six major platforms

Between October 12 and October 21, nearly every layer of the modern web shipped an urgent security release. Some were rated critical. Some were rated “merely” high. All of them meant somebody had to stop what they were doing and update something.

Date Platform What happened
Oct. 21 PHP Two critical flaws let an attacker run code on a server without logging in. They affect PHP versions going back to 2004.
Oct. 21 GitLab A maximum-severity (10.0) flaw affecting every version since 2014. Teams that patched on Oct 12 were exposed again.
Oct. 21 Node.js Ten vulnerabilities fixed across all three supported versions, including one that allows remote code execution.
Oct. 20 Oracle / Java 1,295 security fixes in one quarterly update, followed within hours by an emergency Java point release.
Oct. 14 Drupal A critical core flaw that can let an attacker take over a site, plus two smaller fixes. A week earlier: 26 advisories for add-on modules.
Oct. 13 Microsoft A record 1,413 vulnerabilities fixed in a single monthly update.
Oct. 12 GitLab The first of two critical releases, fixing a 10.0-rated flaw and 21 other issues.

A few of those deserve a second look. Microsoft fixed more vulnerabilities in October than it did in all of 2025. GitLab had to issue a critical fix nine days after its last critical fix, for a similar bug in the same component. And the PHP flaws were sitting in code that has been running much of the web for over 20 years.

That last point matters most. These aren’t new mistakes. They’re old ones that somebody finally found.

The broader numbers say this isn’t a bad week; it’s a new baseline. Security firm ThreatDown counted 998 vulnerabilities fixed around September’s monthly patch cycle, compared with 96 in the same period a year earlier. Patched Linux kernel vulnerabilities tripled year over year. Chrome saw a 36-fold increase.

Graphic showing dramatic increase in security patches year over year

Why this is happening now: AI learned to read code

For most of the internet’s history, finding a serious security flaw was slow, expensive, human work. A skilled researcher might spend weeks reading code, testing hunches, and chasing dead ends to find a single bug. There were never enough of those people, so plenty of flaws simply sat there, undiscovered, for decades.

That constraint is gone. Today’s AI models can read enormous amounts of code, recognize the patterns that tend to produce vulnerabilities, and test their theories quickly and cheaply. They don’t get bored, and they don’t need to sleep.

The PHP flaws are a clean example. A security firm called Calif found them in August using an OpenAI model, as part of an OpenAI-funded audit of PHP’s code. Weeks later, the firm Wiz found the same flaws independently, using AI models from Google and OpenAI. Two teams, working separately with AI, landed on the same 20-year-old bugs. OpenAI described the discovery as a new phase in which AI can find security bugs with internet-scale impact.

It isn’t just one company or one model. Security researchers point to Anthropic’s Claude Mythos Preview, used through an industry initiative called Project Glasswing, as another major driver. Microsoft has said it now uses AI for vulnerability discovery inside its own products. The result is a backlog of decades of hidden problems surfacing all at once.

Graphic showing increase in total security incidents year over year with 2026 projections

Here’s the part that keeps security teams up at night: attackers have the same tools.

In May, Drupal patched a serious flaw in its core software. Researchers then showed they could use an AI model to build a working attack from that public patch in under an hour, for less than $10 in computing costs. Within two days, Drupal’s security team reported attacks in the wild. One security firm later logged more than 15,000 attack attempts against nearly 6,000 sites.

That changes the math. When fixing a flaw publicly takes days and weaponizing it takes an hour, the window between “patch available” and “you’re a target” is shrinking to almost nothing.

Finding the flaw used to take weeks. Weaponizing the fix now takes about an hour and less than ten dollars.

There’s one more wrinkle. The fixes themselves are breaking more often. Terra Security reviewed published advisories and found that, from 2019 through 2025, about 0.2 percent of security fixes on GitHub needed a follow-up because the patch didn’t fully work. In 2026, that figure is 2.3 percent, more than ten times higher. GitLab’s back-to-back critical releases this month are what that looks like in practice.

Why patching is going to take more of your time

The uncomfortable truth is that discovery scales with computing power, and fixing scales with people.

An AI model can surface a thousand flaws in the time it takes a human to read one advisory. But every one of those fixes still has to be written, reviewed, tested against your actual site, scheduled, deployed, and checked afterward. That work hasn’t gotten meaningfully faster. ThreatDown’s own conclusion is that vulnerability discovery is now accelerating faster than organizations can deploy fixes.

The gap was already a problem before this year. Verizon’s 2026 Data Breach Investigations Report found that 35 percent of vulnerabilities known to be actively exploited were still unpatched 28 days later. That was the baseline before the volume went up tenfold.

Here’s what we expect the new normal to look like:

  • More out-of-cycle releases. Quarterly and monthly patch schedules still exist, but emergency releases between them are becoming routine. Oracle’s emergency Java update landed within hours of its scheduled one.
  • Shorter warning windows. Drupal and PHP both gave advance notice this month, which helped. But PHP’s details leaked anyway, and the planned one-day head start disappeared.
  • Inconvenient timing. Releases arrive on the publisher’s schedule, not yours. Drupal’s critical release window this month ran from noon to 5 p.m. Eastern on a Wednesday, and its security team warned that exploits might follow within hours. Whatever was on your calendar that afternoon got moved.
  • Waiting on someone else. Many fixes have to pass through a vendor or host before you can apply them. Laravel Forge, for example, told customers its automatic updates would not patch PHP; each server had to be updated by hand.
  • Old software becomes a liability, not just a chore. PHP 8.1 and earlier, Drupal versions before 10.6, and unsupported versions of Node.js received no fix this week at all.
Graph showign the gap between the velocity of security issues and the ability of humans to patch and deploy them

To be fair to the robots, there’s a hopeful version of this story. Every one of these flaws was already there. Finding them, and finding them first through responsible disclosure, is how software gets safer over time. In a few years, the code underneath the web may be in better shape than it has ever been.

But “in a few years” doesn’t help anyone this quarter. For now, the job is keeping up.

What you can do about it

You don’t need to become a security expert. You do need to make sure someone is clearly responsible, and that they’re set up to move fast. Here’s where we’d start.

  1. Know what you’re running. Make a simple inventory: your CMS and its version, the add-on modules or plugins installed, the PHP or Node.js version underneath, and who hosts it. When an advisory lands, the first question is always “does this affect us?” You can’t answer it without a list.
  2. Get off unsupported versions. This is the single highest-value step. Unsupported versions of PHP, Drupal, and Node.js were all vulnerable this week, and none of them got a fix. If your site runs on something past its end-of-life date, budget the upgrade now, before an emergency forces it.
  3. Make sure someone is watching the announcements. Drupal and PHP both gave advance warning of their critical releases this month. That head start only helps if someone reads it. Subscribe to the security lists for the platforms you use, or confirm that your developer or host does.
  4. Decide who does what before release day. Name who deploys an update, who approves it, and who covers if that person is out. Ten minutes of planning saves hours of scrambling.
  5. Keep a test copy of your site that matches the real one. A staging environment lets you confirm an update won’t break anything before it goes live. Pair it with a clear rollback plan in case it does.
  6. Use a safety net while you patch, not instead of patching. A web application firewall, a managed host’s virtual patching, or a service like Drupal Steward can block known attacks in the hours before you update. Drupal’s own security team notes that this kind of protection doesn’t cover every possible exploit.
  7. Check your work afterward. After a critical update, look at your logs for unusual requests, unfamiliar administrator accounts, or unexpected files. If an attacker got in before you patched, updating alone won’t remove them.
  8. Budget for maintenance as an ongoing cost. For years, many organizations treated site maintenance as an occasional expense. The pace of 2026 makes it a standing line item, like hosting or insurance.
Checklist of maintenance for websites in 2026

The bottom line

So, what’s going on with the internet right now? AI got very good at finding problems that have been hiding in plain sight for decades, and the whole web is catching up at once.

That’s probably good news in the long run. In the short run, it means your website is less like a brochure you print once and more like a car you have to keep servicing. The organizations that come through this period well won’t be the ones with perfect code. They’ll be the ones that know what they’re running, have someone watching, and can move within hours instead of weeks.

Patch week used to come around a few times a year. It’s now every week. Plan accordingly.

If you’re not sure what your site is running, or who’s responsible for updating it, YMC can help. We’ll take a look and tell you plainly what needs attention.

Sources

Tags: , , , ,

Ben Huizinga

With over a decade of agency and in-house experience, Ben Huizinga is a creative and brand strategist focused on building brands that endure—crafting identities that make meaningful connections and stand the test of time. As Director of Brand and Creative at Young Marketing Consulting, Ben blends hands-on execution with high-level strategic thinking, helping organizations align their vision with the right voice, visuals, and experiences. He is also an experienced website architect, specializing in the development of beautiful, easy-to-use WordPress, Drupal, and Webflow sites that bring brands to life online. His work has shaped leading brands across the sustainability, technology, and nonprofit sectors—including Geothermal Rising, Echo Communications, and Bonterra, one of the world’s largest social good technology companies.

You might also be interested in these related articles: