CVE-2026-34198: Coolify Auth Bypass Vulnerability

CVE-2026-34198 Overview

Coolify is an open-source, self-hostable platform for managing servers, applications, and databases. Versions prior to 4.0.0-beta.471 contain a host header injection vulnerability that enables account takeover through the password reset flow. The TrustProxies middleware trusts all proxies with $proxies = '*', accepting the X-Forwarded-Host header from any source. The TrustHosts middleware, which should mitigate host header attacks, contains a circular caching dependency that prevents it from ever validating hosts. As a result, the ResetPassword notification generates password reset URLs derived from an attacker-controlled request host.

Critical Impact
An unauthenticated attacker can trigger a password reset email containing a link pointing to an attacker-controlled domain, enabling reset token theft and full account takeover.

Affected Products

Coolify versions prior to 4.0.0-beta.471
Self-hosted Coolify instances with default middleware configuration
Deployments exposing the password reset endpoint to untrusted networks

Discovery Timeline

2026-07-07 - CVE-2026-34198 published to NVD
2026-07-07 - Last updated in NVD database

Technical Details for CVE-2026-34198

Vulnerability Analysis

The vulnerability is classified as [CWE-346] Origin Validation Error. The root cause is a broken trust chain across two Laravel middleware components. Coolify configures TrustProxies with a wildcard, treating every upstream client as a trusted proxy. This causes the framework to honor forwarded headers such as X-Forwarded-Host regardless of source.

The complementary TrustHosts middleware is intended to constrain acceptable host values. However, its implementation has a circular caching dependency that prevents the allow-list from ever being evaluated. The middleware effectively becomes a no-op, and Coolify accepts any host value supplied by a remote client.

When the password reset flow calls url(route('password.reset', [...], false)), Laravel constructs the absolute URL using the current request's host. Because the host is attacker-controlled, the generated reset link points to an external domain while still containing a valid token for the victim's account.

Root Cause

The reset URL is derived from request state rather than server-side configuration. The false parameter to route() produces a relative path, and url() then prepends the request host. With TrustProxies accepting any forwarded host and TrustHosts failing to validate, the resulting URL is fully attacker-influenced.

Attack Vector

An unauthenticated attacker submits a password reset request for a victim account while including an X-Forwarded-Host header pointing to a domain they control. The victim receives a legitimate-looking email from the Coolify instance containing a reset link with a valid token. When the victim clicks the link, the token is delivered to the attacker's server. The attacker then submits the token to the real Coolify instance and completes the password reset, taking over the account.

php

             return call_user_func(static::$createUrlCallback, $notifiable, $this->token);
         }
 
-        return url(route('password.reset', [
+        $path = route('password.reset', [
             'token' => $this->token,
             'email' => $notifiable->getEmailForPasswordReset(),
-        ], false));
+        ], false);
+
+        // Use server-side config (FQDN / public IP) instead of request host
+        return rtrim(base_url(), '/').$path;
     }
 }

Source: Coolify security patch commit 98569e4. The patch replaces the request-derived URL with a server-side base_url() value, removing attacker influence over the generated link.

Detection Methods for CVE-2026-34198

Indicators of Compromise

Password reset requests arriving with unusual or unexpected X-Forwarded-Host header values.
Outbound email logs referencing reset URLs whose host does not match the configured Coolify FQDN.
Unexpected password reset completions or session creations for accounts that did not initiate a reset.
Web server access logs showing token-bearing requests to unknown external hosts referenced in reset emails.

Detection Strategies

Compare the host in generated password reset URLs against the configured application FQDN and alert on mismatches.
Inspect reverse proxy and application logs for X-Forwarded-Host values that differ from the primary hostname.
Correlate password reset events with subsequent authentication or account modification events from new IPs.

Monitoring Recommendations

Enable verbose logging on the /forgot-password and /reset-password routes, including request headers.
Monitor outbound SMTP traffic and archive password reset email bodies for post-incident review.
Track EPSS scoring and vendor advisories for changes in exploitation likelihood over time.

How to Mitigate CVE-2026-34198

Immediate Actions Required

Upgrade Coolify to version 4.0.0-beta.471 or later, which replaces request-host URL generation with a server-side base_url() value.
Invalidate all outstanding password reset tokens after upgrading to eliminate any tokens generated during the vulnerable window.
Force password rotation for administrative accounts if any suspicious reset activity is present in logs.

Patch Information

The fix is available in the Coolify v4.0.0-beta.471 release. Technical details are documented in the GitHub Security Advisory GHSA-cgj8-7m5q-x5gv and pull request #9193.

Workarounds

Place Coolify behind a reverse proxy that strips or overrides the X-Forwarded-Host header before it reaches the application.
Restrict the password reset endpoint to trusted networks using firewall or ingress rules until the patch is applied.
Configure the upstream proxy to enforce a fixed Host header matching the deployment's canonical FQDN.

bash

# Example nginx configuration to neutralize spoofed X-Forwarded-Host
server {
    listen 443 ssl;
    server_name coolify.example.com;

    location / {
        proxy_set_header Host coolify.example.com;
        proxy_set_header X-Forwarded-Host coolify.example.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_pass http://127.0.0.1:8000;
    }
}