Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

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

4719 vulnerabilities reference this CWE, most recent first.

GHSA-M5HX-V4QV-JWGH

Vulnerability from github – Published: 2026-01-22 18:30 – Updated: 2026-01-28 18:30
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in WP Messiah Frontis Blocks frontis-blocks allows Server Side Request Forgery.This issue affects Frontis Blocks: from n/a through <= 1.1.5.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-68030"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T17:16:08Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in WP Messiah Frontis Blocks frontis-blocks allows Server Side Request Forgery.This issue affects Frontis Blocks: from n/a through \u003c= 1.1.5.",
  "id": "GHSA-m5hx-v4qv-jwgh",
  "modified": "2026-01-28T18:30:42Z",
  "published": "2026-01-22T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68030"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/frontis-blocks/vulnerability/wordpress-frontis-blocks-plugin-1-1-5-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M5MQ-QMXJ-JM78

Vulnerability from github – Published: 2025-12-01 06:30 – Updated: 2025-12-01 06:30
VLAI
Details

A vulnerability has been found in orionsec orion-ops up to 5925824997a3109651bbde07460958a7be249ed1. Affected by this issue is some unknown functionality of the file orion-ops-api/orion-ops-web/src/main/java/cn/orionsec/ops/controller/MachineInfoController.java of the component SSH Connection Handler. Such manipulation of the argument host/sshPort/username/password/authType leads to server-side request forgery. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. A patch should be applied to remediate this issue. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-13809"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-01T06:15:58Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been found in orionsec orion-ops up to 5925824997a3109651bbde07460958a7be249ed1. Affected by this issue is some unknown functionality of the file orion-ops-api/orion-ops-web/src/main/java/cn/orionsec/ops/controller/MachineInfoController.java of the component SSH Connection Handler. Such manipulation of the argument host/sshPort/username/password/authType leads to server-side request forgery. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. A patch should be applied to remediate this issue. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-m5mq-qmxj-jm78",
  "modified": "2025-12-01T06:30:25Z",
  "published": "2025-12-01T06:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13809"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Xzzz111/exps/blob/main/archives/orion-ops-ssrf-1/report.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Xzzz111/exps/blob/main/archives/orion-ops-ssrf-1/report.md#proof-of-concept"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.333819"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.333819"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.692069"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-M5R2-8P9X-HP5M

Vulnerability from github – Published: 2026-02-09 20:35 – Updated: 2026-02-09 22:38
VLAI
Summary
Craft CMS Vulnerable to SSRF in GraphQL Asset Mutation via Alternative IP Notation
Details

I observed a recent commit intended to mitigate Server-Side Request Forgery (SSRF) vulnerabilities. While the implemented defense mechanisms are an improvement, I have identified two methods to bypass these protections. This report details the first bypass method involving alternative IP notation, while the second method will be submitted in a separate advisory.


Summary

The saveAsset GraphQL mutation uses filter_var(..., FILTER_VALIDATE_IP) to block a specific list of IP addresses. However, alternative IP notations (hexadecimal, mixed) are not recognized by this function, allowing attackers to bypass the blocklist and access cloud metadata services.


Proof of Concept

  1. Send the following GraphQL mutation:
mutation {
    save_images_Asset(_file: { 
        url: "http://169.254.0xa9fe/latest/meta-data/"
        filename: "metadata.txt"
    }) {
        id
    }
}
  1. The IP validation passes (hex notation not recognized as IP)
  2. Guzzle resolves 169.254.0xa9fe to 169.254.169.254
  3. Cloud metadata is fetched and saved

Alternative Payloads

Payload Notation Resolves To
http://169.254.0xa9fe/ Mixed (decimal + hex) 169.254.169.254
http://0xa9.0xfe.0xa9.0xfe/ Full hex dotted 169.254.169.254
http://0xa9fea9fe/ Single hex integer 169.254.169.254

Technical Details

File: src/gql/resolvers/mutations/Asset.php Root Cause: filter_var($hostname, FILTER_VALIDATE_IP) only recognizes standard dotted-decimal notation. Hex representations bypass this check, but Guzzle still resolves them.

// Line 287 - Fails to catch hex notation
filter_var($hostname, FILTER_VALIDATE_IP)
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.8.21"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-RC1"
            },
            {
              "fixed": "5.8.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.16.17"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-RC1"
            },
            {
              "fixed": "4.16.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25494"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-09T20:35:35Z",
    "nvd_published_at": "2026-02-09T20:15:57Z",
    "severity": "MODERATE"
  },
  "details": "I observed a [recent commit](https://github.com/craftcms/cms/commit/9d9b46a9e40cbdfb20d0d933abb546be12ccd3af) intended to mitigate Server-Side Request Forgery (SSRF) vulnerabilities. While the implemented defense mechanisms are an improvement, I have identified two methods to bypass these protections. This report details the first bypass method involving alternative IP notation, while the second method will be submitted in a separate advisory.\n\n---\n## Summary\n\nThe `saveAsset` GraphQL mutation uses `filter_var(..., FILTER_VALIDATE_IP)` to block a specific list of IP addresses. However, alternative IP notations (hexadecimal, mixed) are not recognized by this function, allowing attackers to bypass the blocklist and access cloud metadata services.\n\n---\n## Proof of Concept\n1. Send the following GraphQL mutation:\n```graphql\nmutation {\n    save_images_Asset(_file: { \n        url: \"http://169.254.0xa9fe/latest/meta-data/\"\n        filename: \"metadata.txt\"\n    }) {\n        id\n    }\n}\n```\n2. The IP validation passes (hex notation not recognized as IP)\n3. Guzzle resolves `169.254.0xa9fe` to `169.254.169.254`\n4. Cloud metadata is fetched and saved\n\n### Alternative Payloads\n| Payload | Notation | Resolves To |\n|---------|----------|-------------|\n| `http://169.254.0xa9fe/` | Mixed (decimal + hex) | 169.254.169.254 |\n| `http://0xa9.0xfe.0xa9.0xfe/` | Full hex dotted | 169.254.169.254 |\n| `http://0xa9fea9fe/` | Single hex integer | 169.254.169.254 |\n\n---\n## Technical Details\n\n**File:** `src/gql/resolvers/mutations/Asset.php`\n**Root Cause:** `filter_var($hostname, FILTER_VALIDATE_IP)` only recognizes standard dotted-decimal notation. Hex representations bypass this check, but Guzzle still resolves them.\n\n```php\n// Line 287 - Fails to catch hex notation\nfilter_var($hostname, FILTER_VALIDATE_IP)\n```",
  "id": "GHSA-m5r2-8p9x-hp5m",
  "modified": "2026-02-09T22:38:00Z",
  "published": "2026-02-09T20:35:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-m5r2-8p9x-hp5m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25494"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/commit/d49e93e5ba0c48939ce5eaa6cd9b4a990542d8b2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/craftcms/cms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/releases/tag/4.16.18"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/releases/tag/5.8.22"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Craft CMS Vulnerable to SSRF in GraphQL Asset Mutation via Alternative IP Notation"
}

GHSA-M5X5-28JR-GPJJ

Vulnerability from github – Published: 2026-07-09 13:35 – Updated: 2026-07-09 13:35
VLAI
Summary
pyLoad: SSRF guard bypass via IPv6 6to4/NAT64 transition wrappers of internal IPs
Details

Summary

is_global_address in src/pyload/core/utils/web/check.py is the central guard against SSRF-style outbound connections in pyload-ng. It tests whether a given IP is "globally routable" via Python's ipaddress.ip_address(value).is_global, and callers treat not is_global as "deny":

def is_global_address(value):
    try:
        return ipaddress.ip_address(value).is_global
    except ValueError:
        return False

def is_global_host(value):
    ips = host_to_ip(value)
    return ips and all((is_global_address(ip) for ip in ips))

Python's ipaddress.IPv6Address.is_global classifies the NAT64 well-known prefix as globally routable on every supported Python version (3.9 through 3.14 confirmed), and on older Pythons (3.9-3.11) the 6to4 prefix as well:

address is_global on Py 3.9-3.11 is_global on Py 3.12+ wrapped IPv4
2002:7f00:0001:: (6to4) True False 127.0.0.1
2002:0a00:0001:: (6to4) True False 10.0.0.1
2002:a9fe:a9fe:: (6to4) True False 169.254.169.254 (IMDS)
64:ff9b::a9fe:a9fe (NAT64) True True 169.254.169.254
64:ff9b::7f00:1 (NAT64) True True 127.0.0.1

pyload-ng declares python_requires = >=3.9 (setup.cfg), so deployments on Python 3.9-3.11 see the 6to4 path too. The NAT64 path is universal. is_global returns True for these wrappers, so is_global_address returns True and the deny check passes. The pycurl PREREQFUNC at src/pyload/core/network/http/http_request.py:680 consults the same helper just before TCP-connect:

if not self.allow_private_ip:
    is_proxy_ip = self.http_proxy_host and self.http_proxy_host == (conn_primary_ip, conn_primary_port)
    if not is_global_address(conn_primary_ip) and not is_proxy_ip:
        return pycurl.PREREQFUNC_ABORT
return pycurl.PREREQFUNC_OK

On a host with 6to4 routing (legacy operator tunnels; 2002::/16 still configurable) or NAT64 (cloud IPv6-only subnets with NAT64 gateway), the encoded form routes to the embedded IPv4 and the curl connection terminates at the internal endpoint, defeating the deny.

is_global_host (the helper that callers like parse_urls use against a URL hostname) feeds through host_to_ip which pins family=AF_INET, so hostname-based reach to these forms relies on the attacker supplying an IPv6 literal in the URL — but the curl PREREQFUNC sees the actual resolved IP (the AAAA returned for the hostname), so a hostname with an AAAA record set to one of the bypass forms reaches the same gap.

Cross-reference: this is the same incomplete-coverage class as pydantic-ai's GHSA-cqp8-fcvh-x7r3 / CVE-2026-46678. pyload-ng's prior SSRF advisories GHSA-7gvf-3w72-p2pg and GHSA-8rp3-xc6w-5qp5 both went through is_global_host / is_global_address; the IPv6 transition gap is orthogonal to those redirect-bypass classes.

Severity

MEDIUMCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:L = 4.7

  • AC:H — exploitation requires the host network to route 6to4 (2002::/16 traffic), have a NAT64 gateway, or otherwise resolve the IPv6 transition form to an internal IPv4 endpoint at the TCP layer.
  • PR:Lparse_urls (src/pyload/core/api/__init__.py:582) requires Perms.ADD, which any account capable of adding links holds. The curl PREREQFUNC at http_request.py:680 is reached by every downloader plugin that runs after is_global_host passed.
  • C:L/A:L — internal-network recon and timing-based confirmation; cloud-metadata exfiltration on networks where the transition form actually routes.

CWE-918: Server-Side Request Forgery (SSRF).

Affected versions

pyload-ng from the introduction of is_global_address / is_global_host in src/pyload/core/utils/web/check.py up to and including the current main HEAD as of filing.

Vulnerable code

src/pyload/core/utils/web/check.py:

def is_global_address(value):
    try:
        return ipaddress.ip_address(value).is_global
    except ValueError:
        return False

Python ipaddress.IPv6Address.is_global returns True for every address in 2002::/16 (6to4) and 64:ff9b::/96 (NAT64) regardless of the IPv4 they wrap, so this guard is a one-line bypass for the prefix the attacker chooses.

Reproduction

research_wave5/poc/pyload_ipv6_ssrf/poc.py drives both is_global_address and is_global_host against IPv6 transition forms whose embedded IPv4 points at loopback, RFC 1918, and AWS IMDS. The helper returns "globally routable" for every form. A second pass replays the same forms through the PREREQFUNC logic in http_request.py:680 and shows the connection would be ALLOWED in each case.

Suggested fix

Treat IPv6 transition-encoding forms by unwrapping the embedded IPv4 and re-running the global check, plus an explicit blocklist of well-known embedding prefixes for defence in depth:

import ipaddress

_NAT64_WELL_KNOWN = ipaddress.IPv6Network("64:ff9b::/96")
_NAT64_DISCOVERY = ipaddress.IPv6Network("64:ff9b:1::/48")


def _embedded_ipv4(addr):
    if isinstance(addr, ipaddress.IPv6Address):
        if addr.ipv4_mapped is not None:
            return addr.ipv4_mapped
        if addr.sixtofour is not None:  # 2002::/16 6to4
            return addr.sixtofour
        if addr in _NAT64_WELL_KNOWN or addr in _NAT64_DISCOVERY:
            return ipaddress.IPv4Address(addr.packed[-4:])
    return None


def is_global_address(value):
    try:
        addr = ipaddress.ip_address(value)
    except ValueError:
        return False
    embedded = _embedded_ipv4(addr)
    if embedded is not None:
        addr = embedded
    return addr.is_global

A patch implementing this approach (plus tests covering 6to4 and NAT64 wraps for 127.0.0.1, 10.0.0.1, 172.16.0.1, 192.168.1.1, 100.64.0.0/10, and 169.254.169.254) accompanies the fix PR.

Credits

Reported by tonghuaroot.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pyload-ng"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.5.0b3.dev100"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48737"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T13:35:22Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`is_global_address` in [`src/pyload/core/utils/web/check.py`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/utils/web/check.py) is the central guard against SSRF-style outbound connections in pyload-ng. It tests whether a given IP is \"globally routable\" via Python\u0027s `ipaddress.ip_address(value).is_global`, and callers treat `not is_global` as \"deny\":\n\n```python\ndef is_global_address(value):\n    try:\n        return ipaddress.ip_address(value).is_global\n    except ValueError:\n        return False\n\ndef is_global_host(value):\n    ips = host_to_ip(value)\n    return ips and all((is_global_address(ip) for ip in ips))\n```\n\nPython\u0027s `ipaddress.IPv6Address.is_global` classifies the NAT64 well-known prefix as **globally routable** on every supported Python version (3.9 through 3.14 confirmed), and on older Pythons (3.9-3.11) the 6to4 prefix as well:\n\n| address                          | `is_global` on Py 3.9-3.11 | `is_global` on Py 3.12+ | wrapped IPv4         |\n|----------------------------------|---------------------------|--------------------------|----------------------|\n| `2002:7f00:0001::` (6to4)        | True                      | False                    | 127.0.0.1            |\n| `2002:0a00:0001::` (6to4)        | True                      | False                    | 10.0.0.1             |\n| `2002:a9fe:a9fe::` (6to4)        | True                      | False                    | 169.254.169.254 (IMDS)|\n| `64:ff9b::a9fe:a9fe` (NAT64)     | True                      | True                     | 169.254.169.254      |\n| `64:ff9b::7f00:1` (NAT64)        | True                      | True                     | 127.0.0.1            |\n\npyload-ng declares `python_requires = \u003e=3.9` (`setup.cfg`), so deployments on Python 3.9-3.11 see the 6to4 path too. The NAT64 path is universal. `is_global` returns True for these wrappers, so `is_global_address` returns True and the deny check passes. The pycurl `PREREQFUNC` at [`src/pyload/core/network/http/http_request.py:680`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/network/http/http_request.py#L680) consults the same helper just before TCP-connect:\n\n```python\nif not self.allow_private_ip:\n    is_proxy_ip = self.http_proxy_host and self.http_proxy_host == (conn_primary_ip, conn_primary_port)\n    if not is_global_address(conn_primary_ip) and not is_proxy_ip:\n        return pycurl.PREREQFUNC_ABORT\nreturn pycurl.PREREQFUNC_OK\n```\n\nOn a host with 6to4 routing (legacy operator tunnels; `2002::/16` still configurable) or NAT64 (cloud IPv6-only subnets with NAT64 gateway), the encoded form routes to the embedded IPv4 and the curl connection terminates at the internal endpoint, defeating the deny.\n\n`is_global_host` (the helper that callers like `parse_urls` use against a URL hostname) feeds through `host_to_ip` which pins `family=AF_INET`, so hostname-based reach to these forms relies on the attacker supplying an IPv6 literal in the URL \u2014 but the curl PREREQFUNC sees the actual resolved IP (the AAAA returned for the hostname), so a hostname with an AAAA record set to one of the bypass forms reaches the same gap.\n\nCross-reference: this is the same incomplete-coverage class as pydantic-ai\u0027s [GHSA-cqp8-fcvh-x7r3](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-cqp8-fcvh-x7r3) / CVE-2026-46678. pyload-ng\u0027s prior SSRF advisories [GHSA-7gvf-3w72-p2pg](https://github.com/pyload/pyload/security/advisories/GHSA-7gvf-3w72-p2pg) and [GHSA-8rp3-xc6w-5qp5](https://github.com/pyload/pyload/security/advisories/GHSA-8rp3-xc6w-5qp5) both went through `is_global_host` / `is_global_address`; the IPv6 transition gap is orthogonal to those redirect-bypass classes.\n\n## Severity\n\n**MEDIUM** \u2014 `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:L` = **4.7**\n\n- `AC:H` \u2014 exploitation requires the host network to route 6to4 (`2002::/16` traffic), have a NAT64 gateway, or otherwise resolve the IPv6 transition form to an internal IPv4 endpoint at the TCP layer.\n- `PR:L` \u2014 `parse_urls` ([`src/pyload/core/api/__init__.py:582`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/api/__init__.py#L582)) requires `Perms.ADD`, which any account capable of adding links holds. The curl PREREQFUNC at [`http_request.py:680`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/http_request.py#L680) is reached by every downloader plugin that runs after `is_global_host` passed.\n- `C:L/A:L` \u2014 internal-network recon and timing-based confirmation; cloud-metadata exfiltration on networks where the transition form actually routes.\n\n**CWE-918**: Server-Side Request Forgery (SSRF).\n\n## Affected versions\n\n`pyload-ng` from the introduction of `is_global_address` / `is_global_host` in [`src/pyload/core/utils/web/check.py`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/utils/web/check.py) up to and including the current main HEAD as of filing.\n\n## Vulnerable code\n\n[`src/pyload/core/utils/web/check.py`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/utils/web/check.py):\n\n```python\ndef is_global_address(value):\n    try:\n        return ipaddress.ip_address(value).is_global\n    except ValueError:\n        return False\n```\n\n`Python ipaddress.IPv6Address.is_global` returns True for every address in `2002::/16` (6to4) and `64:ff9b::/96` (NAT64) regardless of the IPv4 they wrap, so this guard is a one-line bypass for the prefix the attacker chooses.\n\n## Reproduction\n\n[`research_wave5/poc/pyload_ipv6_ssrf/poc.py`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/research_wave5/poc/pyload_ipv6_ssrf/poc.py) drives both `is_global_address` and `is_global_host` against IPv6 transition forms whose embedded IPv4 points at loopback, RFC 1918, and AWS IMDS. The helper returns \"globally routable\" for every form. A second pass replays the same forms through the `PREREQFUNC` logic in [`http_request.py:680`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/http_request.py#L680) and shows the connection would be ALLOWED in each case.\n\n## Suggested fix\n\nTreat IPv6 transition-encoding forms by unwrapping the embedded IPv4 and re-running the global check, plus an explicit blocklist of well-known embedding prefixes for defence in depth:\n\n```python\nimport ipaddress\n\n_NAT64_WELL_KNOWN = ipaddress.IPv6Network(\"64:ff9b::/96\")\n_NAT64_DISCOVERY = ipaddress.IPv6Network(\"64:ff9b:1::/48\")\n\n\ndef _embedded_ipv4(addr):\n    if isinstance(addr, ipaddress.IPv6Address):\n        if addr.ipv4_mapped is not None:\n            return addr.ipv4_mapped\n        if addr.sixtofour is not None:  # 2002::/16 6to4\n            return addr.sixtofour\n        if addr in _NAT64_WELL_KNOWN or addr in _NAT64_DISCOVERY:\n            return ipaddress.IPv4Address(addr.packed[-4:])\n    return None\n\n\ndef is_global_address(value):\n    try:\n        addr = ipaddress.ip_address(value)\n    except ValueError:\n        return False\n    embedded = _embedded_ipv4(addr)\n    if embedded is not None:\n        addr = embedded\n    return addr.is_global\n```\n\nA patch implementing this approach (plus tests covering 6to4 and NAT64 wraps for 127.0.0.1, 10.0.0.1, 172.16.0.1, 192.168.1.1, 100.64.0.0/10, and 169.254.169.254) accompanies the fix PR.\n\n## Credits\n\nReported by tonghuaroot.",
  "id": "GHSA-m5x5-28jr-gpjj",
  "modified": "2026-07-09T13:35:22Z",
  "published": "2026-07-09T13:35:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pyload/pyload/security/advisories/GHSA-m5x5-28jr-gpjj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pyload/pyload"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pyLoad: SSRF guard bypass via IPv6 6to4/NAT64 transition wrappers of internal IPs"
}

GHSA-M5XF-X7Q6-3RM7

Vulnerability from github – Published: 2022-11-18 17:14 – Updated: 2023-08-29 22:52
VLAI
Summary
KubeVela VelaUX APIserver has SSRF vulnerability
Details

Impact

Users using the VelaUX APIServer could be affected by this vulnerability.

When using Helm Chart as the component delivery method, the request address of the warehouse is not restricted, and there is a blind SSRF vulnerability.

This issue is patched in 1.5.9 and 1.6.2.

References

Fix by: #5000

For more information

If you have any questions or comments about this advisory: * Open an issue in KubeVela repo * Email us at here

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oam-dev/kubevela"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0-alpha.1"
            },
            {
              "fixed": "1.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oam-dev/kubevela"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-39383"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-18T17:14:39Z",
    "nvd_published_at": "2022-11-16T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nUsers using the VelaUX APIServer could be affected by this vulnerability.\n\nWhen using Helm Chart as the component delivery method, the request address of the warehouse is not restricted, and there is a blind SSRF vulnerability.\n\nThis issue is patched in 1.5.9 and 1.6.2.\n\n### References\nFix by: #5000 \n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [KubeVela repo](https://github.com/kubevela/kubevela)\n* Email us at [here](https://github.com/kubevela/kubevela#contact-us)\n",
  "id": "GHSA-m5xf-x7q6-3rm7",
  "modified": "2023-08-29T22:52:24Z",
  "published": "2022-11-18T17:14:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kubevela/kubevela/security/advisories/GHSA-m5xf-x7q6-3rm7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39383"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubevela/kubevela/pull/5000"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubevela/kubevela"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2022-1113"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "KubeVela VelaUX APIserver has SSRF vulnerability "
}

GHSA-M62C-4M95-XPCR

Vulnerability from github – Published: 2024-09-23 21:30 – Updated: 2024-09-30 15:30
VLAI
Details

New Cloud MyOffice SDK Collaborative Editing Server 2.2.2 through 2.8 allows SSRF via manipulation of requests from external document storage via the MS-WOPI protocol.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-47222"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-23T20:15:05Z",
    "severity": "CRITICAL"
  },
  "details": "New Cloud MyOffice SDK Collaborative Editing Server 2.2.2 through 2.8 allows SSRF via manipulation of requests from external document storage via the MS-WOPI protocol.",
  "id": "GHSA-m62c-4m95-xpcr",
  "modified": "2024-09-30T15:30:44Z",
  "published": "2024-09-23T21:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47222"
    },
    {
      "type": "WEB",
      "url": "https://myoffice.ru"
    },
    {
      "type": "WEB",
      "url": "https://support.myoffice.ru/products/myoffice-sdk"
    }
  ],
  "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-M62F-JRRH-2Q4V

Vulnerability from github – Published: 2025-02-11 12:30 – Updated: 2025-02-11 15:32
VLAI
Details

A vulnerability has been identified in Opcenter Intelligence (All versions < V2501). Server-side request forgery (SSRF) vulnerability in Tableau Server. For details go to help.salesforce.com and search for knowledge article id 001534936.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-26491"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-11T11:15:17Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in Opcenter Intelligence (All versions \u003c V2501). Server-side request forgery (SSRF) vulnerability in Tableau Server. For details go to help.salesforce.com and search for knowledge article id 001534936.",
  "id": "GHSA-m62f-jrrh-2q4v",
  "modified": "2025-02-11T15:32:24Z",
  "published": "2025-02-11T12:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26491"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-246355.html"
    },
    {
      "type": "WEB",
      "url": "https://help.salesforce.com/s/articleView?id=001534936\u0026type=1"
    }
  ],
  "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"
    }
  ]
}

GHSA-M639-8G2X-JQ6F

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

Server-Side Request Forgery (SSRF) vulnerability in Gift Up! Gift Up Gift Cards for WordPress and WooCommerce gift-up allows Server Side Request Forgery.This issue affects Gift Up Gift Cards for WordPress and WooCommerce: from n/a through <= 3.1.7.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-32412"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-13T19:54:58Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Gift Up! Gift Up Gift Cards for WordPress and WooCommerce gift-up allows Server Side Request Forgery.This issue affects Gift Up Gift Cards for WordPress and WooCommerce: from n/a through \u003c= 3.1.7.",
  "id": "GHSA-m639-8g2x-jq6f",
  "modified": "2026-03-13T21:31:49Z",
  "published": "2026-03-13T21:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32412"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/gift-up/vulnerability/wordpress-gift-up-gift-cards-for-wordpress-and-woocommerce-plugin-3-1-7-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M686-8XW7-XQG8

Vulnerability from github – Published: 2026-04-12 06:30 – Updated: 2026-04-12 06:30
VLAI
Details

A vulnerability was identified in AstrBotDevs AstrBot up to 4.22.1. The affected element is the function post_data.get of the component API Endpoint. Such manipulation leads to server-side request forgery. The attack may be performed from remote. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-6119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-12T06:16:21Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was identified in AstrBotDevs AstrBot up to 4.22.1. The affected element is the function post_data.get of the component API Endpoint. Such manipulation leads to server-side request forgery. The attack may be performed from remote. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-m686-8xw7-xqg8",
  "modified": "2026-04-12T06:30:27Z",
  "published": "2026-04-12T06:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6119"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AstrBotDevs/AstrBot/issues/7171"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AstrBotDevs/AstrBot"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/792661"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/356979"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/356979/cti"
    }
  ],
  "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-M6JJ-V4VV-F2HJ

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

JetBrains YouTrack before 2020.3.888 was vulnerable to SSRF.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-27624"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-16T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "JetBrains YouTrack before 2020.3.888 was vulnerable to SSRF.",
  "id": "GHSA-m6jj-v4vv-f2hj",
  "modified": "2022-05-24T17:34:17Z",
  "published": "2022-05-24T17:34:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27624"
    },
    {
      "type": "WEB",
      "url": "https://blog.jetbrains.com"
    },
    {
      "type": "WEB",
      "url": "https://blog.jetbrains.com/2020/11/16/jetbrains-security-bulletin-q3-2020"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

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.