EUVD-2026-37201
GHSA-9v83-jvh5-6gh3
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Crafted ACME response yields RCE as the renewal user, so C:H/I:H/A:H; AC:H reflects required CA control or on-path TLS tamper; PR:N/UI:N - no victim creds or interaction.
Primary rating from Vendor (runZero).
CVSS VectorVendor: runZero
Lifecycle Timeline
2DescriptionCVE.org
In ServerCo getssl version 2.49 and prior, the ACME challenge token returned to the client was not strictly validated against RFC 8555 before being used in challenge-file handling, allowing a maliciously crafted token to influence local path/filename usage during validation. An attacker who can supply ACME challenge responses to getssl (for example, a malicious or compromised CA endpoint, or an on-path adversary able to tamper with that response path) could exploit this to achieve unauthorized file write/path traversal effects, usually with elevated privileges, ultimately allowing for remote command injection. This issue appears related in spirit to CVE-2023-38198, and is an instance of CWE-73, "External control of file name or path." Other ACME shell script handlers may be affected by similar issues.
AnalysisAI
Remote command injection in ServerCo getssl 2.49 and prior allows an attacker who controls or tampers with ACME challenge responses (a malicious/compromised CA endpoint or on-path adversary) to write attacker-chosen file paths via tokens that violate RFC 8555 base64url constraints, typically yielding code execution as the privileged user that renews certificates. The issue was reported by runZero, fixed upstream in v2.50, and at the time of analysis there is no public exploit identified and the CVE is not listed in CISA KEV.
Technical ContextAI
getssl is a Bash shell-script ACME client (RFC 8555) used to obtain Let's Encrypt and similar certificates. The vulnerable code path took the ACME challenge token returned by the CA and used it directly in challenge-file path/filename operations without enforcing RFC 8555 §8.3 (base64url alphabet [A-Za-z0-9_-], maximum 255 characters). This is a textbook CWE-73 ('External control of file name or path'): network-supplied data is concatenated into filesystem paths inside a shell script, so a token containing '../', '/', or shell metacharacters such as ';', '`', '$()' or '|' can break out of the intended .well-known/acme-challenge directory and, because the script is shell, also reach command interpretation. The PR #896 fix adds a validate_token function that rejects out-of-alphabet characters and tokens longer than 255 bytes, and additionally applies basename(1) to the token as defense in depth.
RemediationAI
Vendor-released patch: upgrade to getssl v2.50 (https://github.com/srvrco/getssl/releases/tag/v2.50), which lands the validate_token function and basename hardening from PR #896 (https://github.com/srvrco/getssl/pull/896). If upgrading is not immediately possible, reduce the attack surface by pinning getssl to a trusted ACME directory URL over strictly verified TLS (removing the on-path-tamper scenario, at the cost of breaking deployments that rely on intercepting proxies), running getssl as a non-root user whose write scope is confined to the challenge directory (limits file-write-to-RCE pivot but typically requires reworking how renewed certs are deployed), and monitoring for unexpected files appearing outside .well-known/acme-challenge during renewal. There are no in-script configuration toggles that disable the vulnerable path while still allowing certificate issuance, so patching is the correct fix.
Same weakness CWE-73 – External Control of File Name or Path
View allSame technique Path Traversal
View allShare
External POC / Exploit Code
Leaving vuln.today