CVE-2026-8450

What it actually does

HTTP::Daemon send_file() uses Perl’s two-argument open() on a caller-supplied path string. That form treats leading or trailing magic (pipe and redirect prefixes) as process or file-mode operators rather than a literal filename. Untrusted data reaching send_file() can therefore execute OS commands as the daemon process UID, stream subprocess stdout into the HTTP response body (read-pipe form), or create, truncate, or append attacker-chosen files (write/append forms). Confidentiality and integrity of the host and of HTTP responses are fully at risk; availability is not the primary impact.

Why it matters to the business

Any internet-facing or internally reachable service that builds on HTTP::Daemon and passes request-influenced values into send_file() can be abused for remote command execution and unauthorized file writes without authentication or user interaction (CVSS 9.1). That can mean theft of secrets, implant of persistence, tampering with application files, and data leakage through HTTP responses. Exploit maturity is currently listed as none and the CVE is not in CISA KEV, but the issue has been public for about 125 days and EPSS has risen sharply (0.0140 → 0.0261, +87% over 30 days), so opportunistic scanning and weaponization risk is increasing. Organizations running Perl HTTP daemons or products that vendor HTTP::Daemon should treat this as a high-urgency patching item even without a named campaign.

How an attack unfolds

An attacker first finds an HTTP::Daemon-based service where a filename, static-asset path, or similar string from the request (URI, query, header, or body) is passed into send_file() without rejecting open() magic. They then supply a value that two-argument open() interprets as a pipe or redirect instead of a file to read. A read-pipe style value causes the daemon to spawn a subprocess and return that process’s output in the HTTP body, confirming execution and exfiltrating command results. A write or append style value creates or overwrites a file at a path the daemon can reach, which can plant a webshell, alter configuration, or destroy data. Because the daemon’s UID runs the command or file operation, impact equals whatever that account can read, write, or execute. No named threat actors or ransomware use are associated with this CVE at this time.

How to fix it

Upgrade HTTP::Daemon to 6.17 or later, which is the first version that no longer exposes this send_file() behavior. If an immediate upgrade is not possible, stop passing any request-derived or otherwise untrusted string into send_file(); resolve and allowlist paths to known static files on disk, reject values containing pipe or redirect metacharacters, and prefer APIs that open files by literal path without two-argument open() magic. Run the daemon with least privilege (dedicated UID, no write access to code or config trees, no unnecessary shell). Inventory all Perl applications and downstream products that depend on HTTP::Daemon and apply the same upgrade.

How to confirm the fix worked

Confirm installed HTTP::Daemon is 6.17 or newer (cpan, OS package manager, or vendored lib listing). Grep application code and dependencies for send_file( usage and verify every argument is a server-controlled, allowlisted filesystem path. In a non-production check, send only benign filenames that should succeed or 404; do not use pipe or redirect prefixes as a test payload. After patching, regression-test static file serving and confirm the process no longer honors magic open prefixes. Review deployment images and lockfiles so old HTTP::Daemon versions cannot be reintroduced.

Typical attack path

1. Discover an HTTP service implemented with or embedding Perl HTTP::Daemon that serves files or otherwise calls send_file() on request-influenced input.
2. Identify a parameter (path, filename, or similar) that reaches send_file() without sanitization against two-argument open() magic prefixes.
3. Submit a request whose value is interpreted as a pipe to a subprocess or as a write/append file open rather than a read of a static file.
4. Observe command output in the HTTP response (read-pipe) or confirm unauthorized file create/truncate/append on the host (write-mode).
5. Use gained execution or file write to steal credentials, modify application files, or establish persistence under the daemon UID.

How to detect it

Assume compromise is possible on any unpatched HTTP::Daemon instance exposed for the ~125 days since publication, even though exploit maturity is none and no named APT or ransomware campaign is documented. Look for Perl or HTTP::Daemon parent processes spawning a shell or unexpected interpreters, HTTP responses whose bodies do not match the requested static asset, and files created or truncated by the daemon UID outside the document root. Useful sources: process-creation logs (EDR/Sysmon/auditd), web access and error logs, file-integrity monitoring on application and config paths, and outbound connections initiated by the daemon after suspicious requests. Correlate requests to file-serving endpoints with anomalous status codes, oversized or unexpected Content-Type bodies, and subsequent child-process activity.

• perl process spawning /bin/sh, /bin/bash, cmd.exe, or powershell.exe as a child
• HTTP::Daemon or perl httpd parent with unexpected exec of system utilities (id, whoami, curl, wget, nc)
• web access logs for file-serving routes containing '|' or leading '>' in the path or filename parameter
• HTTP 200 responses for static-file URLs whose body does not match the on-disk asset (possible pipe-stdout leak)
• new or truncated files owned by the HTTP::Daemon/perl daemon UID outside the document root
• auditd/Sysmon Event ID 1 or equivalent: Image=perl with CommandLine containing send_file-related app scripts plus a pipe character
• FIM alerts on application .pl/.pm, config, or crontab files written by the daemon account

What your security team should do

• Patch HTTP::Daemon to 6.17+ everywhere it is installed or vendored; treat this as high priority given CVSS 9.1 and a rising EPSS trend despite no KEV listing.
• Hunt code and SBOMs for send_file( on untrusted input and remove or wrap those call sites even after upgrading.
• Restrict the daemon UID so a successful injection cannot write application code, credentials, or system configuration.
• Add WAF or reverse-proxy allowlists for static-file routes so unexpected path characters never reach the Perl process.
• Monitor for child shells or unexpected file writes from Perl HTTP daemon processes until all instances are upgraded.