Sep 25, 2026·5 min read·3 visits
An incomplete security fix in compliance-trestle allows path traversal, arbitrary file write, and recursive directory deletion across multiple subcommands by manipulating the output path parameter.
CVE-2026-57171 describes an incomplete fix of CVE-2026-46345 inside compliance-trestle. Sibling subcommands (catalog-generate, profile-generate, ssp-generate, create, and replicate) bypass path validation routines. An attacker can manipulate output parameters to perform arbitrary file writes and directory deletions.
The Python-based Software Development Kit (SDK) and command-line tool compliance-trestle (Trestle) facilitates the management of Open Security Controls Assessment Language (OSCAL) documents. Trestle relies on structured workspace directories to catalog, profile, and track system security plans. While these operations typically target local repository files, the application-level directory boundaries are frequently used as security boundaries within automated pipelines.
During the remediation of a prior path traversal vulnerability (CVE-2026-46345), engineers introduced validation constraints targeting the jinja subcommand. This specific mitigation validated generated outputs through the PathSecurityValidator.validate_local_path() method. However, this defensive check was not systematically applied across sibling commands that share equivalent output mechanisms.
Consequently, several core command-line modules remained vulnerable to input-controlled path traversal. An attacker capable of defining output arguments can direct the execution environment to write files outside the designated workspace. This configuration also allows directory destruction depending on associated flags.
The vulnerability stems from the incomplete implementation of directory validation checks within sibling commands. Commands such as catalog-generate, profile-generate, ssp-generate, create, and replicate historically bypassed the PathSecurityValidator. Instead, they evaluated user-supplied path inputs via is_directory_name_allowed() which was designed to prevent name collision with core OSCAL directories.
This validation check contained two logical flaws. First, if a path starts with a Unix root separator, pathlib.Path(name).parts[0] resolves to the root directory itself. Because the root directory does not exist in the defined restricted directories, the method returns a truthy validation success. Second, path relative traversals (such as subdir/../../) resolve the first element of parts as subdir, which also successfully passes the constraint checks.
Once authorized, the path joining logic invokes Python's standard pathlib division operator. If the configured path argument is absolute, Python discards the preceding workspace root variable entirely. If the input contains relative directory traversals, the resolved output directory escapes the workspace bounds. Additionally, when a user specifies the --force-overwrite option, the program calls clear_folder(), which recursively deletes the target path before writing files.
The vulnerable code in trestle/common/file_utils.py checked output folders using basic slicing of uncanonicalized path components. It failed to check for absolute paths or relative dot-dot sequences.
# Vulnerable Implementation
def is_directory_name_allowed(name: str) -> bool:
pathed_name = pathlib.Path(name)
root_path = pathed_name.parts[0]
if root_path in const.MODEL_TYPE_TO_MODEL_DIR.values():
logger.warning('Task name is the same as an OSCAL schema name.')
return FalseThe patch addresses this gap by introducing explicit validation checks for both absolute paths and the presence of .. segments inside the file_utils.py validation logic. It also updates the vulnerable command files to call PathSecurityValidator.validate_local_path immediately after constructing the output path.
# Patched Implementation in trestle/common/file_utils.py
def is_directory_name_allowed(name: str) -> bool:
pathed_name = pathlib.Path(name)
# Reject absolute paths explicitly
if pathed_name.is_absolute() or name.startswith('/'):
logger.warning('Task name must not be an absolute path')
return False
# Reject traversal sequences
if '..' in pathed_name.parts:
logger.warning('Task name must not contain ".." path traversal sequences')
return False
root_path = pathed_name.parts[0]
if root_path in const.MODEL_TYPE_TO_MODEL_DIR.values():
logger.warning('Task name is the same as an OSCAL schema name.')
return FalseAdditionally, all affected CLI subcommands (e.g., trestle/core/commands/author/catalog.py) were patched to enforce path boundaries:
# Added check in affected commands
markdown_path = trestle_root / args.output
PathSecurityValidator.validate_local_path(markdown_path, trestle_root)Exploitation requires an execution context where the output file path parameter (-o or --output) is influenced by an untrusted source. This scenario is common in shared, multi-tenant build environments, CI/CD pipelines, or automation scripts that parse user-provided metadata or pull request properties.
An attacker can structure an exploit payload using standard relative path sequences or absolute system paths. When the Trestle utility parses the input argument, it performs the directory validation steps on the uncanonicalized input. The command then executes, leading to directory deletion (if forced) and file placement outside the workspace.
This path-resolution mechanism permits an attacker to targeting sensitive directories on the execution runner, such as /etc/cron.d or /var/www. If the execution runner possesses high privileges, this can lead to system-wide compromise or denial of service.
The impact of CVE-2026-57171 affects system integrity and availability. An attacker can write arbitrary compliance schema files to sensitive operating system paths, potentially overwriting system libraries or configurations.
If the runner process operates with elevated privileges, this primitive enables local privilege escalation. For example, writing arbitrary files to /etc/cron.d or active system service folders allows execution of arbitrary commands. This risk is highly relevant in multi-tenant environments where a single pipeline runs validation workflows on behalf of multiple untrusted repository contributors.
The inclusion of folder clearing logic (clear_folder) also introduces a high-impact availability risk. By pointing the output directory to system-critical paths with force flags active, an attacker can delete directories, resulting in permanent damage to execution environments or build runners.
Remediation requires upgrading the compliance-trestle installation to a safe release version. The patch has been backported to both the 3.x and 4.x branches. Workspaces should transition to 3.12.4 (for v3 deployments) or 4.1.0 (for v4 deployments).
If immediate upgrading is not possible, execution environments must implement input filtering on CLI commands. Ensure that parameters parsed from untrusted inputs are checked for traversal patterns (..) or absolute directories.
Security teams can deploy Semgrep rules to detect instances of unvalidated input patterns in their automation pipelines. Systems can also audit command logs to intercept suspicious traversal patterns targeting Trestle execution targets.
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H| Product | Affected Versions | Fixed Version |
|---|---|---|
compliance-trestle IBM / OSCAL Compass | < 3.12.4 | 3.12.4 |
compliance-trestle IBM / OSCAL Compass | >= 4.0.0, <= 4.0.3 | 4.1.0 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-22 |
| Attack Vector | Local |
| CVSS Severity Score | 7.7 |
| EPSS Score | 0.00211 |
| Exploit Status | poc |
| CISA KEV Status | Not Listed |
The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as '..' or absolute paths that can resolve to locations outside of the restricted directory.
Compliance-trestle is vulnerable to Server-Side Template Injection (SSTI) leading to arbitrary code execution due to an incomplete fix for CVE-2026-46439. While the original remediation removed recursive template rendering in the core system, custom include extensions ('mdsection_include' and 'md_clean_include') continued to compile and parse files via a standard, non-sandboxed Jinja2 environment. This allows attackers who can inject template expressions into OSCAL documents or markdown files to execute arbitrary python code when the custom template processing is executed. The issue has been patched in versions 4.1.0 and 3.12.4.
A parameter injection vulnerability exists in the Ash framework for Elixir, where untrusted string-keyed maps can bypass the 'public?: false' restriction on action arguments. An attacker can leverage this bypass to inject and overwrite private arguments, resulting in unauthorized data modification or privilege escalation depending on the target application's design.
An improper authentication vulnerability (CWE-287) exists in the SAML backend of the social-auth-core package before version 5.0.0. The Assertion Consumer Service (ACS) endpoint does not verify whether incoming SAML assertions match a previously initiated AuthnRequest in the user's session. This permits an attacker with credentials on a shared Identity Provider to perform a 'Session Donor' attack, permanently linking their SAML identity to an authenticated victim's account and achieving full, persistent account takeover.
An identity binding collision vulnerability in the Vend OAuth2 backend of python-social-auth (social-core) before version 5.0.0 allows unauthenticated remote attackers to take over local accounts in multi-tenant configurations. The flaw stems from relying on shop-local numeric user IDs as global social-auth identifiers, leading to collisions when identical IDs exist across distinct tenants.
A Login Cross-Site Request Forgery (Login CSRF) vulnerability was discovered in the social-auth-core library prior to version 5.0.0 when utilizing the LoginRadius authentication backend. The backend explicitly disabled state token validation during the authentication callback, allowing attackers to link their identities to victim sessions.
An authentication bypass vulnerability exists in the VKontakte App backend of social-auth-core prior to version 5.0.0. The vulnerability allows remote attackers to bypass cryptographic signature verification and gain unauthorized access to arbitrary accounts by omitting the signature parameter.