is coolify safe to self-host in 2026
Yes — but with two hard conditions: run a patched version (the latest release), and never expose the dashboard to the public internet. In January 2026 Coolify disclosed 11 critical vulnerabilities (CVSS up to 10.0) — authentication bypass, remote code execution as root, and SSH-key theft — across roughly 52,000 exposed instances. They’re all patched now. Update, firewall the dashboard, and it’s safe to run.
what were the 2026 coolify vulnerabilities?
On January 9, 2026, Coolify disclosed 11 critical flaws at once. The severity was the real story: several rated CVSS 10.0, chaining low-privilege access into full root compromise of the host. The two attack vectors that mattered most were unauthenticated command injection through Docker Compose build parameters, and authenticated privilege escalation via unsanitized git and build input fields. And more RCE CVEs have trickled out since, which is the pattern to understand (see the kicker).
| CVE | what it does | fixed in |
|---|---|---|
| CVE-2025-64420 (10.0) | low-priv user reads root’s private SSH key → SSH in as root | Jan 2026 patch (4.0.0-beta.445+) |
| CVE-2026-27957 | authenticated command-injection RCE (CA cert feature) | 4.0.0-beta.464 |
| CVE-2026-34034 | host RCE via Sentinel token injection | 4.0.0-beta.466 |
| CVE-2026-34597 | authenticated host RCE (Nixpacks build params) | 4.0.0-beta.470 |
| CVE-2026-34047 | auth bypass on terminal routes | 4.0.0-beta.471 |
| CVE-2026-12815 | RCE via the Image Name Handler | 4.1.2 |
which coolify version is safe?
The latest stable release. The fixes above rolled out through the 4.0.0-beta.464–471 range, and the most recent RCE (CVE-2026-12815) was closed in 4.1.2 — so anything current is patched against the known set. The one rule with no exceptions: do not run a build from before January 9, 2026 on any machine reachable from the internet. If your instance has been sitting un-updated since last year, treat it as already compromised, not just vulnerable.
was coolify actually exploited in the wild?
No confirmed in-the-wild exploitation as of mid-2026 — but that’s cold comfort with 52,000 instances exposed and working details public. When a CVSS 10.0 SSH-key leak has a known shape and tens of thousands of targets are one Shodan search away, “not yet” is a window, not a guarantee. Patch as if it’s being scanned, because it is.
how do i self-host coolify safely?
The tool’s whole job is to run commands on your server, so a dashboard account is effectively root. Treat it that way:
- Update first, ask questions later. Get to the latest release before anything else. This closes the entire known CVE set in one move.
- Never expose the dashboard to the public internet. This is the single biggest lever. Bind it to localhost and reach it over a VPN or Tailscale, or put it behind a reverse proxy that enforces auth. Most of the 52,000 “exposed” instances died on this exact mistake.
- Firewall the port. Lock the Coolify port (8000) to your IP or your VPN range. If Shodan can’t see it, the mass-scanners can’t hit it.
- Treat every dashboard user as root. Because they are — most 2026 CVEs are “authenticated user → RCE.” Don’t hand out accounts you wouldn’t hand out SSH root to.
- Turn on 2FA and watch the releases. New RCEs keep landing; a build that’s safe today is a patch behind next month. Subscribe to the release feed.
is coolify safe to self-host in 2026 — the honest answer
Safe, yes — but understand what you’re running. Coolify isn’t uniquely insecure; it’s a PaaS that executes arbitrary commands on your host by design, so nearly every bug in it is a root bug, and they’ll keep coming. That’s not a reason to avoid it — it’s a reason to run it like the loaded gun it is: patched, firewalled, and never, ever on the open internet. The teams that got burned in January weren’t running Coolify. They were running an old Coolify with the front door open.