SEPPmail CVE-2026-8811

Exploitation requires the SEPPmail Secure Email Gateway to be processing an attachment through its encrypted-PDF generation feature, so the attacker must be able to deliver an email with a maliciously named attachment to a recipient whose mail flow triggers PDF encryption on the gateway, and the CVSS 4.0 vector indicates PR:L plus an attack requirement (AT:P), meaning some prerequisite condition in the message-processing pipeline must be met rather than pure unauthenticated remote exploitation. The impact is bounded by the gateway's filesystem permissions on the PDF-generation worker and by whether the resulting traversal target lands in a directory actually served by the appliance's web interface; deployments that do not use PDF encryption of attachments are not in the vulnerable code path.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:H/SA:L) scores 7.1 and indicates a network-reachable flaw with low attack complexity but a 'Present' attack requirement (AT:P) and low privileges (PR:L), so exploitation depends on specific email-processing conditions and some level of authenticated/system access rather than being a trivial drive-by. Vulnerable-system integrity is High (file write into web-accessible paths) while confidentiality is N, which is consistent with a write-primitive rather than a data-disclosure bug. No KEV listing, no EPSS data, and no public exploit code are referenced in the inputs, so this should be treated as a high-severity, patch-promptly issue for SEPPmail operators rather than confirmed active exploitation; the AT:P and PR:L choices versus the description's wording ('an attacker can exploit') should be verified with the vendor advisory because the exact privilege required for the malicious attachment path is not fully spelled out in the description.

An attacker sends an email to a SEPPmail-protected recipient with an attachment whose filename contains directory-traversal sequences; when the gateway generates the encrypted-PDF representation of that attachment, the crafted filename causes the output file to be written into a directory served by the appliance's web interface. The attacker then requests that file over HTTP/HTTPS - for example, a planted script or HTML payload - to achieve content placement, defacement, or webshell-style follow-on access. No public exploit code is identified at time of analysis.