EUVD-2026-84006
GHSA-j6jw-3jf9-6hc7
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft email header address with shell metacharacters
-
DeliverySubmit message to Windows Perl app using Sendmail transport
-
ExploitEnvelope built from From/To/Cc reaches _sendmail_pipe
-
Executionopen() passes command string to shell
-
ImpactArbitrary commands run as sending process
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization OS command sanitization, avoid shell exec
MITRE ATT&CK
2 techniques across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires ALL of: (1) the application runs on Windows (MSWin32) - on every other platform sendmail arguments are passed as a list with no shell, making the flaw non-existent; (2) the app uses Email::Sender::Transport::Sendmail (not the SMTP transport); (3) the caller supplies no explicit envelope, so Email::Sender::Simple derives the envelope sender/recipients from the From, To, and Cc headers; and (4) the attacker controls one of those header addresses and embeds shell metacharacters. No authentication or user interaction is needed to supply a malicious header. The Windows-only requirement is the dominant limiting factor and sharply narrows the real-world attack surface. |
| Impact | The vendor CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) overstates real-world risk because it ignores a hard platform gate: the shell-injection path in _sendmail_pipe only exists on MSWin32 - every other OS uses open()'s list form and passes arguments directly to sendmail with no shell. So the flaw is unexploitable on Linux/BSD/macOS entirely. On Windows it further requires that the application uses the Sendmail transport (many Perl apps on Windows use the SMTP transport instead) and that the attacker-controlled From/To/Cc header reaches the envelope - which happens when Email::Sender::Simple is called without an explicit envelope. Given those gates I lean toward AC:H rather than AC:L (~8.1). Corroborating signals point to low urgency: EPSS is only 0.22% (13th percentile), there is no CISA KEV listing, and no public PoC. SSVC frames it as Exploitation=none, Automatable=yes, Technical Impact=total - meaning if it were reachable it would be fully damaging and scriptable, but there is no observed exploitation. Net: a genuine unauthenticated command-injection with total technical impact, but scope-limited to Windows deployments of a Perl library, so treat as patch-soon rather than emergency. A patch (v2.602) is confirmed available. Note a metadata inconsistency: the CVE record is CVE-2026-93012 but the vendor Changes entry cites 'CVE-2026-84344' for the same fix - verify the canonical identifier. |
| Exploit ScenarioDerived | A Perl application running on Windows uses Email::Sender::Transport::Sendmail (via Email::Sender::Simple) to send mail and derives the envelope from message headers. An attacker submits a From/To/Cc address containing shell metacharacters (e.g. a crafted 'address' embedding a command), which is concatenated into the single command string that open() hands to the shell, executing arbitrary commands as the sending process. No public exploit code was identified at time of analysis, though SSVC rates the technique as automatable. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 22, 2026
Arbitrary command injection on Windows in the Perl distribution Email::Sender (Email::Sender::Transport::Sendmail versions before 2.602) lets an attacker who controls a From, To, or Cc header address execute commands as the sending process, because on MSWin32 the envelope sender and recipients are concatenated into a single command string that Perl's open() hands to a shell. The flaw is strictly Windows-only: on every other platform the transport uses open()'s list form and passes arguments directly to sendmail with no shell involved, so the injection path does not exist there, and exploitation additionally requires that the application use the sendmail transport rather than the SMTP transport and that the caller supply no explicit envelope (letting Email::Sender::Simple derive addresses from headers). The vendor CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N) overstates real-world risk given that hard platform gate; our assessment uses CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, EPSS is low at 0.22% (13th percentile), SSVC records no observed exploitation with automatable attack and total technical impact, and no public exploit code was identified at time of analysis, though a vendor patch (2.602) and an upstream commit are public.
RemediationAI
Vendor-released patch: upgrade Email::Sender to version 2.602 or later (CPAN release Email-Sender-2.602), which on Win32 validates every envelope address against the pattern \A[0-9a-z][-0-9a-z._+=]*\@[0-9a-z][-0-9a-z.]*\z and rejects anything else with an Email::Sender::Failure::Permanent instead of building a command line; the upstream fix is commit 9a587bc9ff4edae13239190c2651da2c76b1e72c and the release notes are at https://metacpan.org/release/RJBS/Email-Sender-2.602/changes, with the advisory thread at https://seclists.org/oss-sec/2026/q3/854. If upgrading is not immediately possible, the most effective compensating control on Windows is to stop using the sendmail transport altogether and switch to Email::Sender::Transport::SMTP (or any transport that does not spawn a local program), which removes the shell from the path entirely; the trade-off is that mail routing then depends on an SMTP relay being available and configured, and any sendmail-specific behavior (aliases, local delivery, -f handling) is lost. A second option is to always pass an explicit, caller-controlled envelope to send_email rather than letting Email::Sender::Simple derive addresses from the From/To/Cc headers, and to validate those addresses against the same conservative character class before handing them to the transport - this defeats the header-injection vector but fails on legitimate RFC 5322 addresses containing quoted local-parts, plus signs in local-parts, or domain literals, and it requires every call site to be audited. Sanitizing or rejecting inbound message headers before they can ever reach a transport is worthwhile in all cases but is not a substitute for patching, since the transport is the component that decides whether a shell is invoked. Note that the patched behavior deliberately refuses many perfectly legal addresses on Windows; deployments that must accept such addresses should move to the SMTP transport as the upstream documentation recommends. Detection can focus on Windows hosts running Perl applications that call Email::Sender::Transport::Sendmail, particularly any process spawning cmd.exe or a sendmail batch file with addresses containing shell metacharacters; no public exploit code was identified at time of analysis, so exploitation is expected to be opportunistic rather than widespread given the low EPSS score.
Affected ProductsAI
Affected is the Perl distribution Email::Sender through version 2.601, specifically the Email::Sender::Transport::Sendmail component whose _sendmail_pipe routine builds a shell command line when $^O eq 'MSWin32' (perl on Windows, MSWin32 platform). Applications are exposed only if they run on Windows, use Email::Sender::Transport::Sendmail (rather than Email::Sender::Transport::SMTP), and send messages without an explicit envelope so that Email::Sender::Simple populates the envelope sender and recipients from the From, To, and Cc headers. Linux, macOS, and other non-Windows platforms are unaffected because they take the open() list-form branch that execs sendmail directly without a shell. The distribution is published on CPAN (see the release changes at https://metacpan.org/release/RJBS/Email-Sender-2.602/changes and the fix commit https://github.com/rjbs/Email-Sender/commit/9a587bc9ff4edae13239190c2651da2c76b1e72c.patch); no CPE identifiers were supplied in the input data. The issue was reported by CPANSec and is tracked as CVE-2026-93012 (EUVD-2026-84006), with a sibling identifier CVE-2026-84344 appearing in the upstream Changes entry for the same fix.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The underlying weakness is CWE-78 (improper neutralization of special elements used in an OS command), rooted in a platform-conditional argument-construction bug in Email::Sender::Transport::Sendmail::_sendmail_pipe. Perl's open() has two distinct invocation styles: the list/indirect-filehandle form (open(my $fh, '|-', $prog, @args)) forks and execs the program directly with an argument vector and never invokes a shell, while the single-string pipe form (open(my $fh, qq(| "$prog" -i -f $from @to))) passes the assembled string through the system command interpreter. Because MSWin32 historically lacks a reliable argument vector for spawned processes in every Perl this library supports, the pre-2.602 code built a single command string on Windows: qq(| "$prog" -i -f $envelope->{from} @{$envelope->{to}}). That means the envelope sender and each recipient become part of a shell command line, and shell metacharacters in any of them are interpreted by the shell (or by cmd.exe when the configured sendmail is a batch file). The attack surface is widened by Email::Sender::Simple, which, when the caller provides no explicit envelope, synthesizes the envelope from the message's From header (as sender) and To/Cc headers (as recipients) - headers an attacker can often influence. RFC 5322 permits characters in local-parts and quoted forms that are legal mail addresses but unsafe on a Windows command line, which is exactly the gap the fix closes: version 2.602 adds a _is_win32 helper and a conservative $WIN32_SAFE_ADDRESS pattern (\A[0-9a-z][-0-9a-z._+=]*\@[0-9a-z][-0-9a-z.]*\z) enforced by _assert_win32_safe_envelope, throwing Email::Sender::Failure::Permanent for any non-conforming envelope address on Win32 before the command line is ever built. The accompanying test file t/sendmail-args.t subclasses the transport to simulate both platforms and verifies both the Unix list-form arguments and the refusal of unsafe Windows addresses.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AV:N and PR:N because an attacker remotely supplies a malicious header address unauthenticated; AC:H because exploitation is gated on Windows-only deployment plus Sendmail-transport/no-envelope config; full C/I/A as commands run as the sending process.
Primary rating from Vendor (CPANSec).
CVSS VectorVendor: CPANSec
Lifecycle Timeline
3DescriptionCVE.org
Email::Sender::Transport::Sendmail versions before 2.602 for Perl allow arbitrary command execution on Windows sending a message whose envelope address reaches the shell in _sendmail_pipe.
On MSWin32 the envelope sender and every recipient go into a single command string, which open() passes to a shell. Every other platform gets the list form, which runs sendmail directly. When the caller supplies no envelope, Email::Sender::Simple takes the recipients from the To and Cc headers and the sender from the From header.
An attacker who controls one of those header addresses runs commands as the sending process.
Executive ViewAI
A critical command-injection flaw in the Perl Email::Sender distribution (Email::Sender::Transport::Sendmail versions before 2.602) allows an attacker who controls a From, To, or Cc address in an outbound message to execute commands as the mail-sending process, but only on Windows hosts. Because exploitation requires the Windows platform, use of the sendmail transport instead of the SMTP transport, and an application that supplies no explicit envelope, only a narrow slice of the application estate is exposed, and no public exploit has been identified at time of analysis. Leadership should care because any server that does meet those conditions effectively hands remote, unauthenticated code execution to whoever can influence an email header, which could compromise the application and its mail relay credentials - while the vendor's 9.8 score overstates that exposure given the hard platform and configuration gates.
Apply vendor patch (Email::Sender 2.602 or later resolves the vulnerable range). Until it is deployed, use Email::Sender::Transport::SMTP instead of the sendmail transport, pass an explicit envelope so header addresses are never used to build the command, run the Windows mail-sending process with a least-privilege account, and restrict its ability to spawn or invoke external binaries.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
OS command injection occurs when an application passes unsanitized user input directly into system shell commands.
Exploit-DB