SmarterMail CVE-2026-104084

Exploitation requires a valid JWT refresh token that was issued to an account before its role was downgraded, redeemed through the POST /api/v1/auth/refresh-token endpoint; because the role claim is embedded at issuance and not revalidated against the account's current role, the reissued access token retains the stale higher-privilege role (DomainAdmin or SysAdmin). The attacker must either be a demoted user still holding their pre-demotion refresh token (whose session was not actively polling at the time of demotion) or have captured such a token. Limiting factors: the attacker needs a previously-privileged account or a stolen refresh token (PR:L, not unauthenticated), the flaw only matters where privileged accounts get demoted/revoked, and the elevated access is bounded by the token's natural expiry rather than persisting indefinitely.

This is a credible mid-to-high priority issue, but not an emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H, score 8.7) indicates a network-reachable, low-complexity flaw requiring low privileges (PR:L) with high confidentiality, integrity, and availability impact on the vulnerable system and no subsequent-system scope change (SC:N/SI:N/SA:N) - consistent with an application-layer privilege escalation (CWE-613, insufficient session/token expiration) rather than host takeover. The PR:L requirement is the key risk-limiting factor: the attacker must either already hold a (now-demoted) account or have captured a refresh token, so this is not pure unauthenticated RCE. No EPSS score was provided (unknown exploitation probability), the CVE is NOT on CISA KEV, and no public POC is referenced, so there is no public exploit identified at time of analysis. The signals are therefore consistent rather than conflicting: a legitimately high-impact privilege-escalation bug disclosed by a reputable finder (VulnCheck) with a patch available, but no evidence yet of real-world exploitation. Treat as a prioritized patch for any internet-facing SmarterMail instance where admin demotions are part of normal operations, rather than a drop-everything incident.

An administrator demotes a DomainAdmin or SysAdmin account (e.g., offboarding or revoking access), but that user still holds a refresh token issued before the demotion. The user replays the stale refresh token against POST /api/v1/auth/refresh-token and receives a fresh access token that still carries the old high-privilege role claim, regaining administrative control until the token naturally expires. No public exploit code is identified, but the attack requires only a standard HTTP client and a previously valid refresh token.