Black October: When Every Product You Run Becomes a Security Problem on the Same Day

On October 14, 2026, Next.js published an out-of-band security release. Two critical flaws allowing remote code execution without authentication, both scored 9.5 out of 10, and a denial of service on top. Within days, national cybersecurity agencies were telling organisations to patch immediately.

For a developer with one application, that is a bad afternoon. I run several products, built at different times, on different versions, and that makes it a different kind of problem.

The real question is not how to patch

Applying an update is usually the easy part. The hard part comes before it:

• Which of my products are affected?
• On which version, on which server?
• Does the flaw actually apply to the way this product is configured?
• What else shares a database or a machine with it?

And the most uncomfortable question of all: which one have I forgotten?

Every portfolio has one. An older project still running because nobody turned it off, with dependencies frozen on the day of its last deployment. It receives no attention, and it can be the way in to everything around it.

What retail taught me about this

In retail technology, you learn to think in fleets. A flaw is never about one kiosk. It is about every device in the field, and you need to know exactly what is running where before you can do anything useful.

Most small software operations have no such inventory. The knowledge sits in someone's head, spread across repositories and old deployment notes.

Giving an agent the map

So I put an agent on the job, and the most important thing I gave it was not a model. It was the map: every project, its stack, where it runs and how it is deployed.

With that context, a daily watch becomes useful. The agent reads the new advisories, compares them with what is really running, and separates what concerns us from the noise. When something applies, it prepares the correction rather than just sending an alert that someone has to interpret at midnight.

This is the kind of job agents are genuinely good at. It is repetitive, it needs to happen every single day, and it depends on combining information scattered across many places. A person will skip it the week things get busy. An agent will not.

Where I keep a person

Automation has a limit here, and it is the same limit I apply everywhere else. A security fix changes production, and sometimes the update itself is what breaks things. Watching and preparing can run on their own. The final decision to change something in production stays with a person, with a record of what was done.

Lessons

1. You cannot protect what you have not listed. Write down everything you run before buying a security tool.
2. The forgotten product is the most exposed one. Retire it or keep it updated.
3. Give an agent the map, not just the alerts.
4. Automate the watching. Keep the decision to change production with a person.