Coolify's 11 Critical CVEs and 52,890 Exposed Dashboards: What a Single Root Daemon's Blast Radius Actually Looks Like

On January 8, 2026, Coolify disclosed eleven critical vulnerabilities in a single day. Five of them carried a CVSS score of 10.0 — authenticated command injection that ends with root access on the host. On the same day, Censys counted 52,890 Coolify dashboards reachable from the public internet.

Eight months on, the short version reads like this. Coolify's maintainers responded well: the January wave was patched in 4.0.0-beta.451, the long-awaited v4.0.0 stable shipped on April 27, 2026, and v4.1.0 added audit logging in May. No exploitation in the wild had been confirmed as of July 2026. But the two things that made the disclosure alarming are still true. The architecture — one Laravel control panel that holds root SSH keys for every server it manages — is unchanged, so the next critical CVE still converts into fleet-wide root. And nobody has published a follow-up census showing that the 52,890 exposed dashboards ever got locked down.

This post walks through the numbers, the twelve-month CVE record behind them, and the ledger that actually matters when you choose a self-hosted PaaS: what a single root-privileged daemon costs you in blast radius, versus what a multi-component, RBAC-scoped control plane costs you in operational complexity.

The January disclosure, in numbers​

The eleven CVEs disclosed on January 8, 2026 span command injection, privilege escalation, credential exposure, and stored XSS. Here is the full list, per The Hacker News' summary of the advisories:

Two details deserve more attention than they got.

First, the discovery method. Seven of these CVEs came out of a single AI-driven penetration test. Aikido ran its autonomous pentesting system against Coolify 4.0.0-beta.434 without seeding it with prior reports, and it independently found the rate-limit bypass, the self-invitation privilege escalation, two of the root-level command injections, and the root SSH key exposure. If an off-the-shelf AI pentest finds perfect-score CVSS bugs in a mature, widely deployed codebase, assume motivated attackers running similar tooling will too. The cost of finding this bug class just collapsed.

Second, the exposure. Censys' January 8 count of 52,890 publicly reachable instances broke down to roughly 15,000 in Germany, 9,800 in the United States, 8,000 in France, 4,200 in Brazil, and 3,400 in Finland — the classic Hetzner/OVH self-hoster geography. Every one of those dashboards is a login page in front of a daemon holding root credentials for every server it manages. The CVEs were authenticated, which softens the immediate risk — but the same wave included a rate-limit bypass (CVE-2025-64422, via header manipulation) and invitation-link flaws that exist precisely to turn "authenticated" into a speed bump.

Twelve months, four waves, one bug class​

The January disclosure was not a lightning strike. It was the fourth wave in a twelve-month pattern, documented across the advisories and WZ-IT's consolidated timeline:

• Early 2025: unauthorized private-key attachment, role escalation to Owner, and plaintext private-key leakage (CVE-2025-22609 through 22612), patched in beta.361 and beta.374.
• Mid-2025: command injection via the Git repository field and Docker Compose directives, plus stored XSS (CVE-2025-59156 through 59158), patched in beta.420.7.
• Late 2025: the Aikido wave — compose parameter injection, Git source injection, root SSH key exposure, privilege escalation via invitations (CVE-2025-64419 through 64425), patched through beta.445.
• January 2026: five more CVSS-10.0 command injections in database backup, import, PostgreSQL init, proxy config, and file storage (CVE-2025-66209 through 66213), patched in beta.451.

Look at the shape, not the individual bugs. Backup names, import paths, proxy config, mount paths, Git fields, compose directives — six unrelated features, one identical flaw: user input flows into a shell command string that Coolify executes as root. When the same bug class recurs across four waves and a dozen independent code paths, it stops being a bug and starts being a property of the codebase.

And the architecture is what turns that property into a fleet-wide event. Coolify is a single Laravel application that manages every connected server over SSH, as root by default — your public key goes into root's authorized_keys, and the control panel stores the corresponding private keys. There is no privilege boundary between "the component that renders the dashboard," "the component that runs database backups," and "the credential that is root on every box you own." They are the same process. That is why a backup-name injection is CVSS 10.0 and not 6.5: the input lands in a shell that is already root, on a daemon that already holds root everywhere else.

What changed in the eight months since — and what didn't​

Credit where due: Coolify's response trajectory is genuinely good.

• beta.451 (January 2026) closed the entire fourth wave promptly after disclosure.
• v4.0.0 stable (April 27, 2026) ended nearly two years of beta and shipped hardening: HMAC webhook signature verification and upgraded email-verification hashing.
• v4.1.0 (May 2026) added audit logging — table stakes for forensics that the platform previously lacked — along with an MCP server, which is a genuinely useful agent interface and also, worth saying plainly, new attack surface on the same daemon.
• v4.1.1 and v4.1.2 (through July 2026) restricted private-key and source selection to the current team and fixed deploy keys overwriting server root SSH keys.

No exploitation in the wild has been confirmed as of July 2026, per Hostzero's follow-up analysis. That is the good column.

Now the honest column. The question the disclosure begged — did those 52,890 exposed dashboards actually get patched or pulled off the public internet? — has no public answer. Censys published the January count; nobody has published a follow-up census. What we can observe is that the structural default that produced the number hasn't changed: a standard Coolify install puts the dashboard on a routable port, and locking it behind a VPN or allowlist remains a user exercise. Absent evidence, the safe assumption about tens of thousands of hobbyist-run instances is that a large fraction are still exposed and some meaningful fraction are still running pre-451 builds.

And look closely at what the v4.1.x fixes are fixing: deploy keys overwriting server root SSH keys, key selection scoped to the current team. These are good patches that also confirm the trust model underneath — one daemon, holding root keys, mediating every team's access to every server — is the same one the January CVEs detonated inside. The bug class got harder to hit. The blast radius, when the next one lands, is identical.

The blast-radius ledger​

This is the comparison that actually matters when you pick a self-hosted platform, and it's a trade, not a free lunch.

Compromise one thing in a single-daemon PaaS — Coolify, or any of its architectural siblings — and the attacker holds:

• Root SSH to every connected server, because the daemon stores those keys (and CVE-2025-64420 showed even a low-privileged user could read them).
• Every tenant's containers, databases, and environment secrets on those servers.
• The backup pipeline (and with it, exfiltration of everything at rest).
• The deploy pipeline — persistent, legitimate-looking code execution on every future deploy.

One CVE, total compromise. That is not an indictment of Coolify's team; it is arithmetic about where the credentials live.

Compromise one component in a Kubernetes / Cluster API control plane, and what you hold is that component's ServiceAccount, scoped by RBAC to the verbs and resources it needs. A compromised build controller can touch builds. It cannot read the cloud credentials held by the infrastructure provider, which lives in a different pod, under a different ServiceAccount, in a namespace a NetworkPolicy walls off. There are no stored root SSH keys to fan out through, because nodes are managed declaratively through machine templates rather than imperatively through a shared root shell. Privilege escalation means chaining additional vulnerabilities, not reading a table in the daemon's database.

Honesty requires the other column too. Kubernetes is not invulnerable — IngressNightmare (CVE-2025-1974) put a 9.8 on ingress-nginx in March 2025 and was exactly the "one component holds too much" failure this ledger warns about. The difference is not that multi-component platforms don't have CVEs. It's that the unit of compromise is a component, not the platform: the response to IngressNightmare was "patch or disable one controller," not "assume root on every node you own and rotate everything."

And the complexity cost is real. A Cluster API control plane means etcd, an API server, controller managers, and provider controllers — more processes to run, more versions to upgrade, more YAML, a steeper learning curve, and a control plane that wants dedicated resources rather than a corner of a €4 VPS. Coolify's single daemon is simpler to operate, and for a solo hobbyist with one box and nothing sensitive on it, that simplicity may honestly win. The ledger doesn't say single-daemon platforms are wrong. It says the price of that simplicity is denominated in blast radius, and the twelve-month CVE record above is what the invoice looks like when it arrives.

If you run Coolify today​

None of this argues for panic-migrating. It argues for treating a PaaS daemon like the root-equivalent infrastructure it is:

1. Upgrade to v4.1.2 or later. Every wave above is patched; running pre-451 in September 2026 is running known CVSS-10.0 bugs.
2. Get the dashboard off the public internet. VPN, WireGuard, Tailscale, or at minimum an IP allowlist. This single change removes you from the next Censys number.
3. Rotate credentials if you ever ran beta.434 or earlier — CVE-2025-64420 means low-privileged users could have read your root private key. Rotate the SSH keys, not just passwords.
4. Treat team membership as root. The escalation CVEs turned "member" into "admin" into "root on every server." Invite accordingly.
5. Isolate the control plane host from the workloads it manages, and keep backups somewhere the daemon can't delete them.

The axis nobody puts on the pricing page​

Self-hosted PaaS comparisons obsess over memory footprint and feature checklists. The 2025–2026 Coolify record argues for a different first question: when a critical CVE lands in the platform itself, what does the attacker get? For a single root daemon, the answer is everything, everywhere, at once — and 52,890 internet-facing dashboards' worth of people had that answer demonstrated to them in January.

The trend line points one direction: AI-driven pentesting just made this bug class cheap to find, agent interfaces like MCP are adding surface to exactly these daemons, and self-hosting keeps growing on exactly the cheap-hardware geography the Censys map shows. Blast radius per CVE is becoming the most important number in self-hosted platform design — and it's set at architecture time, not patch time.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. It's built on Cluster API precisely because of this ledger: an RBAC-scoped, multi-component control plane instead of one root daemon holding keys to your fleet. Star the repo on GitHub or deploy your first app today.