CVE-2026-102471 in Vert.x
Summary
by MITRE • 10/14/2026
In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the vertx-mail-client does not sanitize CR (\r) or LF (\n) characters in user-supplied email header names and values before writing them into the SMTP DATA section. A CR/LF sequence embedded in a name or value passed to MailMessage.addHeader(), MailMessage.setHeaders(), MailAttachment.addHeader(), or MailAttachment.setHeaders() is written verbatim to the wire, allowing an attacker to inject arbitrary headers (e.g. Bcc, Reply-To, Content-Type) or prepend body content to the outgoing message.
The same weakness affects MIME part metadata set via MailAttachment.setContentType(), setDisposition(), setDescription(), and setContentId(), which are written directly into MIME part headers without validation.
A secondary weakness in Utils.mustEncode(char) additionally allows a bare LF in a From display-name to bypass Q-encoding and reach the wire unchanged.
An unauthenticated attacker who can control any header name, header value, or attachment metadata field passed to the mail client (for example via a web form or API that feeds into MailMessage) can exploit this to redirect email copies, spoof headers, or tamper with message structure.
The impacted component is io.vertx:vertx-mail-client.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
Eclipse Vert.x versions within the ranges 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and specifically version 5.2.0 contain a critical input validation flaw in its mail client component, identified as io.vertx:vertx-mail-client. This vulnerability stems from the failure to sanitize carriage return (CR) and line feed (LF) characters when processing user-supplied data for email headers and MIME part metadata. The core technical issue lies in how the library handles string inputs destined for SMTP communication protocols. When developers utilize methods such as MailMessage.addHeader, MailMessage.setHeaders, MailAttachment.addHeader, or MailAttachment.setHeaders to define custom header fields, the framework writes these values directly into the SMTP DATA section without performing necessary character escaping or validation. Similarly, MIME part metadata configured via MailAttachment.setContentType, setDisposition, setDescription, and setContentId is transmitted verbatim into MIME headers. This lack of sanitization creates a direct pathway for injection attacks against the mail server infrastructure.
The operational impact of this flaw is severe, as it enables an unauthenticated attacker to perform email header injection or body prepending if they can control any input passed to the affected methods. By embedding CR/LF sequences within header names or values, an adversary can terminate a legitimate header line and inject new ones. This capability allows for significant manipulation of outgoing messages, including redirecting blind carbon copy recipients to unauthorized parties, spoofing reply-to addresses to intercept sensitive communications, or altering content-type headers to facilitate phishing attacks using malicious MIME structures. Furthermore, the ability to prepend body content means an attacker can append unsolicited text or HTML scripts before the intended message body, potentially executing cross-site scripting if the recipient client renders untrusted HTML. A secondary weakness in the Utils.mustEncode method exacerbates this risk by allowing bare LF characters within a From display-name field to bypass Q-encoding mechanisms entirely, reaching the wire unchanged and further expanding the attack surface for header manipulation.
This vulnerability aligns with Common Weakness Enumeration category CWE-74, which describes injection flaws resulting from improper neutralization of special elements used in an output segment against a parser. In the context of email protocols, it also relates to CWE-915, Improper Neutralization of Special Elements Used in an SMTP Command, specifically regarding header fields and message bodies. From a tactical perspective, this flaw supports techniques documented in the MITRE ATT&CK framework under T1078, Valid Accounts or T1498, Network Denial of Service if used to disrupt mail flow, but more critically it facilitates T1534, Internal Spearphishing by allowing attackers to craft convincing spoofed emails that appear legitimate due to controlled header fields. The exploitation requires the attacker to have some level of control over input data fed into the Vert.x mail client, such as through a web form or API endpoint that processes user submissions and forwards them via email.
Mitigation strategies must prioritize immediate updates to patched versions outside the affected ranges provided by Eclipse Vert.x maintainers. For organizations unable to upgrade immediately, defensive coding practices should be implemented within application logic preceding any calls to the mail client APIs. Developers must manually sanitize all input strings destined for header names and values by stripping or encoding CR and LF characters before passing them to MailMessage or MailAttachment methods. Additionally, custom wrappers around Utils.mustEncode can be employed to ensure strict compliance with RFC 5321 requirements regarding line length and character sets. Security teams should also audit existing codebases for any direct usage of these vulnerable APIs in production environments where user input is processed, ensuring that no unsanitized data reaches the SMTP layer. Regular penetration testing focusing on email injection vectors can help identify residual risks in custom implementations surrounding this library.