Skip to content

PostgreSQL Healthcheck Command Injection Allows Root Code Execution in Container

High
andrasbacsai published GHSA-gvc4-f276-r88p Jul 2, 2026

Package

composer coollabsio/coolify (Composer)

Affected versions

<= 4.0.0-beta.473

Patched versions

4.0.0-beta.474

Description

Summary

The PostgreSQL database healthcheck command in Coolify uses user-controlled input (postgres_user and postgres_db) without proper shell escaping. Since Docker healthchecks with CMD-SHELL execute via /bin/sh -c, an attacker can inject arbitrary commands that execute as root inside the PostgreSQL container.

Details

Vulnerable Code — app/Actions/Database/StartPostgresql.php:113-117:

'healthcheck' => [
    'test' => [
        'CMD-SHELL',
        "psql -U {$this->database->postgres_user} -d {$this->database->postgres_db} -c 'SELECT 1' || exit 1",
    ],
    'interval' => '5s',
    'timeout' => '5s',
    'retries' => 10,
],

The postgres_user and postgres_db fields are interpolated directly into the shell command without escaping. Docker's CMD-SHELL passes this to /bin/sh -c, which interprets shell metacharacters like ;, |, $(), and backticks.

Note: Client-side validation exists but can be bypassed, or the validation may not cover all injection vectors.

PoC

Environment:

  • Coolify: v4.0.0-beta.470
  • User: Member (low-privileged)

Step 1: Login as Member user

Step 2: Create PostgreSQL database

Step 3: Set Username to:

postgres; id > /tmp/hc_rce.txt; echo

Step 4: Save and Start the database

Step 5: Wait 30 seconds for healthcheck to run

Step 6: Verify command execution inside container:

docker exec  cat /tmp/hc_rce.txt

Result:

uid=0(root) gid=0(root) groups=0(root),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

Root code execution confirmed inside container!

Video PoC

https://youtu.be/e0vzVSlaA58

Impact

An attacker with any authenticated account can:

  • Execute arbitrary commands as root inside PostgreSQL container
  • Access all database credentials (environment variables)
  • Read/modify/delete all database data
  • Use container network access to attack internal services
  • Potential container escape depending on Docker configuration

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE ID

CVE-2026-42153

Weaknesses

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Learn more on MITRE.

Credits