CVE-2026-34198: Coolify Password Reset Host Header Injection Leading to Account Takeover
Coolify, an open-source server and application management tool, contains a vulnerability that allows unauthenticated attackers to hijack user accounts by manipulating password reset emails. The vulnerability stems from weak proxy trust settings and a broken host validation mechanism that together allow an attacker to redirect password reset links to their own domain, capturing the reset token and gaining access to victim accounts. The flaw affects Coolify versions prior to 4.0.0-beta.471.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 5.3 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N
- Weaknesses (CWE)
- CWE-346, CWE-640
- Affected products
- 0 configuration(s)
- Published / Modified
- 2026-07-07 / 2026-07-07
NVD description (verbatim)
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.
5 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
Coolify's TrustProxies middleware is configured to accept X-Forwarded-Host headers from any source (wildcard '*'), creating a vector for host header spoofing. The TrustHosts middleware, designed to mitigate such attacks through host validation, contains a circular caching dependency that prevents validation logic from ever executing. When a password reset is initiated, the ResetPassword notification constructs the reset URL using url(route(..., false)), which derives the host from the incoming request rather than a validated source. An attacker can craft requests that cause Coolify to generate password reset emails with malicious URLs pointing to attacker-controlled infrastructure. Because the reset token is embedded in the URL and sent via email, token interception compromises the user account.
Business impact
Account takeover poses direct operational and reputational risk. Attackers gaining administrative access to Coolify instances can modify server configurations, access stored credentials for managed databases and applications, exfiltrate sensitive data, or inject malicious workloads. For organizations using Coolify in production, a compromised instance effectively compromises all downstream infrastructure it manages. Credential theft of end-users via poisoned reset emails further extends the attack surface to other services those users access.
Affected systems
Coolify versions prior to 4.0.0-beta.471 are vulnerable. The vulnerability affects self-hosted Coolify deployments accessible via network requests—typically instances exposed to the internet or within trusted networks. Any user with an email address registered in a Coolify instance is a potential target.
Exploitability
Exploitation requires no authentication and minimal technical sophistication: an attacker triggers a password reset for a target user, observes or influences the resulting email (via phishing pretext, network position, or email compromise), and intercepts the reset token. The attack requires user interaction (clicking the link) but leverages trust in email communications from the server. The attack vector is network-accessible, and while attack complexity is marked as high in the CVSS metric (likely due to the user-interaction requirement), the underlying technical components are straightforward to exploit.
Remediation
Upgrade Coolify to version 4.0.0-beta.471 or later. This release fixes the TrustHosts middleware circular dependency and corrects the password reset URL generation to use validated host information rather than untrusted request headers.
Patch guidance
Apply the upgrade to 4.0.0-beta.471 as soon as feasible. Before patching, verify that backup and restore procedures are tested, as this is a beta release. For instances that cannot be immediately upgraded, implement network-level mitigations: restrict X-Forwarded-Host header propagation at reverse proxies or load balancers, whitelist only trusted proxy sources, and configure email filtering to flag suspicious password reset links or domains.
Detection guidance
Monitor Coolify logs and reverse proxy/load balancer logs for X-Forwarded-Host headers containing unexpected domains. Watch for password reset requests followed by immediate login attempts from unusual IP addresses or geographic locations. Correlate password reset emails sent to users with the destinations embedded in those emails—legitimate resets should reference your own domain. SIEM or log aggregation tools can flag patterns of distributed password reset requests targeting multiple accounts, suggesting automated reconnaissance.
Why prioritize this
Although the CVSS score is moderate (5.3), the vulnerability enables direct account takeover with minimal attacker effort and no authentication requirement. Coolify often manages critical infrastructure, making compromise of an administrative instance particularly damaging. Organizations running internet-facing or production Coolify instances should prioritize this patch. The combination of weak proxy validation, broken host verification, and user-facing password reset makes this a practical attack vector in real deployments.
Risk score, explained
The CVSS 3.1 score of 5.3 (MEDIUM) reflects network accessibility, no privilege requirement, and no authentication barrier, balanced against high attack complexity and required user interaction (clicking the reset link). However, the integrity impact is rated high because account takeover enables unauthorized modification of managed infrastructure. The score appropriately captures the technical difficulty but may underweight the operational severity for production Coolify deployments managing critical systems. Security teams should consider this a priority above its numeric score suggests.
Frequently asked questions
Can an attacker reset a password without knowing the user's email address?
The attacker must know or guess a valid email address associated with a Coolify user account. However, in many environments, user email addresses are discoverable through documentation, directory listings, or configuration files. The attack does not require the attacker to know the current password.
If we use Coolify in an air-gapped or internal-only network, are we still at risk?
The vulnerability requires an attacker to influence the password reset flow and redirect the reset link. In a purely internal network, this would require an insider with network access or a compromised host on that network. Risk is significantly lower than for internet-exposed instances, but the vulnerability should still be patched to close the attack surface.
Does enabling HTTPS or SSL/TLS prevent this attack?
No. HTTPS encrypts the connection between the user and Coolify, and between the user and the attacker's server, but does not prevent the attacker from crafting a malicious reset URL or the user from clicking it. The vulnerability is in the URL generation logic, not the transport security.
What should we do if we suspect password reset tokens have been compromised?
Force password resets for all Coolify users, review access logs for unusual activity, audit any configuration changes made via the Coolify interface, and check managed servers and databases for unauthorized modifications or credential exposure. If the Coolify instance manages production infrastructure, treat this as a security incident requiring forensic investigation.
This analysis is provided for informational purposes and based on the vulnerability description and CVSS vector provided. Security teams should verify all technical details, patch availability, and applicability to their specific deployments with official Coolify project communications and advisories. This vulnerability does not appear on the CISA Known Exploited Vulnerabilities (KEV) catalog at this time, but absence from KEV does not indicate an attack has not occurred. Implement network-level defenses (firewall rules, reverse proxy filtering) in parallel with patching. Test patches in non-production environments before deployment. Source: NVD (public-domain), retrieved 2026-08-15. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-10010MEDIUMChrome Android Site Isolation Bypass
- CVE-2026-10937MEDIUMChrome Same-Origin Policy Bypass in Password Handling
- CVE-2026-10996MEDIUMChrome Same-Origin Policy Bypass in Web Workers
- CVE-2026-11020MEDIUMChrome Extension XML Cross-Origin Data Leak – Patch to 149.0.7827.53
- CVE-2026-11032MEDIUMChrome Password Manager Cross-Origin Data Leak
- CVE-2026-11036MEDIUMChrome Same-Origin Policy Bypass via DOM Implementation Flaw
- CVE-2026-11048MEDIUMChrome Extension Same-Origin Policy Bypass (Medium, 6.5)
- CVE-2026-11081MEDIUMChrome Canvas Same-Origin Policy Bypass