CVE-2026-40611: 
Wolfi vulnerability analysis and mitigation

CVE-2026-40611 is a path traversal vulnerability in the webroot HTTP-01 challenge provider of Lego, a Let's Encrypt client and ACME library written in Go. A malicious ACME server can supply a crafted challenge token containing ../ sequences, causing Lego to write attacker-influenced content to any path writable by the Lego process, or delete arbitrary files. All versions prior to 4.34.0 are affected. The vulnerability was published on April 21, 2026, and carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory).

The root cause is improper input validation (CWE-22) in the ChallengePath() function in challenge/http01/http_challenge.go, which directly concatenates the ACME token to the challenge path without sanitizing it: return "/.well-known/acme-challenge/" + token. The webroot provider in providers/http/webroot/webroot.go then joins this with the configured webroot directory using filepath.Join() and writes content to the resulting path. Because RFC 8555 Section 8.3 restricts ACME tokens to base64url characters ([A-Za-z0-9_-]) but Lego never enforces this constraint, a malicious server can return a token like ../../../../../../tmp/evil, causing filepath.Join() to resolve outside the webroot. The same unsanitized path is used in the CleanUp() function via os.Remove(), enabling arbitrary file deletion in addition to arbitrary file write (GitHub Advisory).

Successful exploitation allows a malicious ACME server to write attacker-controlled content to any filesystem path writable by the Lego process, or delete arbitrary files via the cleanup code path. Depending on the privileges under which Lego runs, an attacker could achieve remote code execution by writing to cron directories, systemd unit paths, shell profiles, or web application directories; destroy data by overwriting configuration files, TLS certificates, or application state; and if Lego runs as root, gain unrestricted filesystem write access across the entire system (GitHub Advisory).

A proof-of-concept is publicly available in the GitHub Security Advisory, demonstrating the vulnerability both via a minimal Go program calling the webroot provider directly and via a real-world attack scenario using --server to point Lego at a malicious ACME server. Exploitation requires user interaction in the sense that the victim must run Lego against a malicious or compromised ACME server. There is no evidence of in-the-wild exploitation at this time, and the CVE is not listed in the CISA KEV catalog. The EPSS score is 0.046% (GitHub Advisory).

1. Set up a malicious ACME server: The attacker operates or compromises an ACME-compatible server that can return crafted challenge responses, including tokens with path traversal sequences such as ../../../../../../tmp/pwned.
2. Social engineer or redirect the victim: The attacker convinces the victim to run Lego with --server pointing to the malicious ACME server, or performs a network-level redirect (e.g., DNS hijacking, BGP hijacking) to route Lego's ACME requests to the attacker-controlled server.
3. Trigger the HTTP-01 challenge: The victim runs a command such as lego --server https://malicious-acme.example.com --http --http.webroot /var/www/html --email user@example.com --domains example.com run, initiating the certificate issuance flow.
4. Return a crafted token: The malicious ACME server responds to the order with a challenge token containing path traversal sequences (e.g., ../../../../../../etc/cron.d/backdoor).
5. Achieve arbitrary file write: Lego's webroot provider calls filepath.Join(w.path, http01.ChallengePath(token)), resolves the traversal, and writes the key authorization content (attacker-influenced) to the target path outside the webroot.
6. Achieve arbitrary file deletion (optional): After the challenge, Lego's CleanUp() function calls os.Remove() on the same unsanitized path, deleting the targeted file.
7. Achieve code execution or persistence: If the written file is a cron job, shell profile, or web application script, the attacker gains code execution or persistent access on the victim system (GitHub Advisory).

• File System: Unexpected files written outside the configured webroot directory, particularly in sensitive locations such as /etc/cron.d/, /etc/systemd/system/, ~/.bashrc, ~/.profile, or web application directories; unexpected deletion of configuration files, TLS certificates, or application state files.
• Logs: Lego process logs showing certificate issuance attempts against an unfamiliar or external ACME server URL; filesystem audit logs (e.g., auditd) recording writes or deletions by the Lego process to paths outside the webroot.
• Network: Outbound HTTPS connections from the Lego process to unexpected or unknown ACME server endpoints; DNS queries for unfamiliar ACME server hostnames.
• Process: Lego process spawning unexpected child processes (e.g., shells, scripts) following a certificate issuance attempt, which may indicate successful code execution via a written cron job or shell profile (GitHub Advisory).

Upgrade Lego to version 4.34.0 or later, which fixes the vulnerability by validating ACME tokens against the RFC 8555-specified base64url character set before constructing file paths. As a temporary workaround until patching is complete, restrict network access so that Lego can only communicate with trusted, known-good ACME servers (e.g., Let's Encrypt production/staging), and ensure the Lego process runs with the minimum required filesystem permissions to limit the blast radius of any path traversal exploitation (GitHub Advisory).

The vulnerability was reported by security researcher RealHurrison and published by Lego maintainer ldez via a GitHub Security Advisory on April 15, 2026. A Tenable Nessus plugin (ID 309695) was released to detect vulnerable Lego installations. The advisory was noted on Mastodon by @thehackerwire and indexed by multiple vulnerability tracking services shortly after publication (GitHub Advisory, Tenable).