CVE-2026-10303: getssl Path Traversal Vulnerability

CVE-2026-10303 Overview

CVE-2026-10303 affects ServerCo getssl version 2.49 and prior, a shell script that automates TLS certificate issuance through the Automated Certificate Management Environment (ACME) protocol. The script fails to validate ACME challenge tokens against RFC 8555 before using them in challenge-file handling. An attacker who controls or tampers with ACME challenge responses can manipulate local file paths during validation. This enables unauthorized file writes, path traversal, and ultimately remote command injection, typically with elevated privileges. The flaw is categorized as CWE-73: External Control of File Name or Path.

Critical Impact
A malicious or compromised Certificate Authority (CA) endpoint, or an on-path adversary, can achieve remote command injection on systems running getssl versions 2.49 and earlier.

Affected Products

ServerCo getssl version 2.49
ServerCo getssl versions prior to 2.49
Other ACME shell script handlers with similar token-handling patterns may be affected

Discovery Timeline

2026-06-16 - CVE-2026-10303 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-10303

Vulnerability Analysis

The getssl script implements the ACME HTTP-01 challenge flow by writing a token-derived file into a web-accessible directory. RFC 8555 restricts challenge tokens to a base64url character set, but getssl accepts the token returned by the ACME server without enforcing this constraint. When the script uses the unvalidated token to construct file paths or shell commands, attacker-controlled characters break out of the intended context.

This enables path traversal sequences and shell metacharacters to reach privileged file operations. Because certificate renewal frequently runs as root or another privileged user, exploitation yields elevated code execution. The issue mirrors CVE-2023-38198 in the acme.sh ecosystem and reflects a broader pattern across shell-based ACME clients.

Root Cause

The root cause is the absence of input validation on the token field returned by the ACME server. RFC 8555 Section 8.3 specifies that tokens must use the base64url alphabet, but getssl passes the raw value into shell variables used for filename construction and command invocation. This violates CWE-73, external control of file name or path.

Attack Vector

Exploitation requires the attacker to influence ACME challenge responses delivered to the getssl client. This is feasible for an operator of a malicious or compromised ACME endpoint, or an on-path adversary capable of tampering with TLS-protected ACME traffic where certificate pinning is absent. The crafted token contains traversal sequences or shell metacharacters that redirect file writes outside the intended challenge directory or inject commands into subsequent shell expansions. Because getssl typically runs with elevated privileges to manage certificates and restart services, successful exploitation produces high-impact code execution. See the RunZero advisory and the Remy Hax research blog for technical proof-of-concept details.

Detection Methods for CVE-2026-10303

Indicators of Compromise

Unexpected files written outside the configured ACL web-root challenge directory, particularly with names containing .. or shell metacharacters
ACME challenge responses containing characters outside the base64url alphabet (A-Z, a-z, 0-9, -, _)
Anomalous child processes spawned by getssl or its cron job, especially shells, network utilities, or interpreters
Modifications to system files coinciding with scheduled certificate renewal windows

Detection Strategies

Inspect getssl execution logs for non-standard token values returned by ACME servers
Apply file integrity monitoring (FIM) to web-root challenge directories and parent paths writable by the renewal user
Audit cron and systemd timer outputs for getssl invocations producing unexpected stderr or process trees
Compare deployed getssl versions across hosts against the fixed release v2.50

Monitoring Recommendations

Capture process telemetry from hosts running ACME clients and alert on shell child processes under the certificate renewal account
Log outbound HTTPS connections from getssl and validate the destination matches the configured CA directory URL
Forward ACME client logs to a centralized SIEM for correlation with file-write and process-execution events

How to Mitigate CVE-2026-10303

Immediate Actions Required

Upgrade getssl to version 2.50 or later, available from the GitHub Release v2.50
Inventory all hosts running ACME shell-script clients and confirm patched versions are in place
Review getssl configuration files to confirm the renewal account holds the minimum required privileges
Audit recent certificate renewal logs for evidence of malformed tokens or anomalous file writes

Patch Information

The fix is delivered through Pull Request #896 and released in getssl v2.50. The patch enforces RFC 8555 token validation before the value is used in any file path or shell context. Administrators should pull the tagged release and verify the version string after deployment.

Workarounds

Run getssl under a dedicated, non-root user with write access limited to the challenge directory only
Pin the ACME directory URL to a trusted CA and enforce certificate validation on outbound ACME traffic
Apply mandatory access controls such as AppArmor or SELinux profiles restricting getssl file write paths
Where feasible, migrate to ACME clients with stricter input validation until patching completes

bash

# Verify the installed getssl version and upgrade to the patched release
getssl --version
cd /opt/getssl && git fetch --tags && git checkout v2.50