Patching is essential. It's just not enough.

If you work in security, October 2026 has probably felt like a month without a weekend.

Microsoft's Patch Tuesday alone addressed more than 1,400 vulnerabilities, the largest release we have seen, and the security community couldn't even agree on the exact count. Attackers began exploiting a SonicWall flaw rated 10.0 just days after it was disclosed, GitLab patched a maximum-severity bug, and a cyberattack on refrigeration systems spoiled millions in stock at French supermarkets overnight.

Then came the week everyone is still talking about. On 20 October, PHP warned of two critical flaws, now known as PHP2Shell, that let an attacker run their own code on a web server without logging in at all. The details leaked before the fix was ready, Cloudflare saw early attacks on the very day the patches landed, and two days later a third flaw appeared that those patches didn't cover. And PHP wasn't alone. Node.js fixed ten flaws on the same day, NGINX had shipped five fixes the week before, GitLab fixed 24 vulnerabilities in a single release on 13 October, and Go released a patch of its own. In about two weeks, nearly every layer of a typical web stack needed urgent attention.

Headlines like these push every team toward the same reflex: patch faster, patch everything, patch now. Patching is essential, and nothing in this article says otherwise. But after two decades in this field, I've learned that patching alone isn't enough. If it's the only thing standing between you and an attacker, you will always be one step behind. The real question isn't how fast we can react. It's how we build systems that stay standing while we react.

Here are four lessons I keep coming back to.

1. Prioritise by what attackers are actually doing

When 1,400 fixes land on your desk in a single day, you can't treat them as 1,400 equal tasks. A high CVSS score tells you how bad a flaw could be, but it doesn't tell you whether anyone is using it right now. A publicly disclosed bug isn't necessarily under attack, and a medium-rated one that is being exploited may deserve your attention before a critical one that isn't.

So start with three questions. Is it being exploited in the wild? Does it sit on something exposed to the internet? And what would it reach if it succeeded? The flaw that answers yes to all three goes first, even if it isn't the one making the most noise.

PHP2Shell shows why this matters. It needed no login, it reached servers straight from the internet, and attacks started within a day. That combination sends it straight to the top of the list, even in a week when hundreds of other fixes are waiting their turn.

2. Assume something will get through, and limit how far it can travel

No team patches everything before attackers move. The SonicWall case showed us how short that window has become: days, sometimes hours. So the more useful question is what happens after a flaw slips past us.

This is where isolation earns its keep. When you separate your components, segment your networks and give every service only the access it truly needs, a breach in one corner stays in that corner. A vulnerability in a web front end shouldn't hand an attacker the database behind it, and a compromised building system shouldn't open a path to the systems that run the business. We can't control when the next zero-day arrives, but we can control how much it's able to touch.

We saw this logic in the official advice on PHP2Shell. Canada's Cyber Centre told teams that couldn't patch right away to take their internet-facing PHP applications off the public network until they could. A flaw you can't fix yet becomes far less dangerous when attackers simply can't reach it.

3. Treat the edge as the front line

Look at this month's list again and you'll notice a pattern. VPNs, remote-access gateways, email gateways, code platforms: the systems that face the internet are the ones attackers hit first, because they're the doors into everything else.

That's why I believe the edge deserves its own layers of defence rather than being trusted to hold on its own. Put protection in front of your exposed services, filter traffic before it ever reaches them, hide what doesn't need to be public, and watch those doors more closely than anything else. When a new exploit appears, a strong edge often lets you block the attack pattern within minutes, long before the vendor's patch is tested and deployed.

PHP2Shell proved the point. For about a day there was simply nothing to install, and the PHP team said plainly that the patch was the only real fix. Yet Cloudflare pushed emergency firewall rules and blocked the attack pattern at the edge for its customers. Those rules were temporary and never meant to replace the patch, but they turned a frightening gap into a manageable one.

4. Governance is what makes speed possible

People often think of governance as the slow part of security, the paperwork that gets in the way. In my experience it's the opposite. The teams that respond fastest are the ones that already know who decides, who acts and who communicates before anything goes wrong.

When a critical flaw drops on a Tuesday evening, you don't want to be discovering which systems you own, who can approve an emergency change, or how to tell your clients what's happening. Keep an accurate inventory, agree your response playbooks in advance, and rehearse them. Then speed stops being heroics and becomes routine.

PHP2Shell tested exactly this. The first question wasn't how to install the update, but where PHP actually lives: on the web servers you remember, and also inside appliances, vendor products and container images. Systems on PHP 8.1 or older get no official fix at all. And the work didn't end with the patch. A third flaw surfaced two days later, and because the details leaked early, a server patched on Thursday may have been touched on Tuesday night. That's why the guidance also asked teams to review their logs for signs of compromise. Good governance means someone owns that follow-up, so it doesn't quietly fall off the list.

From reaction to resilience

None of these lessons will stop the next record Patch Tuesday, and none of them makes any system untouchable. What they do is change the question we ask ourselves. Instead of "how fast can we patch?", we start asking "how well do we hold up while we patch?"

That shift is what I call Resilience Engineering: designing systems so that when the world around them is shaken, they stay steady, and the people who depend on them can keep making decisions with confidence. For anyone running critical operations, that steadiness is the real measure of security.

I'd love to hear how your teams handled this month. What helped you most, and what would you do differently next time?

Sources

• [Microsoft Patch Tuesday October 2026: Zero-Days, Critical CVEs, and What to Patch First](https://www.splashtop.com/blog/patch-tuesday-october-2026)
• Security Affairs: [October 2026 Patch Tuesday](https://securityaffairs.com/200953/security/microsoft-patch-tuesday-sets-new-record-with-1415-cves-in-october-2026-updates.html), [Cisco email gateway flaw](https://securityaffairs.com/?p=200985)
• Security Affairs: [SonicWall SMA 1000](https://securityaffairs.com/?p=198303), [Ivanti VPN zero-days](https://securityaffairs.com/200895/hacking/volexity-uncovers-stealthy-ivanti-vpn-attack-using-three-zero-day-vulnerabilities.html), [French supermarket attack](https://securityaffairs.com/200863/hacking/hackers-cranked-french-supermarkets-freezers-up-to-50-degrees-causing-hundreds-of-stores-to-lose-their-stock.html)
• Security Affairs: [GitLab maximum-severity fix](https://securityaffairs.com/200868/security/gitlab-patches-max-severity-vulnerability-cve-2026-97229.html)
• [PHP warns admins of two critical flaws, emergency patches coming tomorrow](https://www.bleepingcomputer.com/news/security/php-warns-admins-of-two-critical-flaws-emergency-patches-coming-tomorrow/)
• [AL26-026: Critical vulnerabilities impacting PHP](https://cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619)
• [nginx's latest five vulnerabilities fixed in 1.30.6 and 1.31.7](https://webhosting.today/2026/10/16/nginx-has-disclosed-26-vulnerabilities-in-2026-the-latest-five-are-fixed-in-1-30-6-and-1-31-7/)
• [Node.js fixes 10 flaws on the same day as PHP](https://fourweekmba.com/ai-node-js-fixes-10-flaws-4-high-on-the-same-day-as-php/)
• [GitLab Multiple Vulnerabilities, 13 October 2026](https://www.hkcert.org/security-bulletin/gitlab-multiple-vulnerabilities_20261013)