Coolify CVE-2026-34198

The attacker must be able to send an HTTP request with a forged X-Forwarded-Host header to the Coolify instance's password reset endpoint - no authentication or prior access required (PR:N, AV:N per CVSS). The default Coolify configuration with TrustProxies set to '*' is the enabling condition; instances that override this to trust only a specific, named reverse proxy are not exploitable via this path. The victim must click the password reset link delivered to their email (UI:R), which is the primary friction point. The attacker must have knowledge of a valid user email address to target; indiscriminate mass-triggering is possible if an email enumeration vector exists. Exploitation is limited to the password reset flow - it does not affect login sessions, API tokens, or other authentication paths. Coolify instances that are not reachable from the public internet (e.g., internal-only deployments) face significantly reduced exposure.

The NVD-assigned CVSS of 5.3 (AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N) is modest but potentially undersells real-world impact. AC:H reflects the need for an attacker to know a target's email and for the victim to click - realistic preconditions given that Coolify is often operated by small teams where user emails may be discoverable. UI:R is a genuine friction point but password reset emails are designed to be acted upon, making click-through likely. C:N is questionable: account takeover in a Coolify instance grants access to all managed servers, applications, and databases, implying confidentiality breach in post-exploitation, though the base vector narrowly scores the credential-interception step itself. EPSS data was not provided. KEV status is negative and no POC is confirmed, suggesting exploitation has not been publicly demonstrated. The attack is straightforward to execute conceptually - no memory corruption or complex timing required - so the risk is primarily gated on victim interaction and email delivery. For self-hosted deployments where the Coolify instance manages sensitive infrastructure, the effective blast radius of account takeover is high despite the mid-range base score. This is a real remediation priority for any internet-exposed Coolify instance.

An attacker who knows (or enumerates) a Coolify user's email address sends an HTTP POST to the password reset endpoint with an X-Forwarded-Host header set to an attacker-controlled domain (e.g., evil.attacker.com). Coolify's unguarded middleware stack accepts this header as the canonical host, generates a reset URL of the form https://evil.attacker.com/reset-password?token=<TOKEN>, and emails it to the victim. When the victim clicks the link expecting a legitimate Coolify login page, the token is transmitted to the attacker's server, which can then be replayed against the real Coolify instance to take over the account. No public POC has been confirmed, but the technique is well-understood and requires no special tooling.