CVE-2026-81036 in Stalwart
Summary
by MITRE • 08/26/2026
Stalwart Mail Server does not compare an OAuth redirect target against any registered destination in its default configuration. The validation routine in crates/http/src/auth/oauth/registration.rs returns success immediately when the client-authentication requirement is disabled, and that requirement is false in the shipped settings, so the supplied redirect value is neither matched against a registered client nor otherwise constrained. The value is stored with the authorization code, and the login page reads it back and sends the browser to it with the code attached. A request naming a destination the attacker controls therefore delivers a valid authorization code there once the account holder authenticates, and because the token endpoint checks only that the redirect presented at exchange matches the one recorded with the code, the same party can exchange it for access and refresh tokens and read the account's mail.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability in Stalwart Mail Server represents a critical failure in OAuth 2.0 authorization flow validation, specifically concerning the handling of redirect URIs during the authentication process. In standard OAuth implementations, the redirect URI serves as a security boundary to ensure that authorization codes and subsequent access tokens are delivered only to pre-registered, trusted endpoints controlled by the client application. This mechanism prevents attackers from intercepting sensitive credentials by directing them to malicious domains. However, in this specific implementation within Stalwart Mail Server, the validation logic contained in the registration module fails to enforce these constraints when certain configuration settings are altered or left at their default state. The core issue lies in a conditional check that prematurely returns success if client authentication requirements are disabled, bypassing any subsequent verification against registered redirect destinations.
In its shipped default configuration, Stalwart Mail Server has this specific client-authentication requirement set to false. Consequently, the validation routine does not compare the supplied OAuth redirect target against any list of registered or allowed destinations. This oversight means that an attacker can specify arbitrary URLs as the redirect endpoint during the authorization request initiation phase. The server accepts these unvalidated values and stores them in association with the generated authorization code. When a legitimate user authenticates to their mail account, the system redirects the browser to the attacker-controlled URL provided earlier, appending the valid authorization code to the query parameters of that malicious link.
The exploitation chain continues when the attacker intercepts this redirect or waits for it to be triggered by a victim. Because the token endpoint validation logic only checks whether the redirect URI presented during the token exchange matches the one recorded with the authorization code, and because both values were set by the same actor (the attacker), the server accepts the request without further scrutiny of the domain's legitimacy. This allows the attacker to successfully exchange the intercepted authorization code for access tokens and refresh tokens. These tokens grant full API-level access to the victim's mail account, enabling the reading, sending, or modification of email data without requiring the user’s password beyond the initial authentication step which was tricked into authorizing a malicious client.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-601 URL Redirection to Untrusted Site Open Redirect, as it involves failing to validate input against expected constraints and allowing redirection to uncontrolled destinations. From an ATT&CK perspective, this falls under T1556 OAuth Authentication Token Theft, where the attacker steals tokens through a flawed redirect mechanism rather than breaking encryption or cracking passwords directly. The impact is severe, resulting in complete compromise of user confidentiality and integrity within the mail system.
Mitigation strategies must focus on enforcing strict validation regardless of client authentication settings. Administrators should ensure that all OAuth clients are explicitly registered with specific, whitelisted redirect URIs before any authorization code can be issued. The server software itself requires a patch to remove the early return condition when client-authentication is disabled and instead mandate that every redirect URI be validated against an allowlist of pre-registered endpoints. Until such patches are applied, users should avoid using OAuth integrations with untrusted third-party clients or disable public access to the mail server’s authentication interfaces entirely. Regular audits of configuration files to ensure no insecure defaults persist in production environments are also recommended to prevent similar misconfigurations from leading to credential theft.