CVE-2026-34597: Coolify Authenticated RCE via Nixpacks Build Parameter Injection

Technical summary

The vulnerability exists in Coolify's Nixpacks build pack handler prior to version 4.0.0-beta.470. The root cause is unsafe string concatenation: the install_command parameter supplied by an authenticated user is directly embedded into a shell command without sanitization or proper argument quoting. During the build process, this concatenated string is executed via shell on the deployment host, allowing standard shell metacharacters (pipes, semicolons, command substitution, etc.) to be interpreted as command separators rather than literal arguments. The flaw maps to CWE-78 (Improper Neutralization of Special Elements used in an OS Command, 'OS Command Injection'). The CVSS 3.1 score of 8.8 reflects high confidentiality, integrity, and availability impact with low attack complexity and network-based attack vector, constrained only by the requirement for prior authentication.

Business impact

Exploitation enables lateral movement and data exfiltration within infrastructure managed by Coolify. An attacker with credentials can pivot from the Coolify control plane to underlying hosts, compromise containerized applications, and access connected databases or secrets. For organizations using Coolify in production, this creates supply-chain risk: malicious build commands could be injected during CI/CD pipelines, poisoning container images before deployment. The authentication requirement limits blast radius compared to unauthenticated RCE, but credential compromise—whether through phishing, insider threat, or credential stuffing—significantly lowers the bar to exploitation. Business continuity is at risk if deployments are weaponized to install backdoors or sabotage services.

Affected systems

Coolify versions prior to 4.0.0-beta.470 are vulnerable. The Nixpacks build pack integration is the attack surface. Any authenticated user with permission to define or modify build parameters for Nixpacks-based deployments can trigger the vulnerability. Self-hosted Coolify instances are at direct risk; cloud-managed Coolify offerings depend on their deployment model and version status. Organizations should verify their Coolify version and check access controls around build configuration privileges.

Exploitability

Exploitability is moderate to high within the authentication boundary. The attack requires valid Coolify credentials and access to create or modify a deployment with Nixpacks configuration. No complex gadget chains or race conditions are needed—simple shell injection payloads (e.g., `; malicious_command #`) embedded in the install_command field will execute. Once authenticated, the attack surface is readily accessible via the Coolify UI or API. The vulnerability is not currently listed on CISA's Known Exploited Vulnerabilities (KEV) catalog, suggesting limited public weaponization as of the publication date, though this should not be taken as a guarantee of safety. Proof-of-concept exploits will likely emerge post-disclosure.

Remediation

Immediate action: upgrade Coolify to version 4.0.0-beta.470 or later. This patch introduces proper input validation and shell escaping for the install_command parameter. Interim mitigations for users unable to patch immediately include: (1) restrict Coolify user permissions to the minimum necessary for legitimate deployments; (2) disable or remove Nixpacks build pack integration if not actively used; (3) implement network segmentation so Coolify hosts cannot reach sensitive internal systems or data stores; (4) audit all existing deployments and build configurations for suspicious commands; (5) enforce multi-factor authentication on Coolify accounts to reduce credential compromise risk. These measures reduce but do not eliminate risk.

Patch guidance

Upgrade to Coolify 4.0.0-beta.470 or any subsequent stable release. Review the official Coolify release notes and deployment documentation to ensure compatibility with your environment before upgrading. Test the patch in a non-production environment first, particularly if you have custom build scripts or integrations. After patching, re-validate existing deployments to confirm they still function correctly with the improved input handling. If you are a managed Coolify customer, confirm with your provider that they have applied or plan to apply this patch.

Detection guidance

Monitor Coolify build logs and deployment execution logs for unusual shell commands or special characters in install_command parameters (semicolons, backticks, pipes, $() syntax). Look for failed build executions preceded by commands unrelated to the declared build process. If Coolify logs are forwarded to a SIEM, create rules to flag install_command values containing shell metacharacters. Inspect the Coolify deployment configuration files (if accessible) for anomalous commands. Review authentication logs for unauthorized or suspicious user accounts accessing build configuration APIs. Network-level detection is harder without host-based monitoring, but exfiltration or lateral movement attempts from Coolify hosts to sensitive resources should trigger incident response.

Why prioritize this

This is a high-priority patch despite requiring authentication. Coolify is often deployed in CI/CD contexts with broad access to infrastructure and secrets. Compromised credentials are common in breach scenarios, and the RCE impact is severe—host-level code execution during builds can contaminate images, leak environment variables, or install persistent backdoors. The fix is available and straightforward to apply. Organizations running production Coolify should prioritize this update within 1–2 weeks; those using Coolify in high-privilege environments (e.g., production deployments, secrets management) should treat it as critical and patch within days.

Risk score, explained

The CVSS 3.1 score of 8.8 (HIGH) reflects the combination of network accessibility (AV:N), low attack complexity (AC:L), high impact on confidentiality, integrity, and availability (C:H/I:H/A:H), and an unsandboxed security context (S:U). The only limiting factor is the requirement for prior authentication (PR:L). Given that build parameters are often under user control and credentials may be shared, delegated, or compromised, the practical exploitability is closer to HIGH than MEDIUM. The score appropriately prioritizes this above many other authenticated vulnerabilities and below only the most critical unauthenticated RCEs.

Frequently asked questions