SEPPMail Gateway Blues: RCE and Mail Exposure (CVE-2026-3814)
Has anyone else seen the drop on SEPPMail Secure E-Mail Gateway this morning? It looks pretty grim. According to the latest disclosure, we're looking at a set of critical vulnerabilities allowing for Remote Code Execution (RCE) and arbitrary mail reading. Since these appliances usually sit right on the perimeter, they are prime targets for pivoting into the internal network, effectively acting as a bridge past the firewall.
The specific issues seem to center around an input validation flaw in the web interface leading to RCE (CVE-2026-3814) and an improper access control issue (CVE-2026-3815) that lets an authenticated user dump arbitrary mailboxes or potentially bypass auth entirely in some configurations.
The vulnerability chain involves bypassing authentication to upload a malicious configuration, which triggers a deserialization issue leading to code execution. Since the appliance processes incoming mail, an attacker could intercept, decrypt, and exfiltrate sensitive communications without the sender or recipient knowing. This effectively breaks the 'secure' part of the Secure E-Mail Gateway.
For those monitoring these endpoints, you might want to start hunting for suspicious POST requests to the management interface or unusual file extensions being passed to the import handler.
DeviceProduct == "SEPPMail"
| where HttpRequestMethod in ("POST", "PUT")
| where HttpRequestUri contains "import" or HttpRequestUri contains "upload"
| where HttpUserAgent contains "curl" or HttpUserAgent contains "python"
| project Timestamp, SourceIP, HttpRequestUri, HttpUserAction
If you're an MSP or managing mail gateways for enterprise clients, patching this should be priority zero. How many of you are actually seeing SEPPMail in the wild? I've only run into it a few times in the DACH region, but the impact there could be massive.
We manage about 15 clients using this stack. Woke up to a nightmare of patching tickets today. The appliance takes forever to reboot, and since it handles all TLS termination, we had to schedule emergency maintenance windows. We've temporarily restricted management interface access to specific source IPs via the firewall while we apply the patches. Definitely recommend that as an immediate mitigation step if you can't patch instantly.
I actually found a similar bug in a mail gateway a few years back. The issue usually stems from the web admin panel not properly sanitizing imports or backup restores. If the attacker gets RCE as root (which is common on these virtual appliances), the mail encryption keys are usually just sitting there in /opt/seppmail/config or similar, making decryption trivial. Assume full mail compromise if you see signs of exploitation.
Good call on the KQL query. I'd also add a check for unusual outbound connections from the gateway itself. If it's compromised, it won't just be reading mail; it'll likely beacon out or try to lateral move.
netstat -antp | grep ESTABLISHED | grep -v ":25\|:443\|:80\|:587"
Keep an eye on process anomalies too—if you see python or perl spawning from the root user on that appliance, you're already owned.
The pivot risk is real. Since these boxes often have decent compute, attackers frequently drop miners immediately to monetize the RCE before moving laterally. I recommend checking for unexpected interpreters running as root or the web user:
ps auxf | grep -E "(python|perl|curl|wget)" | grep -v grep
Don't forget to audit /etc/crontab for persistence mechanisms if you suspect a breach.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access