CVE-2026-104084 in SmarterMail
Summary
by MITRE • 10/09/2026
SmarterMail before build 9777 contains a privilege escalation vulnerability where JWT access and refresh tokens embed a role claim at issuance that is not revalidated against the account's current role when redeemed through POST /api/v1/auth/refresh-token. Attackers who capture a refresh token issued before an administrator demotion, or a demoted user whose session was not actively polling at the time of demotion, can replay the stale token to obtain a new access token retaining the higher-privilege role (such as DomainAdmin or SysAdmin) until natural token expiry.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in SmarterMail versions prior to build 9777 represents a critical privilege escalation flaw rooted in improper validation of security tokens during the authentication refresh cycle. This issue specifically affects the JSON Web Token (JWT) mechanism used for maintaining user sessions and managing access privileges within the application's web interface. The core technical deficiency lies in the handling of JWT refresh tokens, which are designed to allow users to obtain new access tokens without re-entering credentials when their initial session expires or becomes stale. In a secure implementation, any token redemption process must strictly validate that the user associated with the request currently possesses the permissions required for the requested action. However, SmarterMail fails to perform this critical check during the execution of the POST /api/v1/auth/refresh-token endpoint. Instead of querying the current state of the user's account and role assignments from the backend database or identity store at the moment of redemption, the system relies on the static data embedded within the refresh token itself. This architectural oversight creates a significant window for exploitation where historical privilege states override current administrative controls.
The operational impact of this vulnerability is severe, as it allows attackers to bypass intended access restrictions and regain elevated privileges such as DomainAdmin or SysAdmin roles after they have been explicitly revoked by an administrator. The attack scenario typically begins with the capture of a refresh token issued while the user still held high-level permissions. This can occur through various vectors including cross-site scripting attacks, network sniffing if transport layer security is misconfigured, or insider threats who retain access to session data. Once captured, the attacker submits this stale refresh token to the authentication endpoint. Because the system does not revalidate the account's current role against its internal records of privilege changes, it accepts the token as valid and issues a new JWT access token that retains the original, higher-privilege role claim. This effectively neutralizes administrative demotions or permission revocations, allowing previously restricted users to continue operating with full administrator capabilities until the refreshed tokens naturally expire.
From a classification perspective, this vulnerability aligns closely with CWE-269 Improper Privilege Management and CWE-613 Insufficient Session Expiration. The failure to revalidate user roles during token refresh is also indicative of CWE-754: Improper Check for Unusual or Exceptional Conditions within the authentication logic flow. In terms of offensive security frameworks, this behavior facilitates lateral movement and persistence techniques described in MITRE ATT&CK under T1078 Valid Accounts, specifically where an attacker maintains access by exploiting stale credentials or tokens that have not been properly invalidated upon privilege changes. The lack of real-time synchronization between the token's embedded claims and the authoritative source of truth for user permissions undermines the fundamental principle of least privilege, which is essential for maintaining a secure perimeter within enterprise communication platforms like SmarterMail.
Mitigation strategies must focus on enforcing strict validation at every step of the authentication lifecycle. Developers should modify the refresh-token endpoint to query the current role assignments from the database or identity provider before issuing new access tokens. This ensures that any changes in user status, such as demotion or account suspension, are immediately reflected in subsequent token generations. Additionally implementing short-lived access tokens combined with robust rotation policies can limit the window of opportunity for attackers exploiting stale refresh tokens. Organizations running affected versions should upgrade to build 9777 or later where this validation logic has been corrected. Until an update is applied, administrators should manually invalidate all active sessions and force re-authentication for users whose privileges have recently changed to ensure no residual high-privilege tokens remain in circulation.