CVE-2025-68643: Axigen Mail Server · Cross-site Scripting
Source CVE Database V5
Not known to be exploited · CVSS 5.4 Medium · fixed in 10.5.57 : update affected systems when convenient.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 10% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 10.5.57
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:NExploitation evidence
Disclosed: evidence found.
CVE published 5 Feb 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
In the absence of an official patch, administrators should restrict access to account preference modification interfaces and enforce strong authentication mechanisms, including multi-factor authentication, to prevent unauthorized changes. Regularly audit account preferences for suspicious entries, particularly the timeFormat parameter. Implement Content Security Policy (CSP) headers in the WebMail interface to limit the execution of unauthorized scripts. Network segmentation and monitoring for unusual WebMail activity can help detect exploitation attempts. Additionally, educate users about phishing and credential security to reduce the risk of initial compromise. Organizations should also monitor threat intelligence feeds for any emerging exploits targeting this vulnerability and prepare incident response plans accordingly.
Description
Axigen Mail Server before 10.5.57 allows stored Cross-Site Scripting (XSS) in the handling of the timeFormat account preference parameter. Attackers can exploit this by deploying a multi-stage attack. In the first stage, a malicious JavaScript payload is injected into the timeFormat preference by exploiting a separate vulnerability or using compromised credentials. In the second stage, when the victim logs into the WebMail interface, the unsanitized timeFormat value is loaded from storage and inserted into the DOM, causing the injected script to execute.