Is Coolify Safe? What the 2026 CVEs Mean — and How to Lock It Down

On January 8, 2026, Coolify disclosed eleven critical vulnerabilities in a single day. Five of them carry a CVSS score of 10.0 — authenticated command injection that ends with root access on the host. At the time of disclosure, Censys counted 52,890 Coolify dashboards reachable from the public internet. More of them stand in Germany than anywhere else: roughly 15,000.

So, is Coolify safe? The short answer: yes — if you operate it like the piece of critical infrastructure it is. The longer answer is what this article is for.

What actually happened

Coolify is an open-source, self-hosted PaaS — an alternative to Heroku, Vercel or Netlify that deploys applications and orchestrates servers for you. That job description matters for everything that follows: Coolify routinely performs privileged operations on your hosts, usually as root.

The January disclosure covered eleven CVEs. Grouped by class:

No exploitation in the wild was confirmed at disclosure, and none has been reported since (as of July 2026). With ~52,000 exposed instances that is not a reason to relax — it is a head start.

January was not the end of it. Further critical issues were disclosed through spring 2026 — a Sentinel-token injection leading to host RCE (CVE-2026-34034), command injection during deployment (CVE-2026-34038), an authorization bypass that let users reach other teams’ servers (CVE-2026-34592). Coolify has since left beta: after years of 4.0.0-beta.4xx builds, the first stable release, v4.0.0, shipped on April 27, 2026 — and the current v4.1.2 (June 2026) still carries a page-long list of security fixes. Patching Coolify is a treadmill, not a one-off event.

Why this keeps happening — and why it doesn’t mean "Coolify is bad"

Coolify’s entire job is to take user input — a Git URL, a docker-compose file, a database name — and turn it into privileged operations on your servers. That is the largest attack surface a self-hosted tool can have. The recurring pattern across these CVEs is the same: user input reaches a shell without enough sanitization, in many independent code paths.

Add the feature velocity of a young product — every vulnerable version above still reads 4.0.0-beta.4xx, and the first stable release only shipped in April 2026 — and a small core team, and this class of bug will keep appearing. To be fair: the project patches quickly and works with security researchers through responsible disclosure — that part functions well.

The takeaway is not "avoid Coolify". It is: treat it like production infrastructure, not like a weekend tool.

The honest nuance: who is actually at risk

Most of the eleven January CVEs require authentication. If you are the only admin, nobody else has an account, and your dashboard is not reachable from the internet, an attacker needs your credentials before any of the CVSS-10.0 bugs matter. Your real-world risk is far lower than the headlines suggest.

The problem: real installations rarely look like that.

• 52,890 dashboards were publicly reachable — 15,000 of them in Germany.
• Unauthenticated vectors existed too: host-header injection in the password reset flow and a login rate-limit bypass.
• In team setups, any low-privileged member had several paths to root — including simply reading the root user’s SSH private key.
• The stored XSS lets a low-privileged user plant a payload that executes in the admin’s browser.

If any of these describe your setup, "it requires auth" is not a defense.

The lock-down checklist

Do this even if you never talk to us:

1. Update — and keep updating.
4.0.0-beta.451 is the bare minimum; better, run the current stable release — v4.1.2 as of July 2026. Coolify left beta with v4.0.0 on April 27, 2026, and 4.1.2 alone ships another long list of security fixes. Subscribe to the GitHub security advisories for the repository — new critical CVEs have appeared every few months.

2. Take the dashboard off the public internet.
VPN (WireGuard/Tailscale) or a strict IP allowlist. Most of the January risk disappears with this one step.

3. Rotate secrets if you ever ran ≤ beta.434.
Private keys were readable by low-privileged users. Rotate SSH keys, API tokens and database credentials — updating does not un-leak anything.

4. Minimal RBAC.
Every member account was a potential root shell. Grant app/server management rights only to people you would give root anyway.

5. Separate the control plane.
Where possible, run Coolify on its own host, not next to your production workloads. It limits the blast radius when — not if — the next CVE lands.

6. Monitor.
Alert on unusual API calls, new SSH keys and config changes on the Coolify host.

7. Keep backups off the Coolify host.
A root compromise of the control plane must not take your backups with it.

When self-hosted Coolify is a fine choice

We are not here to talk you out of a tool that fits. Keep running Coolify yourself if:

• It hosts side projects, internal tools or staging — nothing a customer or regulator would ask about.
• You are a single admin, the dashboard sits behind a VPN, and updates get applied within days, not months.
• You genuinely enjoy operating it — many people do, it is a good product.

When it stops being fine

The calculation changes when:

• Customer data or production workloads for a company run on it — especially under GDPR, or if you are in scope for NIS2.
• Several people have accounts. Every one of them was one CVE away from root this January.
• The question "who applies a critical patch within 24 hours, including during vacations?" has no answer.

The software is free; the operational duty is not. This is the same argument we make about running alpha-stage storage: someone has to absorb the risk. Either your team does — with update discipline, monitoring and on-call — or you pay someone to do it.

What we do

Hostzero runs open-source infrastructure for EU companies from our Frankfurt data center. For Coolify setups that have outgrown DIY, that means: a security audit of your existing instance (exposure, versions, RBAC, secret rotation), hardened managed operations — VPN-only dashboard, monitoring, patches applied on SLA — or, where it fits better, migration to a platform we already operate at scale.

Talk to an engineer — 30 minutes, no sales pitch. Describe your setup and we will tell you honestly whether the checklist above is all you need.

Frequently Asked Questions

Is Coolify safe to use in 2026?
Yes, with conditions: run the latest version, keep the dashboard off the public internet, rotate secrets if you ran a vulnerable version, and make sure someone owns patching. The project itself is actively maintained and fixes vulnerabilities fast.

Which version fixes the vulnerabilities?
4.0.0-beta.451 closed the January 2026 wave; later issues were fixed in subsequent releases. Coolify has since left beta — as of July 2026 the current release is v4.1.2. Run the latest stable version and check the project’s security advisories.

Have the Coolify vulnerabilities been exploited?
No exploitation in the wild has been confirmed as of July 2026. With ~52,000 publicly reachable instances, assume scanners are looking anyway.

I run Coolify alone, as a single user. Am I affected?
Your risk is much lower — most CVEs need an authenticated user. But the password-reset and rate-limit issues were unauthenticated, so an exposed dashboard is still a risk. Put it behind a VPN.

Should a company use Coolify in production? The category is not the problem; operations are. If you are in GDPR or NIS2 scope, run it with the same rigor as any tool that holds root on your servers — or have it run for you.