A newly disclosed vulnerability in Coolify, the popular open-source self-hosted deployment platform, allows any authenticated user, regardless of privilege level, to execute arbitrary commands as root inside PostgreSQL database containers.
Tracked as CVE-2026-42153 and rated High severity with a CVSS score reflecting network-based, low-complexity exploitation, the flaw stems from a classic but dangerous mistake: unescaped user input flowing directly into a shell command.
The vulnerability was publicly disclosed via GHSA-gvc4-f276-r88p by Coolify maintainer andrasbacsai, based on research credited to security researcher ik0z.
Coolify automatically configures Docker healthchecks for PostgreSQL databases to verify they’re running correctly. The problem lies in how that healthcheck command gets built. In app/Actions/Database/StartPostgresql.php, the platform interpolates the postgres_user and postgres_db fields—both of which users can set when creating a database—directly into a shell string:
psql -U {$this->database->postgres_user} -d {$this->database->postgres_db} -c 'SELECT 1' || exit 1
Because Docker’s CMD-SHELL healthcheck type executes commands through /bin/sh -c any shell metacharacters in these fields are interpreted rather than treated as literal text. Semicolons, pipes, command substitution syntax like $(), and backticks all become live shell instructions instead of harmless database identifiers.
Exploitation requires no special access. A low-privileged “Member” account can trigger it in a handful of steps:
- Log into Coolify with a standard member-level account.
- Create a new PostgreSQL database.
- Set the username field to a payload such as
postgres; id > /tmp/hc_rce.txt; echo. - Save and start the database.
- Wait roughly 30 seconds for Docker’s healthcheck cycle to fire.
Once the healthcheck runs, the injected id command executes with root privileges inside the container. Proof-of-concept testing confirmed output showing uid=0(root) gid=0(root), verifying full root access. A video demonstration accompanying the disclosure shows the entire exploitation chain in under a minute.
Notably, the advisory flags that client-side validation exists but doesn’t reliably block this attack; either it’s bypassable or it fails to cover every injection vector, leaving server-side enforcement as the only real safeguard.
Root access inside a PostgreSQL container isn’t a contained problem. Attackers can harvest database credentials stored in environment variables, read or destroy all hosted data, and pivot using the container’s network access to probe internal services.
Depending on the underlying Docker configuration, this could also open a path toward container escape, extending the blast radius to the host system itself.
Coolify patched the issue in version 4.0.0-beta.474, released shortly after disclosure. Versions 4.0.0-beta.473 and earlier remain vulnerable.
Administrators running self-hosted Coolify instances should upgrade immediately and audit existing PostgreSQL database configurations for suspicious username or database name entries that may indicate prior exploitation attempts.
This case underscores a persistent lesson in secure development: any user-supplied value destined for a shell command needs strict escaping or, better still, should avoid shell interpolation entirely in favor of parameterized execution methods.