On September 8, cPanel disclosed a vulnerability in one of its email-reporting components, tracked as CVE-2026-67401. The short version is uncomfortable: an ordinary, authenticated cPanel account could use it to write files and end up running commands as root. On a shared server, every customer is an authenticated account, so this is the kind of bug that turns one tenant’s login into control of the whole machine.

cPanel shipped a fix quickly. For the large majority of our servers, that was the end of it: the update landed on the normal schedule and the problem was gone before most customers had heard of it. This post is about the part that wasn’t that simple, because it is going to keep happening, and not just to us.

The fix existed. It would not install.

A small number of our older servers run an operating system that reached end of life some time ago. That is a normal part of a hosting fleet’s life: servers get built, they run well for years, and eventually the operating system underneath them stops receiving vendor builds while the server itself is still doing its job.

Here is what that means on the day a serious vulnerability drops. The vendor publishes a patched release. Your update tool reaches for it. And there is nothing to reach for, because the patched build was never produced for that operating system. It is not that the update fails. It is that the update does not exist for the platform you are on. No amount of re-running it changes that.

So you are holding a known, actively exploitable hole, a fix you can see but cannot install, and a clock.

What we did about it

We were not going to leave customers exposed, and we were not going to take servers offline over a platform decision they never made. So our engineers went to work.

The vulnerable code turned out to be the kind we could work with directly. We took cPanel’s own fix, the exact change the vendor had published, and applied that fix to the servers that could not receive it as a normal update. We did not write our own patch. We did not guess at what the fix should be. We used the vendor’s change and confirmed it matched, byte for byte, what a properly updated server was running. Then we made sure it actually worked.

That last step is the one worth stealing, and it is the part most people get wrong.

The version number will lie to you

On a server that can no longer receive updates, the version number never changes. It cannot. So if you check “is this server patched?” by reading the version, you get the same answer whether the hole is open or closed. Checking the version tells you nothing about this vulnerability at all.

We verified every affected server by attempting the exploit against it and confirming it was refused, while confirming that normal, legitimate use still worked. Not by reading a version string. Test the code that actually runs.

This matters beyond one incident. In any environment with end-of-life systems, “the version says it’s patched” and “the version says it’s vulnerable” are both unreliable, and a team that trusts the number can be wrong in either direction. We built a small, read-only check that anyone on our team can run against a server and get a plain answer: patched, or not. It became the thing we trusted.

Start to finish, the affected servers were closed in an afternoon. Quietly, with no customer downtime, and before we saw any sign of exploitation.

Let’s be honest about what that was

It was a good afternoon’s work, and it was a stopgap. Applying a vendor’s fix by hand is something a capable operations team can do once, carefully, under pressure, for a fix that happens to live in code you can reach. It is not a strategy.

Every future vulnerability on an end-of-life platform demands the same manual effort, carries the same risk, and arrives on the same unforgiving timeline. Sooner or later a fix will land somewhere that cannot be applied by hand at all, and then the only options left are the two bad ones: stay exposed, or go dark.

So our recommendation, to our own customers and to anyone running older infrastructure, is direct: move off end-of-life operating systems onto a currently supported platform. A supported server receives the vendor’s fix automatically, the moment it ships, with no heroics required. That is the whole value of being current. During the next emergency you are boring, and boring is exactly what you want to be.

Migration is planned work. A zero-day is not. Doing the planned work now is how you avoid being forced into the unplanned work later, at the worst possible moment. If you are on one of our older platforms and want to talk about moving to a current one, that is a conversation our team is glad to have, and it is a lot calmer than the one we had on September 10.

Why this is a trend, not a one-off

Here is the part that should change how everyone reads a security advisory. For years, the gap between a vulnerability being disclosed and being actively exploited was measured in weeks. That was the margin most organisations lived in. Patch this month, and you were fine.

That margin is collapsing, and rising AI capability is a big reason why. The same tools that help defenders read code and patch faster help attackers do the mirror image: take a terse advisory, understand the flaw, and produce a working exploit in a fraction of the time it used to take. Turning a description of a bug into a functioning attack is exactly the kind of task that is getting dramatically cheaper. We already treat it as a working assumption that a proof of concept exists the day the advisory does.

Two things follow from that, and they are not comfortable:

  • Weeks becomes hours. “We’ll patch it in the next maintenance window” was a reasonable sentence in 2020. It is a much riskier one now.
  • The long tail becomes the target. Systems that were “going to be upgraded eventually” are exactly the ones that cannot take a fast fix, which makes them the most attractive place to point a fast exploit.

This incident was not the last of its kind. It was an early example of a pattern that is accelerating, and the teams that come through the next few years well will be the ones who treat two things as non-negotiable: stay on supported platforms, and be able to respond in hours.

What to ask anyone who hosts your business

You do not need to be technical to hold a provider to this. Four questions do it:

Ask What a good answer sounds like
How fast do you patch a critical vulnerability? Hours, with a specific example. Not “our next maintenance window.”
How do you verify a server is actually patched? By testing it. Not by reading a version number.
What happens to systems that cannot take the vendor fix? A plan, and a date to retire them. Not silence.
Am I on a supported platform right now? Yes, or a clear path to yes. Not “let me check.”

We patched fast, we verified by exploit rather than by assumption, and we are moving our remaining legacy systems onto supported platforms so the next one of these is a non-event. That is the standard. The threat curve is bending toward faster, and the right response is to stop being a slow target.

We wrote about the same discipline, applied to WordPress core, a few weeks ago: wp2shell: Update WordPress Core Today, and What We Found Across Our Shared Servers. Different software, same lesson: the update is the easy part, and the verification is the part that keeps you honest.

Drafted with AI assistance from our operations records; reviewed, edited and published by the named author, who is accountable for every claim in it.