Dora NodaSeven CVEs scored a perfect 10.0 in a single January disclosure, and every one of them turned a low-privileged dashboard user into root on your servers. That was the week the default recommendation for self-hosted PaaS got an itemized security bill — and the bill kept growing through July. If you run production workloads behind Coolify, this is the concrete accounting of what that risk profile costs you: the flaws, the patch treadmill they ride in on, and the audit question nobody can answer for you.
What January's disclosure actually contained
On January 8, 2026, cybersecurity researchers disclosed 11 critical-severity flaws in Coolify, covered by The Hacker News. Read the list slowly, because the pattern matters more than any single entry:
| CVE | CVSS | Flaw | Blast radius |
|---|---|---|---|
| CVE-2025-66209 | 10.0 | Command injection in database backup | Any authenticated user with backup permissions executes arbitrary commands on the host; container escape, full server compromise |
| CVE-2025-66210 | 10.0 | Command injection in database import | Arbitrary commands on managed servers; full infrastructure compromise |
| CVE-2025-66211 | 10.0 | Command injection in PostgreSQL init script management | Authenticated users execute arbitrary commands as root |
| CVE-2025-66212 | 10.0 | Command injection in Dynamic Proxy Configuration | Users with server management permissions execute arbitrary commands as root |
| CVE-2025-66213 | 10.0 | Command injection in File Storage Directory Mount | Users with app/service management permissions execute arbitrary commands as root |
| CVE-2025-64419 | 9.7 | Command injection via docker-compose.yaml | Arbitrary system commands as root on the Coolify instance |
| CVE-2025-64420 | 10.0 | Information disclosure of the root user's private key | Low-privileged users read root's SSH key and authenticate as root over SSH |
| CVE-2025-64424 | 9.4 | Command injection in git source input fields | A low-privileged team member executes system commands as root |
| CVE-2025-59156 | 9.4 | OS command injection via Docker Compose directives | Low-privileged user injects Compose directives; root-level execution on the host |
| CVE-2025-59157 | 10.0 | OS command injection via the Git Repository field | A regular user injects shell commands that execute on the server during deployment |
| CVE-2025-59158 | 9.4 | Stored XSS in project creation | Payload executes in an admin's browser when they delete the project or resource |
Nine of the eleven are some flavor of command injection. Seven score a perfect 10.0. And the blast radius column reads like a copy-paste error: authenticated, often low-privileged, user to root, over and over, through backup forms, import forms, init scripts, proxy config, storage mounts, compose files, and git URL fields.
Credit where it is due: Coolify's team disclosed through GitHub Security Advisories and shipped fixes. Fixes landed in 4.0.0-beta.420.7, beta.445, and beta.451 depending on the flaw. Note the version numbers — every one of them a beta. We will come back to that, because it is the treadmill the whole risk profile runs on.
July proved it was a pattern, not an incident
Six months later, on July 15, 2026, SecurityOnline reported four more critical Coolify vulnerabilities, three of them scoring CVSS 9.9:
| CVE | CVSS | Flaw | Blast radius |
|---|---|---|---|
| CVE-2026-34037 | 9.9 | cloneTo() authorizes the source resource but never scopes the destination to your team | A member clones apps and databases onto another team's server, then deploys attacker-chosen containers on the victim host |
| CVE-2026-34047 / CVE-2026-34048 | 9.9 | Terminal websocket bootstrap routes check only that a user is logged in, not that they are an admin | A low-privileged member opens an admin-only terminal session and runs commands on team servers |
| CVE-2026-57498 | 9.6 | Livewire components accept server and destination IDs straight from the URL with no team validation | Cross-team IDOR: operate on servers your team was never granted |
The flaw class shifted from injection to broken authorization, but the blast radius did not move an inch — and that is the architectural point. Coolify runs privileged operations on your servers over SSH, often as root. It holds the keys to every machine it manages. In that architecture there is no such thing as a low-impact auth bug: a single missing authorization check hands an attacker real infrastructure, not just dashboard data. The July wave is what that property looks like in practice, four times over.
So the honest count for a team doing its 2026 review is not "11 CVEs in January." It is 11 criticals in January plus 4 criticals in July, 15 total, against a control plane that is one broken check away from root on every box it touches. The question was never whether the team would fix them — they did, both times. The question is what it costs you to keep up.
The patch treadmill has no LTS exit
Here is the operational part that stings. The January fixes shipped in beta.420.7, beta.445, and beta.451. The July fixes shipped in beta.464, beta.470, and beta.474. Coolify v4 spent roughly two years in beta — some 474 beta releases — before v4.0.0 finally went stable in April 2026, with v4.1.0 following in May.
There is no LTS branch and no backport stream. To patch a critical CVE you take the newest full release, with all of its unrelated changes, behavior shifts, and fresh bugs. You cannot sit on a vetted build and take security-only fixes, because security-only fixes do not exist as an artifact. Every patch window is therefore also an upgrade window, with upgrade-window risk: the custom networking that needed host-level intervention after proxy restarts, the build args that broke Docker layer caching until beta.450, the API behaviors that drift from the docs. Each of those is a minor annoyance on its own. Chained to a CVSS-10 patch deadline, they become the reason teams postpone the patch — which is exactly how a disclosed, fixed flaw turns into a compromised server.
This is the treadmill in one sentence: your patch cadence is set by the attacker's calendar, but your upgrade risk is set by a rolling release train with no stable branch to stand on. v4 going stable in April 2026 improves the footing going forward, and that progress deserves acknowledgment. It does not retroactively give you the backports you needed in January, and the July fixes still rode the newest-release train.
The audit question: who fixes the next one, and by when
Now the bus factor. Coolify's own team page names the people: Andras Bacsai (founder, lead developer), Peaklabs Dev (core developer), and ShadowArcanist (community lead and docs maintainer). That is the crew behind a project with roughly 54,000 GitHub stars, a 19,000-member Discord, 280-plus one-click services, and thousands of companies running it in production. Meanwhile v5 — a full rewrite announced in April 2025 — sits in early development, splitting whatever attention exists between maintaining v4 and building its replacement.
None of that is an accusation. Small teams ship great software, and Coolify's velocity is real. It is an audit observation: when the next CVSS 10 drops, "who fixes it and by when" is answered by the availability of essentially two developers, one of whom is also the founder doing everything else a founder does. There is no second vendor shipping an independent patch, no distro security team backporting the fix to the version you actually run, no enterprise support contract with an SLA to invoke. Your patch window opens when they ship and not before, and it ships on the release train described above.
Put the three pieces together and the single-maintainer security bill itemizes itself: flaws that are root-by-architecture, patches that arrive only as full rolling releases, and a fix pipeline exactly as wide as one small team's week. Any one of those is manageable. All three at once is the risk profile teams inherited when they picked the popular answer.
The structural alternative — and the honest stay-and-harden guide
The alternative is not "a different dashboard." It is a thinner dashboard: a PaaS layer that is a small surface over CNCF components — Kubernetes for orchestration, Gateway API for ingress, cert-manager for TLS, Cluster API for machine lifecycle — instead of a bespoke control plane that reimplements all of them while holding root SSH.
| Bespoke control plane (Coolify model) | Thin PaaS over CNCF components | |
|---|---|---|
| CVE arrives from | One small team's codebase | Upstream projects with multi-vendor security teams |
| Patch ships as | Newest full release, unrelated changes included | Component upgrade, often backported to supported minors |
| One auth bug buys attacker | Root on managed servers (holds root SSH) | Scoped by RBAC and component boundaries; no single key to every box |
| Fix pipeline width | One team's availability | Multiple vendors plus distro backports |
| Audit answer for "who fixes it" | A name, singular | A project security process with CVE history you can read |
The point is not that Kubernetes never has CVEs — it has plenty. The point is what a CVE costs you when it lands: a scoped component patch with backports, versus a full-release upgrade on someone else's weekend.
If you are staying on Coolify — and for many teams that is the rational call — harden the things this record says actually fail. Keep the dashboard and API off the public internet entirely; a Tailscale-only admin plane while apps stay public removes the internet-scannable session that can reach the Docker socket. Pin to a specific release and subscribe to the security advisories so a beta.474-class fix does not sit unapplied. Treat every team member as root-equivalent when scoping access, because both CVE waves proved that is what the dashboard grants in practice. And rehearse the full-release upgrade path before a CVSS 10 makes it urgent, because the patch will arrive bundled with everything else.
The broader lesson survives whichever choice you make: popularity is not a security control. Eleven criticals in January and four more in July earned Coolify its scrutiny, but the scrutiny belongs on the structure — root-holding bespoke control plane, rolling-release-only patches, one small team — because that structure is what converts the next flaw into your next emergency. Audit the structure before you adopt the tool, and you will never have to read a CVE table like January's about your own fleet.
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.
