Coolify Fixed 11 Critical CVEs in v4.0.0 — How to Audit Any Self-Hosted PaaS Before Trusting It With Secrets

In January 2026, researchers disclosed 11 critical vulnerabilities in Coolify, the popular open-source self-hosting platform — several scoring a perfect CVSS 10.0, all enabling full server takeover. At the time, internet scans found roughly 53,000 Coolify instances exposed online. The fixes rolled up into the v4.0.0 stable release that April.

Here is the uncomfortable part: none of this means Coolify is uniquely reckless. Eleven critical CVEs in an actively developed deployment tool is normal. What matters — and what most teams never do — is auditing a self-hosted PaaS the same way you would audit any dependency you hand production secrets to.

"We host it ourselves" is not a security property. This post breaks down what the flaws actually were, what they shared mechanically, and gives you a six-point checklist for judging any single-box platform before it holds your tenants' keys.

What the 11 flaws actually were​

The January 2026 disclosure bundled three reporter batches into one ugly picture. Every flaw below allows an attacker to go from limited access to full control of the Coolify host:

Fixes shipped fast once reported: the backup-injection batch was patched in v4.0.0-beta.451 (December 2025, via comprehensive input validation and shell-argument escaping across the affected flows), the compose-injection flaw in beta.445, and the deployment-input pair in beta.420.7.

The April 27, 2026 v4.0.0 stable release collected the whole set — which is why this post frames it as "v4.0.0 patched 11 CVEs" even though the patches technically landed across several betas first.

This was also not Coolify's first rodeo. A year earlier, in January 2025, a separate batch (CVE-2025-22609 at CVSS 10.0, CVE-2025-22611 at 9.9, CVE-2025-22605) offered full administrative control over affected instances. Two critical batches in twelve months is the cadence you should assume for any fast-moving deployment tool — and plan around, rather than be surprised by.

The pattern, not the count​

Counts make headlines; mechanisms let you evaluate the next tool. Three patterns run through both Coolify batches, and they are the same three patterns that recur in almost every self-hosted control-plane compromise:

Unsanitized user input reaching a shell. The backup commands, the compose-file handling, the git repository fields — in each case, attacker-influenced strings were interpolated into shell commands without escaping. This is the oldest web vulnerability class there is, and it keeps showing up because deployment tools are, by nature, machines that turn user input into shell commands. Any PaaS you evaluate is a shell-command generator with a web UI. Ask how it escapes.

Authorization checks missing on sensitive reads. CVE-2025-64420 is the scariest of the batch precisely because it is boring: a low-privileged user could view the root user's private SSH key. No exploit chain, no memory corruption — just a read path that never asked "is this user allowed to see this?"

The control plane holds every secret needed to own every server it manages, so a single missing check anywhere in its read surface is total compromise. When you audit a tool, the read paths deserve as much suspicion as the write paths.

The control plane runs as root, so everything is total. Coolify manages Docker, SSH connections, and host services, which means it operates with the highest privileges on the box. There is no meaningful privilege boundary between "the app" and "the machine." That is true of Dokploy, CapRover, and nearly every single-box tool — it is inherent to the architecture, not a Coolify-specific sin. But it means the blast radius of any flaw is the entire server, and your audit should assume breach-of-app equals breach-of-host.

53,000 dashboards on the public internet​

At disclosure time, Censys-tracked scans counted roughly 52,000–53,000 publicly reachable Coolify instances, concentrated in Germany, the United States, France, Brazil, and Finland. Every one of them was a web dashboard with root-equivalent power sitting on the open internet during the window between disclosure and patching.

This is the threat model most self-hosting guides underplay. The pitch — "you control the whole stack, so it's inherently safer" — quietly assumes the control plane itself is unreachable to attackers. In practice, teams expose the dashboard for convenience (managing deploys from anywhere), skip IP allowlists ("I'll lock it down later"), and run versions months behind because upgrades mean downtime on the box that also runs production. A self-hosted control plane with a network-reachable login page and stale code is not safer than a managed service; it is a managed service operated by someone with less time for security than the vendor's team.

None of this is an argument against self-hosting. It is an argument against exempting self-hosted tools from the scrutiny you apply to everything else. The operator owns the hardware, but the attacker only needs the dashboard.

Credit where due: the disclosure and fix cadence​

Here is the half of the story that headline counts miss. It is also the half that actually tells you whether to trust a project. Coolify's security process did most things right:

• Public advisories with CVE IDs. Each flaw got a GitHub Security Advisory (GHSA) record and a CVE number, with affected-version ranges and fixed-in versions spelled out. You could determine your exposure from the advisory alone — the minimum bar, and one plenty of smaller tools fail.
• Fast fixes. The December 2025 batch went from report to patched beta in roughly a month. The stored-XSS and deployment-injection flaws were fixed in a patch-level beta (beta.420.7).
• Communicated rollup. The v4.0.0 stable release notes gathered the fixes into a milestone teams could plan an upgrade around, instead of leaving them scattered across 400+ rolling betas.

Judge the process, not just the count: a project with 11 disclosed-and-fixed CVEs and a working advisory pipeline is, all else equal, safer than a project with zero disclosed CVEs and no security contact — the latter usually means nobody is looking.

And the honest coda: auditing never ends at the upgrade. Post-4.0, researchers kept finding issues — 2026 CVEs scoring up to 9.9 against the control plane's authorization logic, and a community audit of the v4.1.x API surface finding database passwords serialized in plaintext on a resource endpoint (locked down in v4.2). Patching to v4.0.0 was necessary; assuming "we're on v4, we're done" would have been wrong within months. Continuous tracking is the job, not a one-time upgrade.

The 6-point audit checklist​

Before any single-box PaaS holds production secrets, run it through this list. Each item has a concrete "good looks like" so it is checkable, not vibes:

1. A public advisory process. Good looks like: a SECURITY.md with a contact, published GHSA/CVE advisories with affected and fixed versions, and credit to reporters. If you cannot find a single CVE for a tool with a network-reachable dashboard, assume under-reporting, not perfection.
2. Pinned versions and a patch-lag policy. Good looks like: production pinned to an exact version, a rule for maximum lag behind stable (e.g. 30 days for critical fixes), and upgrade notes you have actually read once. "Latest beta, auto-updated" and "whatever we installed in 2024" both fail.
3. The dashboard is not on the public internet. Good looks like: VPN-only or SSO-gated access, IP allowlists, no direct port-443 exposure of the admin UI. If you can reach your PaaS login from a random café network, so can everyone else — fix that before anything on this list.
4. Secrets are encrypted at rest and masked in transit. Good looks like: credential fields encrypted in the database (not just "stored in Postgres"), masked in API responses and logs, with key rotation documented. The plaintext-passwords-on-an-API-endpoint finding above is the exact failure to grep for.
5. Roles are enforced server-side, not just hidden in the UI. Good looks like: a low-privileged test user that provably cannot read other teams' secrets, trigger deploys, or reach admin endpoints when calling the API directly. CVE-2025-64420 is what "the button was hidden but the endpoint was open" costs.
6. An upgrade drill you have rehearsed. Good looks like: tested backups of the control plane's own state, a staging instance (even a cheap VPS) where the new version runs first, and a rollback path. Teams that cannot upgrade safely do not upgrade — and then the CVE count stops mattering because none of the fixes are installed.

Work through all six and you will know more about your platform's real posture than its marketing page ever told you — for Coolify, Dokploy, CapRover, or anything else with a "deploy" button and a database full of keys.

Self-host with your eyes open​

Coolify's 11 CVEs are not a reason to abandon self-hosted platforms. They are a reason to treat the platform itself as the most privileged, most exposed dependency you run — because it is. The teams that came through January 2026 unscathed were not the ones with opinions about which tool is "inherently safer." They were the ones with a pinned version, a dashboard behind a VPN, and an upgrade habit.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources​

• The Hacker News, "Coolify Discloses 11 Critical Flaws Enabling Full Server Compromise on Self-Hosted Instances" (Jan 8, 2026) — thehackernews.com
• SC Media, "Nearly a dozen Coolify flaws put servers at risk" (Jan 2026) — scworld.com
• Censys advisory on CVE-2025-64424, CVE-2025-64420, CVE-2025-64419 (Jan 6, 2026) — censys.com
• CyberPress, "Coolify Self-Hosting Platform Vulnerabilities Allow Attackers to Execute Arbitrary System Commands" (exposure count ~52,650) — cyberpress.org
• 0xrakan public advisory for CVE-2025-66209–66213 (fix PR coollabsio/coolify#7375, beta.451) — github.com
• Coolify releases page (v4.0.0 stable, Apr 27, 2026) — github.com
• Cloudzy Blog, "Coolify vs Dokploy: Self-Hosted PaaS Compared (CVEs, License, Sizing)" — cloudzy.com
• Belgium CCB warning on critical Coolify vulnerabilities — ccb.belgium.be