CVE-2026-56709 in Grav
Summary
by MITRE • 08/25/2026
Grav before 3.9.2 fails to validate untrusted Host headers in the sendInvitationEmail() function when constructing token-bearing invitation links. Attackers can manipulate the Host header to poison invitation links and redirect users to attacker-controlled domains, bypassing the require_trusted_host protection which only covers password reset flows.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in Grav versions prior to 3.9.2 represents a critical failure in input validation within the application's email notification subsystem. Specifically, the sendInvitationEmail function constructs URLs for user invitation tokens by relying on unvalidated Host headers received from incoming HTTP requests. In standard web application architecture, the Host header is often used as a source of truth for determining the base URL when generating absolute links. However, this approach introduces significant risk if the server does not strictly enforce that the Host header matches an expected domain configuration. By failing to validate these untrusted inputs against a whitelist or configured trusted hosts list, Grav inadvertently allows external actors to inject arbitrary hostnames into the generated invitation URLs. This flaw is particularly insidious because it targets the user onboarding and account activation workflows rather than immediate authentication bypasses during login attempts.
The operational impact of this vulnerability centers on URL poisoning and potential phishing attacks. When an attacker sends a request with a manipulated Host header, such as setting it to a malicious domain controlled by the adversary, Grav incorporates this value into the invitation link sent via email. Consequently, when the recipient clicks the link intended for account activation or password reset, they are redirected to the attacker-controlled domain rather than the legitimate application server. This redirection can be leveraged for credential harvesting if the phishing site mimics the login interface, leading to unauthorized access of user accounts. Furthermore, it undermines trust in the platform by exposing users to social engineering attacks disguised as official communications from the service provider. The integrity of the invitation process is compromised because the cryptographic token remains valid but is delivered through a deceptive channel that diverts traffic away from the secure application environment.
It is important to distinguish this flaw from other host header vulnerabilities within Grav, such as those affecting password reset flows which are protected by require_trusted_host settings. The specific gap lies in the fact that these security controls were not uniformly applied across all email generation functions. While some parts of the application correctly enforced trusted host validation, others like sendInvitationEmail did not check against this configuration before constructing URLs. This inconsistency creates a predictable attack surface where attackers can target less protected endpoints to achieve similar malicious outcomes without needing to bypass more robust security mechanisms. The lack of consistent enforcement highlights a systemic issue in how the framework handles dynamic URL generation across different modules, allowing specific functions to remain vulnerable despite broader security measures being present elsewhere in the codebase.
From a classification perspective, this vulnerability aligns with CWE-113, Improper Neutralization of CRLF Sequences in HTTP Headers, although it is more accurately described as CWE-601 URL Redirection to Untrusted Site via Host Header Injection or CWE-295 Improper Certificate Validation if considering the trust model. In terms of offensive security tactics, this behavior corresponds to ATT&CK technique T1583.004 Acquire Infrastructure: Domains, where adversaries register domains for use in subsequent attacks such as phishing and malware distribution. The exploitation path involves manipulating server-side logic rather than client-side code, making it a server-side request forgery variant focused on output manipulation. Attackers can automate this process by sending multiple requests with varying malicious Host headers to generate poisoned links that are then distributed via email or other channels to victims.
Mitigation strategies must focus on enforcing strict validation of the Host header at the application level rather than relying solely on web server configurations. Developers should implement a whitelist-based approach where only explicitly defined domains are permitted for URL generation, regardless of what is sent in the request headers. Additionally, utilizing framework-provided methods that abstract host detection and enforce trusted hosts configuration across all email templates would prevent such inconsistencies. Upgrading to Grav version 3.9.2 or later resolves this issue by ensuring consistent validation logic is applied to all invitation-related functions. Administrators should also consider implementing Content Security Policy headers and monitoring for unusual patterns in outbound emails that contain links pointing to unexpected domains, providing an additional layer of defense against successful exploitation attempts.