SmarterMail EUVD-2026-28826

Requires valid authenticated credentials for any SmarterMail user account with API access permissions. The vulnerability affects the /api/v1/report/summary/{type} endpoint specifically, so exploitation depends on API functionality being enabled and accessible to authenticated users. Default SmarterMail configurations typically grant API access to standard user accounts, making any compromised user credential sufficient. Network accessibility to the SmarterMail API (typically TCP 443/9998) is required. Attack complexity is low (AC:L) with no user interaction (UI:N) needed beyond initial authentication, meaning exploitation is straightforward once credentials are obtained. Limiting factors: authentication requirement (PR:L) prevents anonymous exploitation; organizations with MFA enforcement and restrictive API access policies face reduced risk; firewall rules limiting API access to specific IP ranges constrain remote attack surface but not insider threats or compromised accounts.

Real-world risk is HIGH for authenticated attackers but requires initial credential compromise. The CVSS 8.7 score accurately reflects network attack vector (AV:N) with low complexity (AC:L) but critically requires low-privileged authentication (PR:L), meaning attackers need valid user credentials before exploiting the path traversal. This authentication requirement significantly reduces attack surface compared to unauthenticated remote code execution vulnerabilities. However, once any user account is compromised (through phishing, password reuse, or weak credentials), the attacker gains access to ALL user passwords and 2FA secrets system-wide, representing catastrophic horizontal privilege escalation. No EPSS data or KEV status provided, so exploitation prevalence is unknown. The availability of public exploit details from VulnCheck combined with straightforward exploitation (authenticated API call with path traversal payload) means proof-of-concept development is trivial. Vendor patch availability in build 9560 enables immediate remediation. Priority depends heavily on authentication posture: organizations with strong MFA enforcement and minimal authenticated user access to API endpoints face lower immediate risk, while those with weak password policies or compromised accounts face critical exposure. The chained nature (LFI + weak crypto) is particularly concerning as it defeats defense-in-depth expectations around encrypted credential storage.

An attacker compromises a low-privilege SmarterMail user account through phishing or password reuse. They authenticate to the SmarterMail API and craft requests to /api/v1/report/summary/../../../../path/to/credentials.json, exploiting the path traversal to read JSON files containing encrypted passwords and 2FA secrets for all users. Using publicly documented hardcoded encryption keys, the attacker decrypts the credentials offline, gaining administrative access to the mail server and all user accounts, enabling email interception, data exfiltration, and further lateral movement within the organization.