CVE-2026-86196 in API Plugin
Summary
by MITRE • 09/05/2026
Grav API plugin versions before 1.0.20 build password reset links from the untrusted Host header in the forgot-password endpoint, allowing unauthenticated attackers to redirect reset tokens to attacker-controlled domains. Attackers can send password reset requests for any account with a malicious Host header, intercept the reset token from victim emails, and complete account takeover including super-admin accounts.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/05/2026
The Grav API plugin prior to version 1.0.20 contains a critical insecure direct object reference vulnerability stemming from improper validation of user-supplied input within its password reset functionality. Specifically, the forgot-password endpoint constructs URLs for password reset tokens by directly incorporating values from the HTTP Host header without performing adequate sanitization or verification against an allowlist of trusted domains. This architectural flaw allows unauthenticated remote attackers to manipulate the origin of these generated links by injecting a malicious value into the Host header during their request submission. Because web servers and application frameworks often rely on this header for routing and link generation, the application blindly trusts it as a legitimate indicator of the site's domain, failing to recognize that an attacker can spoof or override this field through standard HTTP requests.
This vulnerability enables a sophisticated account takeover attack vector where adversaries can intercept sensitive authentication tokens intended for victims. By sending a password reset request while specifying their own controlled domain in the Host header, attackers force the application to generate a reset link pointing to infrastructure they control rather than the legitimate site. When the victim receives this email and clicks the provided link, or when the attacker monitors traffic on their server, they can capture the unique reset token embedded within that URL. With possession of this valid token, which is typically time-limited but often sufficiently long-lived for exploitation purposes, the attacker gains the ability to set a new password for any targeted user account without knowing the original credentials.
The operational impact of this flaw extends beyond standard user accounts to include super-administrator privileges due to the nature of how reset tokens are validated and applied within the Grav CMS ecosystem. Since the vulnerability affects all endpoints that utilize the Host header for link generation, an attacker can target high-privilege accounts with equal ease as low-level users. Successful exploitation results in a complete compromise of user integrity and confidentiality, allowing unauthorized access to sensitive data, modification of site configurations, and potential further lateral movement within the hosting environment if additional vulnerabilities exist. This represents a severe breach of trust between the application and its authentication mechanisms, fundamentally undermining the security model designed to protect account recovery processes.
From an industry standards perspective, this vulnerability aligns with CWE-20 Improper Input Validation as the root cause lies in the failure to validate external input before using it in critical logic. It also maps directly to ATT&CK technique T1534 Internal Spearphishing if used for credential harvesting or more accurately to T1621 Multi-Factor Authentication Interception if viewed through the lens of bypassing secondary verification steps inherent in password resets, though strictly speaking it is a form of phishing via manipulated links. The specific behavior of redirecting users or tokens to attacker-controlled domains also exhibits characteristics associated with CWE-437 Incomplete Implementation of Function which often leads to unintended side effects like this redirection flaw.
To mitigate this vulnerability and prevent similar issues in future implementations, developers must avoid using untrusted headers such as Host for constructing absolute URLs within application logic. Instead, the base URL or domain should be configured via secure server configuration files or environment variables that are not directly influenced by client-side HTTP requests. Implementing a strict allowlist of trusted domains provides an additional layer of defense against header injection attacks. Furthermore, applying security headers such as Strict-Transport-Security and ensuring proper Content Security Policy configurations can help mitigate the impact if any residual redirect vulnerabilities exist. Upgrading to version 1.0.20 or later is essential for existing deployments, as this release addresses the input validation gap by implementing robust checks on all user-supplied data used in link generation processes.