Vert.x Mail Client EUVD-2026-101577

Exploitation requires an application that passes attacker-controllable data into vertx-mail-client header or metadata APIs - specifically MailMessage.addHeader()/setHeaders(), MailAttachment.addHeader()/setHeaders(), or MIME metadata setters setContentType()/setDisposition()/setDescription()/setContentId() (plus a From display-name path via Utils.mustEncode for a bare LF). No authentication is required (PR:N) and no user interaction is needed, but the vulnerability is only reachable when the host application forwards unsanitized user input into one of these fields; applications that hardcode or strictly validate header values before calling the mail client are not exposed. The limiting factor is therefore application wiring of untrusted input, not a product configuration toggle.

This is a genuine but moderate-severity integrity issue, not the critical RCE its tag implies. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms unauthenticated, low-complexity, remote reachability, but impact is confined to VI:L (low integrity) with VC:N and VA:N - no data disclosure and no availability loss - consistent with SMTP/MIME header injection (CRLF injection) rather than code execution. The input 'RCE' tag directly contradicts the CVSS impact metrics and the description, which describes header spoofing and message tampering, so it should be treated as mislabeled. No EPSS score, KEV listing, POC, or SSVC decision data was provided; therefore exploitation status is 'no public exploit identified at time of analysis' and no active-exploitation or automatable claim can be made. The true risk is conditional: it only materializes in deployments that pass attacker-controlled data into the vertx-mail-client header/attachment APIs, so despite the unauthenticated network vector the real-world footprint is limited to a subset of applications. Net: a real, worth-patching flaw for affected deployments, but a mid-tier priority - not a drop-everything emergency.

An application built on vertx-mail-client feeds unsanitized user input (e.g. a web contact form or API field) into MailMessage.addHeader(), setHeaders(), or attachment metadata. An unauthenticated attacker embeds a CR/LF sequence in the value to inject an extra Bcc or Reply-To header, silently redirecting a copy of outgoing mail or prepending forged body content. No public exploit code is identified at time of analysis, but the technique is well-understood and trivial to reproduce given the low attack complexity.