CVE-2026-34198 in Coolify
Summary
by MITRE • 07/07/2026
Coolify is an open-source and self-hostable tool for managing servers, applications, and databases. Prior to 4.0.0-beta.471, the TrustProxies middleware trusts all proxies ($proxies = '*'), accepting X-Forwarded-Host from any source. The TrustHosts middleware, intended to prevent host header attacks, has a circular caching dependency that prevents it from ever validating hosts. When a password reset is requested, the ResetPassword notification generates the reset URL using url(route(..., false)), which derives the host from the (spoofable) request. An unauthenticated attacker can trigger a password reset email containing a link pointing to an attacker-controlled domain, enabling token theft and account takeover. This issue is fixed in version 4.0.0-beta.471.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/07/2026
The vulnerability in Coolify versions prior to 4.0.0-beta.471 represents a critical security flaw that undermines the application's authentication and authorization mechanisms through improper proxy trust configuration and flawed host validation. The TrustProxies middleware configuration with $proxies = '*' creates an insecure environment where all incoming requests are treated as trusted proxies, allowing any attacker to manipulate the X-Forwarded-Host header without restriction. This fundamental misconfiguration directly violates security principle of least privilege and creates an attack surface that enables man-in-the-middle and host header injection attacks. The TrustHosts middleware suffers from a circular dependency in its caching mechanism that prevents proper validation of host headers, creating a false sense of security while leaving the application vulnerable to host header manipulation attacks.
The technical exploitation of this vulnerability begins with the insecure proxy configuration that allows attackers to spoof host headers through X-Forwarded-Host fields. When an attacker triggers a password reset request, the ResetPassword notification system uses url(route(..., false)) function calls that rely on the request's host information to construct reset URLs. This approach is inherently dangerous because it derives the host from potentially compromised request headers rather than from trusted application configuration. The circular caching dependency in TrustHosts prevents any meaningful host validation, allowing attacker-controlled domains to be accepted as legitimate hosts during URL generation. This creates a direct path for attackers to manipulate password reset links and gain unauthorized access to user accounts.
The operational impact of this vulnerability extends beyond simple account takeover scenarios to encompass broader security implications including credential theft, session hijacking, and potential data breaches. Attackers can craft malicious password reset emails containing links that redirect to attacker-controlled domains, enabling them to capture reset tokens and subsequently compromise user accounts. This type of attack directly maps to attack patterns described in the ATT&CK framework under credential access and privilege escalation techniques. The vulnerability represents a classic case of insecure configuration management and insufficient input validation, falling under CWE-284 for improper access control and CWE-352 for cross-site request forgery. The flaw demonstrates how seemingly minor configuration issues can create cascading security problems that undermine core application security controls.
Mitigation strategies for this vulnerability require immediate implementation of proper proxy trust configuration where only explicitly trusted proxies are allowed to modify request headers. Organizations should configure TrustProxies middleware with specific proxy IP addresses rather than using wildcard configurations, ensuring that only legitimate reverse proxies can influence the host header values. The TrustHosts middleware must be refactored to eliminate circular dependencies and implement proper host validation logic that checks against a predefined whitelist of acceptable hosts. Application developers should modify URL generation functions to use explicit host configuration rather than deriving host information from potentially compromised request headers. Additionally, implementing strict input validation for all user-supplied data and employing secure coding practices that avoid relying on untrusted header values are essential defensive measures. The fix implemented in version 4.0.0-beta.471 addresses these core issues through proper middleware configuration and secure URL generation mechanisms that prevent host header manipulation attacks from succeeding.