Dora NodaAn application platform is supposed to make deployment less scary: connect a repository, press deploy, and get a service. But that convenience has a security corollary that is easy to miss until a critical advisory lands: the platform is now allowed to turn an application-level action into a host-level action.
That is why the recent cluster of critical Coolify reports deserves more than a patch-and-move-on response. The important question is not whether a particular dashboard is “secure enough.” It is: when a low-privilege account, a malformed project field, or an authorization mistake reaches the deployment path, which credentials, machines, tenants, and records are actually in reach?
This is a source-qualified analysis, not an assertion that every claim circulating about Coolify is one demonstrated exploit chain. Public discussion has referred to “11 critical flaws,” CVSS 10.0 findings, container escape, Docker socket exposure, and later MCP features. The verified records below support a narrower—and still serious—lesson: several critical paths connected user-controlled deployment input or authorization decisions to privileged infrastructure. The exact count, a single CVSS 10.0 chain, Docker-socket mechanics, and MCP are not the subject of this article.
The evidence and the blast radius are different things
The following matrix separates what named public advisories say from the operational inference a team should investigate. “Possible blast radius” is not a claim that every deployment, tenant, or server was compromised.
| Record or pathway | Stated precondition | Directly stated impact | Possible blast radius on a single-box setup |
|---|---|---|---|
| CVE-2025-22605 | An authenticated user can reach the affected remote-command path | Arbitrary code on the local Coolify container; access to data, private keys, or tokens of other teams | The management plane and credentials used to operate connected servers; workloads are at risk if those credentials can be used against them |
| CVE-2025-22606 | A user can create or update a project name in an affected version | Shell command execution on the host during deployment | Every workload, secret, volume, and network endpoint reachable from that host is an incident-review target |
| CVE-2025-22612 | An authenticated user hits missing authorization before beta.374 | Retrieval of existing private keys; remote command execution when the victim server configuration matches | Connected servers that trust the exposed key, plus the services and data those servers host |
| CVE-2025-34159 | A low-privilege member can use the described project-creation Compose path | The unreviewed advisory reports a crafted directive mounting the host root filesystem and gaining host-root access | Same-host co-tenants and host resources would require urgent review if the report and environment are applicable |
This is the core deliverable: a platform incident has at least three concentric rings. First comes the vulnerable control-plane action. Second comes the credential or host that action can reach. Third comes the workloads sharing that host or relying on that control plane. A container label or a separate project in a dashboard does not, by itself, stop an incident from moving from ring one to ring three.
The patch boundaries matter. The advisory for CVE-2025-22605 lists version v4.0.0-beta.253 as patched; CVE-2025-22606 lists beta.359; and NVD says beta.374 fixes CVE-2025-22612. The UAE Cyber Security Council’s January 2025 alert assigns CVSS 10.0 to CVE-2025-22612 and describes affected releases before beta.374. The unreviewed CVE-2025-34159 entry reports CVSS 9.4. Those facts justify urgency; they do not prove that every later report is identical or that any specific instance was exploited.
Why deployment control planes deserve production-grade threat modeling
Coolify’s own documentation describes the relevant trust boundary clearly. The control plane stores configuration, connects to selected servers over SSH, and runs Docker operations there. Its security model says it stores SSH private keys and that a sufficiently privileged compromise can use the same paths to reach connected servers. That is normal for a deployment tool: it must possess real authority to deploy.
The advisories show three ways that authority can go wrong.
- CVE-2025-22612 is an authorization-boundary failure. A user who should not retrieve another server’s key can obtain it, and the advisory describes the conditions under which that key enables remote commands.
- CVE-2025-22605 is a command-construction failure in the remote-server execution path. Its advisory says an authenticated user can run code in the Coolify container and reach data or private keys belonging to other teams.
- CVE-2025-22606 is deployment-input command injection. A project name that should remain metadata becomes part of a shell command and executes during deployment.
These are not interchangeable bugs. Yet they converge on a common risk: a deployment control plane sits between a user-controlled input surface and infrastructure credentials. If it is installed beside application workloads on one machine, a host-level command is no longer “just a dashboard bug.” It becomes a reason to examine the host’s containers, volumes, published ports, local credentials, shell history, images, and persistence mechanisms.
That does not make a single-server PaaS irresponsible. It makes its trade-off explicit. A personal project with one trusted administrator can accept a simpler topology and prioritize patch velocity, backups, restricted dashboard access, and key rotation. A platform serving mutually untrusted teams needs to treat “who may cause a deployment action” as a distinct security boundary, not merely a role in a UI.
The architecture change: reduce authority paths, then contain what remains
Moving to Kubernetes or Cluster API is not a security upgrade by declaration. Kubernetes’ own multi-tenancy guidance calls isolation a spectrum: namespaces, RBAC, NetworkPolicy, quotas, virtual control planes, and node isolation solve different problems. In particular, namespaces do not turn shared worker nodes into a hard boundary, and a virtual control plane still needs data-plane isolation.
What changes is the set of controls available to make an exploit path shorter, narrower, and more observable.
| Control | Which pathway it addresses | Role | Residual risk |
|---|---|---|---|
| Separate management-plane nodes and credentials from tenant workload nodes | A control-plane compromise becoming immediate same-host workload access | Containment | A compromised control plane can still request legitimate changes unless its permissions are scoped |
| Namespace-per-tenant, narrowly scoped RBAC, resource quotas, and default-deny NetworkPolicy | Cross-tenant API access, lateral traffic, and noisy-neighbor pressure | Preventive and containment | Misconfigured policies or cluster-scoped privileges can defeat the model |
| Dedicated nodes or node pools where tenant trust boundaries require them | A hostile workload or host compromise affecting unrelated tenants | Containment | The tenant’s own node is still a security domain that needs patching and monitoring |
| Short-lived workload identities and narrowly scoped deploy credentials | Key theft and replay from a long-lived deployment secret | Preventive | Token issuance, audience restrictions, and revocation still need correct implementation |
| Admission policy plus immutable deploy provenance | An unauthorized image, mount, privilege, or deployment mutation | Preventive and detection | Policy is only as complete as its rules and its protected enforcement point |
| Correlated control-plane, Kubernetes, and host audit events | Determining which action reached which server | Detection and recovery | Logs that are incomplete, mutable, or unactionable do not contain an attacker |
The distinction is important. A per-tenant node pool can make an application-host compromise less likely to expose another tenant’s runtime, but it does not make a stolen administrator credential harmless. A NetworkPolicy can restrict pod-to-pod traffic, but it does not repair an authorization bug in the deployment API. The right claim is modest: layered controls can turn a fleet-wide privilege path into a scoped incident with evidence.
For a Cluster-API-managed fleet, this should be visible in the machine lifecycle too. The platform should be able to say which tenant or trust tier a machine serves, who changed that placement, which version of the node image it ran, and which credentials could ask it to do work. “We use Kubernetes” is not evidence; these relationships and events are.
A 48-hour response that produces evidence, not reassurance
When a critical report affects a deployment plane, operators have two jobs: stop the current path and learn whether it was used. This is a practical order of operations.
- Establish the affected version and exposure. Record the exact application image or release, deployment date, dashboard exposure, and enabled integrations. Do not rely on a remembered “we updated recently.”
- Restrict the control-plane entry points. Temporarily limit dashboard, API, webhook, and SSH access to the people and networks needed for response. Preserve access logs before changing retention or proxy configuration.
- Patch from a known release and preserve the before state. Keep the old image digest, configuration, and relevant logs for investigation; verify the running process—not only a configuration file—uses the patched version.
- Rotate the authority, not only the password. Replace potentially exposed SSH keys, API tokens, deployment secrets, webhook secrets, and recovery material. Search deployment configuration and CI for old identifiers.
- Inspect every reachable deployment target. Compare recent containers, images, mounts, scheduled jobs, users, authorized keys, service definitions, and outbound connections to a known-good baseline. Scope the review from the compromised authority path, not from the dashboard’s tenant view.
- Create a containment boundary for the next failure. Split management and tenant workloads where they share a host; add tenant-scoped RBAC and default-deny policies; use dedicated nodes when the trust model needs them. Write down which boundary protects what.
- Make the timeline durable. Correlate actor, source, approval, git revision, image digest, target machine, command or job, and result in an append-only event stream. A useful audit trail answers “who changed this running service?” without reconstructing it from a vendor dashboard and a dozen shell histories.
This checklist is deliberately not Coolify-specific. The same response applies to any self-hosted PaaS, GitOps controller, CI runner, or agent-operated deploy API. The exact exploit may differ; the dangerous combination is reusable: untrusted input, durable infrastructure credentials, and incomplete evidence.
The lesson is not “choose a different logo”
The public Coolify advisories are a reminder that deployment authority is production authority. Patch quickly, but also ask how far each kind of compromise can travel. A platform has earned a stronger security story only when it can point to the privilege it removed or scoped, the containment boundary it configured, and the evidence it retains when something crosses that boundary.
For small, trusted teams, a well-operated single-box setup may be an appropriate trade-off. As soon as the platform becomes a shared service or an agent can request deployments, reducing the trust placed in one control plane and one host becomes an engineering requirement—not an aspirational architecture diagram.
Bex.co is an open-source, AI-native Render alternative for teams that want git-push deployment on machines they own. Its useful security test is the same one above: deploy authority should be scoped, the infrastructure state should be machine-readable, and operations should leave an auditable trail. Explore the project on GitHub.
