Description

An attacker that holds a token intended for a different purpose can authenticate, because when an OAuth2 token response does not contain a scope claim, the audience claim is used in its place and checked against the configured required scopes. These are different concepts, and the audience claim does not describe what a token is allowed to do. A token that grants no relevant permissions can be accepted because its intended recipient value happens to match a configured scope name, granting access that should have been denied. It also hides an identity provider misconfiguration where scopes are not being issued at all. Ensure the identity provider issues a scope claim for all tokens used with Dovecot, and that configured scope names do not match audience values. Update to non-vulnerable version. No publicly available exploits are known.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-08-28T12:16:31.127Z",
  "pubdate": "2026-08-28T12:16:31.127Z",
  "executiveSummary": "This vulnerability involves an improper authentication validation logic within Dovecot when processing OAuth2 tokens. The system incorrectly treats the 'aud' (audience) claim as a fallback for the 'scope' claim when the latter is absent. This flaw allows an attacker possessing a token minted for a different service—but sharing an audience value that matches a configured scope name—to successfully authenticate to the Dovecot service. The impact is unauthorized access to mail services due to a failure in strict authorization boundary enforcement. The risk is elevated by the fact that this behavior masks identity provider misconfigurations, specifically the failure to issue necessary scope claims. Successful exploitation requires an attacker to possess a valid OAuth2 token issued by a trusted identity provider that contains an audience value matching a scope string configured within the Dovecot environment. No public exploits are known, but the potential for unauthorized access mandates immediate attention to token validation logic.",
  "technicalDetails": "The vulnerability resides in the OAuth2 token validation logic utilized by Dovecot. In standard OAuth2/OIDC flows, the 'scope' claim is explicitly defined to identify the specific permissions or resources a client is authorized to access, while the 'aud' claim specifies the intended recipient of the token. The root cause of this vulnerability is a flawed fallback mechanism where the validator defaults to the 'aud' claim if the 'scope' claim is missing from the token payload.\nThe attack flow begins when an attacker obtains a token that was intended for a different service but issued by the same identity provider. If the Identity Provider fails to enforce the inclusion of a 'scope' claim in the token response, and the attacker’s token contains an 'aud' claim that happens to match a scope string configured within the Dovecot service (e.g., 'mail.read' or 'imap.access'), Dovecot incorrectly maps this audience value to an authorization scope. Consequently, Dovecot treats the token as having the required permissions, granting the attacker access to the requested mail resources.\nThis behavior represents a failure in 'confused deputy' prevention, as the system conflates the token's destination (audience) with the token's authorization capabilities (scopes). Because Dovecot relies on the presence of these scopes to permit authentication, the lack of a scope claim—which should normally result in a denied access request—is bypassed by the presence of a matching audience claim. This logic error effectively grants privileges based on mismatched metadata rather than explicitly defined claims.\nThe authentication requirement for this exploit is simply the possession of any valid OAuth2 token issued by an identity provider trusted by the Dovecot configuration. Privilege escalation occurs post-authentication, as the attacker bypasses the authorization check that should have prevented access due to insufficient scope permissions. This vulnerability does not require complex payload manipulation; it relies entirely on the architectural misconfiguration of the token validation routine and the inherent ambiguity permitted by the identity provider's token issuance policy."
}