Your cloud host is part of your attack surface, breached or not

Who exactly is responsible for the security of the server you rent? Most teams would say "us, mostly," and then quietly assume the company that owns the hardware, the hypervisor and the control panel has its own house in order. That quiet assumption is the real story behind Linode's recent security advisories.

Let's be precise, because the headline-level framing can mislead. The documentation we have does not describe a confirmed breach of Linode, which is part of Akamai. What it shows is a pair of customer security advisories on its status page. One, about PHP remote code execution vulnerabilities, started on October 21, 2026. The next, about critical out-of-band F5/NGINX flaws, followed on October 22. In the latter, Akamai said its teams were "actively investigating" the potential impact of three CVEs across its platform and infrastructure.

Trust by default is the actual vulnerability

That is not a scandal. Publishing advisories is what a provider should do. But note the wording: the company itself was still working out how exposed its own platform was. If the people who run the metal need time to find out, the customer renting a slice of it should be asking questions too.

Most of us evaluate a host once, at signup, on price, region and uptime. After that it becomes furniture. We patch our own application, rotate our own keys, and treat everything beneath as someone else's problem. In our view, that is backwards. Your provider's web servers, management API, support tooling and staff access are all paths into your workloads, and you don't control any of them.

The pattern isn't unique to hosting. Coinbase said customer funds were safe after an incident at an analytics vendor involving contact data, going by the headline of that report. Different layer, same lesson: your exposure includes every supplier you handed data or privileges to, whether or not you remember signing them up.

Transparency is the product you should be shopping for

When an incident happens, the quality of the provider's communication matters almost as much as the fix. Compare two behaviors. The F5/NGINX advisory names the specific CVEs and says what is under investigation. Contrast that with Applebee's, where TechCrunch reported that a researcher couldn't find any way to report a security issue, and the company wouldn't say whether it had logs to check for unauthorized access. Applebee's isn't a hosting vendor, but the contrast is instructive: one organization tells you what it knows, and the other leaves you guessing.

So ask your provider the boring questions before you need the answers:

• Is there a public security contact and a disclosure process?
• How fast do advisories go out, and do they name the specific flaws?
• What can the provider access in your environment, and is that access logged?
• Will you be told if an internal incident touches your data, and by when?

If the answers are vague, that's information. We'd weigh it at least as heavily as the price per month.

Assume the provider can be breached, then design for it

Our recommendation isn't to flee the cloud. Self-hosting has its own failure modes, and most small teams would probably do worse. It's to adopt a posture: assume the layer below you can fail, and limit what that failure costs.

In practice, that means encrypting data with keys the provider never holds, keeping backups somewhere else, and treating API tokens and SSH keys as things you can rotate in an afternoon. It also means watching your provider's status and security feeds the way you watch your own dependencies. An NGINX or PHP flaw isn't only about your instances; it may also be about the infrastructure hosting them. None of this requires paranoia. It requires moving the provider from "trusted" to "trusted, verified and replaceable."

Our verdict: don't read Linode's advisories as a reason to panic or to switch vendors. Read them as a free fire drill. If a notice like this made you realize you don't know what your host can see, who you'd contact, or how you'd rebuild elsewhere, that gap is the finding. Close it this quarter, while it's a to-do item and not an incident report.