If you ship software for a living, October 2026 has probably felt like a string of alarms. It was not one incident. It was several, landing close together, in the layers nearly everything else stands on. This note tells the whole story in one place, and links to a closer look at each part. We are writing it for other developers: to say what happened, what it could mean for your own code, and what to do before it does.
The story so far
1 October. Google paused its open-source vulnerability bounty, saying it was being flooded with low-quality, machine-written reports. The first sign of the month’s theme: finding bugs has become cheap, and everything downstream is straining. More in the last post of this series.
8 October. The Go team shipped fifteen security fixes in one release, from denial of service to a proxy mix-up that can hand one person’s reply to someone else. Fifteen fixes in one release.
17 and 20 October. Mozilla distrusted six certificate-authority intermediates, and on the 20th Go blocked eight CA keys outright in a point release. A website that worked yesterday can stop connecting from a freshly built Go program. When Go stopped trusting eight CA keys.
20 and 21 October. Details of a critical PHP flaw leaked a day early. PHP pre-announced, then shipped patches and full disclosure on the 21st. The same day, Node.js shipped ten security fixes. PHP2Shell, explained and Node.js: ten fixes.
Why PHP2Shell is the headline
About seven in ten websites run PHP. A remote-code-execution bug in PHP is therefore a bug in most of the web, and that is where the “70% of websites” figure comes from. Read it carefully, though: 70% of sites run PHP, not 70% are exploitable the same way. What is true is that nearly every PHP site needs the update, and the work is simple: patch and restart. The full explainer shows how the bug works with an animation.
The common thread
None of these were exotic. A stale pointer, a buffer that accepts one write too many, a connection that is reused when it should not be, a list of trusted keys that had to change. They are the ordinary failure modes of software, found faster than before.
The bugs were always there. What changed is how quickly someone can find them, and how little time that leaves between “disclosed” and “being used”.
Your checklist for today
- Inventory. List every runtime you run (PHP, Node.js, Go, others) and the version of each, including inside containers and CI images.
- Patch the runtimes. Move to the patched release of your line. Restart long-running processes; a patched file on disk does nothing for a process that is still running the old code.
- Rebuild, do not just update. Go and other compiled languages bake the toolchain into the binary. Rebuild and redeploy.
- Test your outbound connections. After rebuilding, make sure your services still connect to the APIs they depend on. Watch for certificate errors.
- Shrink the blast radius. Least-privilege accounts, no secrets in environment files readable by the web user, network rules that stop a compromised host from reaching everything else.
- Make it routine. Automated dependency and base-image updates, a weekly patch window, and a way to roll back.
Where this leaves us
Nothing here is a reason to panic. All of it is fixable with updates you can ship this week. But the pace is the lesson: when bugs are found faster, the only sustainable defence is the ability to patch quickly and often. Build that muscle before the next alarm.