Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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

4755 vulnerabilities reference this CWE, most recent first.

GHSA-F49C-C866-MJCW

Vulnerability from github – Published: 2025-12-24 15:30 – Updated: 2026-04-23 18:32
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in bdthemes Prime Slider – Addons For Elementor bdthemes-prime-slider-lite allows Server Side Request Forgery.This issue affects Prime Slider – Addons For Elementor: from n/a through <= 4.0.10.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-68500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-24T13:16:20Z",
    "severity": "CRITICAL"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in bdthemes Prime Slider \u2013 Addons For Elementor bdthemes-prime-slider-lite allows Server Side Request Forgery.This issue affects Prime Slider \u2013 Addons For Elementor: from n/a through \u003c= 4.0.10.",
  "id": "GHSA-f49c-c866-mjcw",
  "modified": "2026-04-23T18:32:01Z",
  "published": "2025-12-24T15:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68500"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/bdthemes-prime-slider-lite/vulnerability/wordpress-prime-slider-addons-for-elementor-plugin-4-0-10-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/bdthemes-prime-slider-lite/vulnerability/wordpress-prime-slider-addons-for-elementor-plugin-4-0-10-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:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F4GW-2P7V-4548

Vulnerability from github – Published: 2026-07-20 22:20 – Updated: 2026-07-20 22:20
VLAI
Summary
Axios: NO_PROXY bypass for 0.0.0.0 local addresses in axios
Details

Summary

Axios versions containing lib/helpers/shouldBypassProxy.js do not treat 0.0.0.0 as a local address when evaluating NO_PROXY rules. In Node.js applications that use HTTP_PROXY or HTTPS_PROXY together with NO_PROXY=localhost,127.0.0.1,::1 or similar, a request to http://0.0.0.0:<port>/ can be routed through the configured proxy instead of bypassing it.

The issue is exploitable when an attacker can influence the axios request URL or a followed redirect target, and when the proxy can reach or relay 0.0.0.0 to local services. This is a Node.js runtime proxy-routing issue, not a browser, install-time, or development-tooling issue.

Impact

Applications are affected when all of the following are true:

  • The application runs axios in Node.js with the HTTP adapter.
  • The process uses environment proxy variables such as HTTP_PROXY or HTTPS_PROXY.
  • The process uses NO_PROXY entries such as localhost, 127.0.0.1, or ::1 to keep local traffic out of the proxy path.
  • Attacker-controlled input can influence the request URL or redirect target.
  • The configured proxy does not reject 0.0.0.0 and can reach the local destination.

For plain HTTP targets, the proxy can receive the full request URL, headers, and body, and may be able to observe the local service response. HTTPS targets are less exposed because axios uses CONNECT tunneling in current versions.

Affected Functionality

Affected functionality is limited to environment-derived proxy selection in the Node HTTP adapter:

  • lib/adapters/http.js calls getProxyForUrl(location) and then shouldBypassProxy(location) before applying the proxy.
  • lib/helpers/shouldBypassProxy.js normalizes and compares NO_PROXY entries.
  • Explicit caller-provided config.proxy remains trusted caller configuration.
  • Browser, React Native, XHR, and fetch adapter behavior are not affected.

Technical Details

lib/helpers/shouldBypassProxy.js defines local loopback equivalence through isLoopback(). The current implementation recognizes localhost, IPv4 127.0.0.0/8, IPv6 ::1, and IPv4-mapped loopback forms, but it does not include 0.0.0.0.

At lib/helpers/shouldBypassProxy.js:176, axios treats two hosts as matching when both are considered loopback:

return hostname === entryHost || (isLoopback(hostname) && isLoopback(entryHost));

Because isLoopback('0.0.0.0') returns false, NO_PROXY=localhost,127.0.0.1,::1 does not match http://0.0.0.0:<port>/. lib/adapters/http.js:185-193 then applies the environment proxy.

Proof of Concept of Attack

import http from 'http';
import axios from './index.js';

const listen = (handler, host = '127.0.0.1') =>
  new Promise((resolve) => {
    const server = http.createServer(handler);
    server.listen(0, host, () => resolve(server));
  });

const close = (server) => new Promise((resolve) => server.close(resolve));

const origin = await listen((req, res) => res.end('origin'), '0.0.0.0');

let proxyRequests = 0;
const proxy = await listen((req, res) => {
  proxyRequests += 1;
  res.end('proxied');
});

process.env.http_proxy = `http://127.0.0.1:${proxy.address().port}`;
process.env.HTTP_PROXY = process.env.http_proxy;
process.env.no_proxy = 'localhost,127.0.0.1,::1';
process.env.NO_PROXY = process.env.no_proxy;

try {
  const direct = await axios.get(`http://127.0.0.1:${origin.address().port}/`);
  const zero = await axios.get(`http://0.0.0.0:${origin.address().port}/`);

  console.log({ direct: direct.data, zero: zero.data, proxyRequests });
} finally {
  await close(origin);
  await close(proxy);
}

Expected safe behavior: both 127.0.0.1 and 0.0.0.0 bypass the proxy when the NO_PROXY policy is intended to cover local destinations.

Observed behavior: 127.0.0.1 bypasses the proxy, while 0.0.0.0 is sent through the proxy.

Workarounds

  • Add 0.0.0.0 explicitly to NO_PROXY where local addresses must bypass proxies.
  • Reject or normalize 0.0.0.0 in application URL validation before calling axios.
  • Set proxy: false on axios requests that must never use environment proxies.
  • Configure the proxy itself to reject 0.0.0.0, loopback, link-local, and internal address ranges.
Original Report ### Summary `axios` versions 1.15.0–1.16.1 contain an incomplete loopback-address check in `lib/helpers/shouldBypassProxy.js`. The `isLoopback()` function correctly identifies `127.0.0.0/8` and `::1` as loopback addresses but does not recognise `0.0.0.0` — the IPv4 unspecified address, which routes to the local machine on Linux and macOS. An attacker who controls a URL passed to axios can use `http://0.0.0.0/` to bypass proxy-based SSRF filtering that the application relies upon. ### Details ## Affected versions `>= 1.15.0, <= 1.16.1` The vulnerability was introduced in v1.15.0 when the `shouldBypassProxy` helper was added as a security improvement (PR #10661). --- ## Root cause **File:** `lib/helpers/shouldBypassProxy.js` ```javascript // Line 1 — static allowlist (incomplete) const LOOPBACK_HOSTNAMES = new Set(['localhost']); // ← 0.0.0.0 missing const isIPv4Loopback = (host) => { const parts = host.split('.'); if (parts.length !== 4) return false; if (parts[0] !== '127') return false; // ← 0.0.0.0: parts[0] = '0' → false return parts.every((p) => /^\d+$/.test(p) && Number(p) >= 0 && Number(p) <= 255); }; const isLoopback = (host) => { if (!host) return false; if (LOOPBACK_HOSTNAMES.has(host)) return true; // ← '0.0.0.0' not in set if (isIPv4Loopback(host)) return true; // ← returns false for 0.0.0.0 return isIPv6Loopback(host); }; isLoopback('0.0.0.0') returns false. Node's WHATWG URL parser does not normalise 0.0.0.0 to 127.0.0.1. Other bypass forms are safe: new URL('http://0177.0.0.1/').hostname → '127.0.0.1' (octal), new URL('http://2130706433/').hostname → '127.0.0.1' (decimal), new URL('http://0x7f000001/').hostname → '127.0.0.1' (hex). Only 0.0.0.0 escapes normalisation. ### PoC 'use strict'; // Verbatim copy of relevant logic from axios v1.16.1 shouldBypassProxy.js const LOOPBACK_HOSTNAMES = new Set(['localhost']); const isIPv4Loopback = (host) => { const parts = host.split('.'); if (parts.length !== 4) return false; if (parts[0] !== '127') return false; return parts.every((p) => /^\d+$/.test(p) && Number(p) >= 0 && Number(p) <= 255); }; const isLoopback = (host) => { if (!host) return false; if (LOOPBACK_HOSTNAMES.has(host)) return true; return isIPv4Loopback(host); }; // 1. Show URL parser does NOT normalise 0.0.0.0 console.log(new URL('http://0.0.0.0/').hostname); // → '0.0.0.0' ← NOT normalised console.log(new URL('http://0177.0.0.1/').hostname); // → '127.0.0.1' ← normalised (safe) console.log(new URL('http://2130706433/').hostname); // → '127.0.0.1' ← normalised (safe) // 2. Show isLoopback fails for 0.0.0.0 console.log(isLoopback('0.0.0.0')); // → false ← BUG: should be true console.log(isLoopback('127.0.0.1')); // → true ← correct Verified output on Node.js v22 / axios v1.16.1: 0.0.0.0 ← NOT normalised by URL parser 127.0.0.1 ← octal normalised correctly 127.0.0.1 ← decimal normalised correctly false ← 0.0.0.0 not detected as loopback ⚠ true ← 127.0.0.1 correctly detected ### Impact Applications that: Accept user-supplied URLs and pass them to axios Use a proxy with NO_PROXY=localhost (or similar) for SSRF filtering …can be bypassed by supplying http://0.0.0.0/. Axios routes the request through the proxy (shouldBypassProxy returns false). If the proxy itself does not filter 0.0.0.0, the connection reaches the local machine — exposing internal services such as cloud IMDS endpoints, internal admin panels, or microservice APIs. Fix Minimal (one line): - const LOOPBACK_HOSTNAMES = new Set(['localhost']); + const LOOPBACK_HOSTNAMES = new Set(['localhost', '0.0.0.0']); Comprehensive: const isIPv4Unspecified = (host) => host === '0.0.0.0'; const isLoopback = (host) => { if (!host) return false; if (LOOPBACK_HOSTNAMES.has(host)) return true; if (isIPv4Loopback(host)) return true; if (isIPv4Unspecified(host)) return true; // add this line return isIPv6Loopback(host); };
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.15.0"
            },
            {
              "fixed": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.31.0"
            },
            {
              "fixed": "0.33.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-183",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T22:20:18Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nAxios versions containing `lib/helpers/shouldBypassProxy.js` do not treat `0.0.0.0` as a local address when evaluating `NO_PROXY` rules. In Node.js applications that use `HTTP_PROXY` or `HTTPS_PROXY` together with `NO_PROXY=localhost,127.0.0.1,::1` or similar, a request to `http://0.0.0.0:\u003cport\u003e/` can be routed through the configured proxy instead of bypassing it.\n\nThe issue is exploitable when an attacker can influence the axios request URL or a followed redirect target, and when the proxy can reach or relay `0.0.0.0` to local services. This is a Node.js runtime proxy-routing issue, not a browser, install-time, or development-tooling issue.\n\n## Impact\n\nApplications are affected when all of the following are true:\n\n- The application runs axios in Node.js with the HTTP adapter.\n- The process uses environment proxy variables such as `HTTP_PROXY` or `HTTPS_PROXY`.\n- The process uses `NO_PROXY` entries such as `localhost`, `127.0.0.1`, or `::1` to keep local traffic out of the proxy path.\n- Attacker-controlled input can influence the request URL or redirect target.\n- The configured proxy does not reject `0.0.0.0` and can reach the local destination.\n\nFor plain HTTP targets, the proxy can receive the full request URL, headers, and body, and may be able to observe the local service response. HTTPS targets are less exposed because axios uses CONNECT tunneling in current versions.\n\n## Affected Functionality\n\nAffected functionality is limited to environment-derived proxy selection in the Node HTTP adapter:\n\n- `lib/adapters/http.js` calls `getProxyForUrl(location)` and then `shouldBypassProxy(location)` before applying the proxy.\n- `lib/helpers/shouldBypassProxy.js` normalizes and compares `NO_PROXY` entries.\n- Explicit caller-provided `config.proxy` remains trusted caller configuration.\n- Browser, React Native, XHR, and fetch adapter behavior are not affected.\n\n## Technical Details\n\n`lib/helpers/shouldBypassProxy.js` defines local loopback equivalence through `isLoopback()`. The current implementation recognizes `localhost`, IPv4 `127.0.0.0/8`, IPv6 `::1`, and IPv4-mapped loopback forms, but it does not include `0.0.0.0`.\n\nAt `lib/helpers/shouldBypassProxy.js:176`, axios treats two hosts as matching when both are considered loopback:\n\n```js\nreturn hostname === entryHost || (isLoopback(hostname) \u0026\u0026 isLoopback(entryHost));\n```\n\nBecause `isLoopback(\u00270.0.0.0\u0027)` returns `false`, `NO_PROXY=localhost,127.0.0.1,::1` does not match `http://0.0.0.0:\u003cport\u003e/`. `lib/adapters/http.js:185-193` then applies the environment proxy.\n\n## Proof of Concept of Attack\n\n```js\nimport http from \u0027http\u0027;\nimport axios from \u0027./index.js\u0027;\n\nconst listen = (handler, host = \u0027127.0.0.1\u0027) =\u003e\n  new Promise((resolve) =\u003e {\n    const server = http.createServer(handler);\n    server.listen(0, host, () =\u003e resolve(server));\n  });\n\nconst close = (server) =\u003e new Promise((resolve) =\u003e server.close(resolve));\n\nconst origin = await listen((req, res) =\u003e res.end(\u0027origin\u0027), \u00270.0.0.0\u0027);\n\nlet proxyRequests = 0;\nconst proxy = await listen((req, res) =\u003e {\n  proxyRequests += 1;\n  res.end(\u0027proxied\u0027);\n});\n\nprocess.env.http_proxy = `http://127.0.0.1:${proxy.address().port}`;\nprocess.env.HTTP_PROXY = process.env.http_proxy;\nprocess.env.no_proxy = \u0027localhost,127.0.0.1,::1\u0027;\nprocess.env.NO_PROXY = process.env.no_proxy;\n\ntry {\n  const direct = await axios.get(`http://127.0.0.1:${origin.address().port}/`);\n  const zero = await axios.get(`http://0.0.0.0:${origin.address().port}/`);\n\n  console.log({ direct: direct.data, zero: zero.data, proxyRequests });\n} finally {\n  await close(origin);\n  await close(proxy);\n}\n```\n\nExpected safe behavior: both `127.0.0.1` and `0.0.0.0` bypass the proxy when the `NO_PROXY` policy is intended to cover local destinations.\n\nObserved behavior: `127.0.0.1` bypasses the proxy, while `0.0.0.0` is sent through the proxy.\n\n## Workarounds\n\n- Add `0.0.0.0` explicitly to `NO_PROXY` where local addresses must bypass proxies.\n- Reject or normalize `0.0.0.0` in application URL validation before calling axios.\n- Set `proxy: false` on axios requests that must never use environment proxies.\n- Configure the proxy itself to reject `0.0.0.0`, loopback, link-local, and internal address ranges.\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Report\u003c/summary\u003e\n\n### Summary\n`axios` versions 1.15.0\u20131.16.1 contain an incomplete loopback-address check in `lib/helpers/shouldBypassProxy.js`. The `isLoopback()` function correctly identifies `127.0.0.0/8` and `::1` as loopback addresses but does not recognise `0.0.0.0` \u2014 the IPv4 unspecified address, which routes to the local machine on Linux and macOS.\n\nAn attacker who controls a URL passed to axios can use `http://0.0.0.0/\u003cpath\u003e` to bypass proxy-based SSRF filtering that the application relies upon.\n\n### Details\n## Affected versions\n\n`\u003e= 1.15.0, \u003c= 1.16.1`\n\nThe vulnerability was introduced in v1.15.0 when the `shouldBypassProxy` helper was added as a security improvement (PR #10661).\n\n---\n\n## Root cause\n\n**File:** `lib/helpers/shouldBypassProxy.js`\n\n```javascript\n// Line 1 \u2014 static allowlist (incomplete)\nconst LOOPBACK_HOSTNAMES = new Set([\u0027localhost\u0027]);   // \u2190 0.0.0.0 missing\n\nconst isIPv4Loopback = (host) =\u003e {\n  const parts = host.split(\u0027.\u0027);\n  if (parts.length !== 4) return false;\n  if (parts[0] !== \u0027127\u0027) return false;   // \u2190 0.0.0.0: parts[0] = \u00270\u0027 \u2192 false\n  return parts.every((p) =\u003e /^\\d+$/.test(p) \u0026\u0026 Number(p) \u003e= 0 \u0026\u0026 Number(p) \u003c= 255);\n};\n\nconst isLoopback = (host) =\u003e {\n  if (!host) return false;\n  if (LOOPBACK_HOSTNAMES.has(host)) return true;   // \u2190 \u00270.0.0.0\u0027 not in set\n  if (isIPv4Loopback(host)) return true;           // \u2190 returns false for 0.0.0.0\n  return isIPv6Loopback(host);\n};\n\nisLoopback(\u00270.0.0.0\u0027) returns false.\n\nNode\u0027s WHATWG URL parser does not normalise 0.0.0.0 to 127.0.0.1. Other bypass forms are safe: new URL(\u0027http://0177.0.0.1/\u0027).hostname \u2192 \u0027127.0.0.1\u0027 (octal), new URL(\u0027http://2130706433/\u0027).hostname \u2192 \u0027127.0.0.1\u0027 (decimal), new URL(\u0027http://0x7f000001/\u0027).hostname \u2192 \u0027127.0.0.1\u0027 (hex). Only 0.0.0.0 escapes normalisation.\n\n\n### PoC\n\u0027use strict\u0027;\n\n// Verbatim copy of relevant logic from axios v1.16.1 shouldBypassProxy.js\n\nconst LOOPBACK_HOSTNAMES = new Set([\u0027localhost\u0027]);\n\nconst isIPv4Loopback = (host) =\u003e {\n  const parts = host.split(\u0027.\u0027);\n  if (parts.length !== 4) return false;\n  if (parts[0] !== \u0027127\u0027) return false;\n  return parts.every((p) =\u003e /^\\d+$/.test(p) \u0026\u0026 Number(p) \u003e= 0 \u0026\u0026 Number(p) \u003c= 255);\n};\n\nconst isLoopback = (host) =\u003e {\n  if (!host) return false;\n  if (LOOPBACK_HOSTNAMES.has(host)) return true;\n  return isIPv4Loopback(host);\n};\n\n// 1. Show URL parser does NOT normalise 0.0.0.0\nconsole.log(new URL(\u0027http://0.0.0.0/\u0027).hostname);    // \u2192 \u00270.0.0.0\u0027   \u2190 NOT normalised\nconsole.log(new URL(\u0027http://0177.0.0.1/\u0027).hostname); // \u2192 \u0027127.0.0.1\u0027 \u2190 normalised (safe)\nconsole.log(new URL(\u0027http://2130706433/\u0027).hostname);  // \u2192 \u0027127.0.0.1\u0027 \u2190 normalised (safe)\n\n// 2. Show isLoopback fails for 0.0.0.0\nconsole.log(isLoopback(\u00270.0.0.0\u0027));   // \u2192 false  \u2190 BUG: should be true\nconsole.log(isLoopback(\u0027127.0.0.1\u0027)); // \u2192 true   \u2190 correct\n\nVerified output on Node.js v22 / axios v1.16.1:\n0.0.0.0     \u2190 NOT normalised by URL parser\n127.0.0.1   \u2190 octal normalised correctly\n127.0.0.1   \u2190 decimal normalised correctly\nfalse       \u2190 0.0.0.0 not detected as loopback  \u26a0\ntrue        \u2190 127.0.0.1 correctly detected\n\n### Impact\nApplications that:\n\nAccept user-supplied URLs and pass them to axios\nUse a proxy with NO_PROXY=localhost (or similar) for SSRF filtering\n\u2026can be bypassed by supplying http://0.0.0.0/\u003cpath\u003e. Axios routes the request through the proxy (shouldBypassProxy returns false). If the proxy itself does not filter 0.0.0.0, the connection reaches the local machine \u2014 exposing internal services such as cloud IMDS endpoints, internal admin panels, or microservice APIs.\n\nFix\nMinimal (one line):\n\n- const LOOPBACK_HOSTNAMES = new Set([\u0027localhost\u0027]);\n+ const LOOPBACK_HOSTNAMES = new Set([\u0027localhost\u0027, \u00270.0.0.0\u0027]);\n\nComprehensive:\n\nconst isIPv4Unspecified = (host) =\u003e host === \u00270.0.0.0\u0027;\n\nconst isLoopback = (host) =\u003e {\n  if (!host) return false;\n  if (LOOPBACK_HOSTNAMES.has(host)) return true;\n  if (isIPv4Loopback(host)) return true;\n  if (isIPv4Unspecified(host)) return true;   // add this line\n  return isIPv6Loopback(host);\n};\n\u003c/details\u003e",
  "id": "GHSA-f4gw-2p7v-4548",
  "modified": "2026-07-20T22:20:18Z",
  "published": "2026-07-20T22:20:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-f4gw-2p7v-4548"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/11000"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/11001"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/1417285c69344bbcc6420a021f67dee0c6fedb2d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/32fc489632377d214db55bfa4e2c48486a7d7ce2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v0.33.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v1.18.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Axios: NO_PROXY bypass for 0.0.0.0 local addresses in axios"
}

GHSA-F4QM-WPP3-7V77

Vulnerability from github – Published: 2022-05-19 00:00 – Updated: 2022-05-27 00:00
VLAI
Details

Server-Side Request Forgery (SSRF) in GitHub repository jgraph/drawio prior to 18.0.7.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-1767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-18T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) in GitHub repository jgraph/drawio prior to 18.0.7.",
  "id": "GHSA-f4qm-wpp3-7v77",
  "modified": "2022-05-27T00:00:53Z",
  "published": "2022-05-19T00:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1767"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jgraph/drawio/commit/c63f3a04450f30798df47f9badbc74eb8a69fbdf"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/b1ce040c-9ed1-4d36-9b48-82df42310868"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F4VR-C276-C5CM

Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31
VLAI
Details

A vulnerability in the web interface of Cisco TelePresence Conductor, Cisco Expressway Series, and Cisco TelePresence Video Communication Server (VCS) Software could allow an authenticated, remote attacker to trigger an HTTP request from an affected server to an arbitrary host. This type of attack is commonly referred to as server-side request forgery (SSRF). The vulnerability is due to insufficient access controls for the REST API of Cisco Expressway Series and Cisco TelePresence VCS. An attacker could exploit this vulnerability by submitting a crafted HTTP request to the affected server. Versions prior to XC4.3.4 are affected.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-1679"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-02-07T21:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the web interface of Cisco TelePresence Conductor, Cisco Expressway Series, and Cisco TelePresence Video Communication Server (VCS) Software could allow an authenticated, remote attacker to trigger an HTTP request from an affected server to an arbitrary host. This type of attack is commonly referred to as server-side request forgery (SSRF). The vulnerability is due to insufficient access controls for the REST API of Cisco Expressway Series and Cisco TelePresence VCS. An attacker could exploit this vulnerability by submitting a crafted HTTP request to the affected server. Versions prior to XC4.3.4 are affected.",
  "id": "GHSA-f4vr-c276-c5cm",
  "modified": "2022-05-13T01:31:25Z",
  "published": "2022-05-13T01:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1679"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190206-rest-api-ssrf"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106940"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F4W7-4MQ2-VXRX

Vulnerability from github – Published: 2025-09-15 18:31 – Updated: 2025-09-15 18:31
VLAI
Details

A vulnerability was detected in ZKEACMS 4.3. Impacted is the function Proxy of the file src/ZKEACMS/Controllers/MediaController.cs. Performing manipulation of the argument url results in server-side request forgery. It is possible to initiate the attack remotely. The exploit is now public and may be used.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-10471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-15T17:15:34Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was detected in ZKEACMS 4.3. Impacted is the function Proxy of the file src/ZKEACMS/Controllers/MediaController.cs. Performing manipulation of the argument url results in server-side request forgery. It is possible to initiate the attack remotely. The exploit is now public and may be used.",
  "id": "GHSA-f4w7-4mq2-vxrx",
  "modified": "2025-09-15T18:31:06Z",
  "published": "2025-09-15T18:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10471"
    },
    {
      "type": "WEB",
      "url": "https://github.com/August829/Yu/blob/main/58ead8e7e08bfb022.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/August829/Yu/blob/main/58ead8e7e08bfb022.md#poc"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.323890"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.323890"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.648387"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-F5CJ-CGW5-MJ38

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

SPIP before 4.4.9 allows Blind Server-Side Request Forgery (SSRF) via syndicated sites in the private area. When editing a syndicated site, the application does not verify that the syndication URL is a valid remote URL, allowing an authenticated attacker to make the server issue requests to arbitrary internal or external destinations. This vulnerability is not mitigated by the SPIP security screen.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-71247"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-19T16:27:12Z",
    "severity": "MODERATE"
  },
  "details": "SPIP before 4.4.9 allows Blind Server-Side Request Forgery (SSRF) via syndicated sites in the private area. When editing a syndicated site, the application does not verify that the syndication URL is a valid remote URL, allowing an authenticated attacker to make the server issue requests to arbitrary internal or external destinations. This vulnerability is not mitigated by the SPIP security screen.",
  "id": "GHSA-f5cj-cgw5-mj38",
  "modified": "2026-02-19T18:31:54Z",
  "published": "2026-02-19T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71247"
    },
    {
      "type": "WEB",
      "url": "https://blog.spip.net/Mise-a-jour-de-securite-sortie-de-SPIP-4-4-9.html"
    },
    {
      "type": "WEB",
      "url": "https://git.spip.net/spip/spip"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/spip-blind-server-side-request-forgery-via-syndicated-sites"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L/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-F5H9-QX38-2HGP

Vulnerability from github – Published: 2022-12-27 15:30 – Updated: 2023-01-10 15:39
VLAI
Summary
AWS SDK is vulnerable to server-side request forgery (SSRF)
Details

A vulnerability was found in AWS SDK 2.59.0. It has been rated as critical. This issue affects the function XpathUtils of the file aws-android-sdk-core/src/main/java/com/amazonaws/util/XpathUtils.java of the component XML Parser. The manipulation leads to server-side request forgery. Upgrading to version 2.59.1 can address this issue. The name of the patch is c3e6d69422e1f0c80fe53f2d757b8df97619af2b. It is recommended to upgrade the affected component. The identifier VDB-216737 was assigned to this vulnerability.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.59.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.amazonaws:aws-android-sdk-mobile-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.59.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-4725"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-30T00:54:03Z",
    "nvd_published_at": "2022-12-27T15:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability was found in AWS SDK 2.59.0. It has been rated as critical. This issue affects the function XpathUtils of the file aws-android-sdk-core/src/main/java/com/amazonaws/util/XpathUtils.java of the component XML Parser. The manipulation leads to server-side request forgery. Upgrading to version 2.59.1 can address this issue. The name of the patch is c3e6d69422e1f0c80fe53f2d757b8df97619af2b. It is recommended to upgrade the affected component. The identifier VDB-216737 was assigned to this vulnerability.",
  "id": "GHSA-f5h9-qx38-2hgp",
  "modified": "2023-01-10T15:39:09Z",
  "published": "2022-12-27T15:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4725"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws-amplify/aws-sdk-android/pull/3100"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws-amplify/aws-sdk-android/commit/c3e6d69422e1f0c80fe53f2d757b8df97619af2b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aws-amplify/aws-sdk-android"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws-amplify/aws-sdk-android/releases/tag/release_v2.59.1"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.216737"
    }
  ],
  "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"
    }
  ],
  "summary": "AWS SDK is vulnerable to server-side request forgery (SSRF) "
}

GHSA-F5MR-Q85P-6HH6

Vulnerability from github – Published: 2026-06-30 18:38 – Updated: 2026-06-30 18:38
VLAI
Summary
Fulcio has OIDC Discovery Redirect Following Allows SSRF and JWKS Substitution for Meta-Issuer Paths, with Kubernetes Service-Account Token Leakage
Details

Impact

Three security vulnerabilities were identified in the OIDC Discovery client:

  1. Blind Server-Side Request Forgery (SSRF) via Cross-Host Redirects: Fulcio uses an HTTP client to fetch OIDC discovery metadata (/.well-known/openid-configuration). Prior to this fix, if a configured issuer returned an HTTP redirect to a different host, the client followed it by default. This allowed a compromised or malicious issuer to redirect Fulcio's discovery requests to internal-only systems, resulting in blind SSRF.

  2. JWKS Substitution and Cache Poisoning: Because cross-host redirects were permitted during OIDC discovery, an attacker could manipulate the discovery flow to return a malicious jwks_uri pointing to an attacker-controlled host. When Fulcio successfully initialized the provider and cached the resulting verifier in the verifier cache, it poisoned the cache with the attacker's verification keys. The attacker could then present signatures validated against the poisoned keys.

  3. Kubernetes ServiceAccount Token Leakage: Fulcio mounts an in-cluster Kubernetes ServiceAccount token to authenticate OIDC discovery requests sent to the local control plane API server (https://kubernetes.default.svc).

  4. Cross-Host Redirects & JWKS: The token was previously attached globally by the transport, leaking it to third-party hosts if the issuer performed a redirect or if the jwks_uri pointed to a different domain.
  5. Wildcard MetaIssuers: If a wildcard MetaIssuer of type kubernetes (e.g., matching external EKS/GKE endpoints) was matched, and a local Kubernetes issuer was present in the config, the transport loaded and attached the local in-cluster ServiceAccount token to outbound requests sent to the external host.

Patches

The following mitigations have been applied:

  • Blocked Cross-Host Redirects: A custom callback is configured on all OIDC discovery HTTP clients to reject redirects that attempt to cross the original issuer's host boundary.
  • Restricted Token Injection: Updated the transport to only attach the ServiceAccount token when the outgoing request's host exactly matches the configured host of the issuer.
  • Restricted Local Token Loading: Constrained the loader to only load and wrap the transport with the local ServiceAccount token when the target issuer URL exactly matches the private local API server (https://kubernetes.default.svc).

Workarounds

None, upgrade to v1.8.6

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.5"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/fulcio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-30T18:38:45Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Impact\n\nThree security vulnerabilities were identified in the OIDC Discovery client:\n\n1. **Blind Server-Side Request Forgery (SSRF) via Cross-Host Redirects**:\n   Fulcio uses an HTTP client to fetch OIDC discovery metadata (`/.well-known/openid-configuration`). Prior to this fix, if a configured issuer returned an HTTP redirect to a different host, the client followed it by default. This allowed a compromised or malicious issuer to redirect Fulcio\u0027s discovery requests to internal-only systems, resulting in blind SSRF.\n\n2. **JWKS Substitution and Cache Poisoning**:\n   Because cross-host redirects were permitted during OIDC discovery, an attacker could manipulate the discovery flow to return a malicious `jwks_uri` pointing to an attacker-controlled host. When Fulcio successfully initialized the provider and cached the resulting verifier in the verifier cache, it poisoned the cache with the attacker\u0027s verification keys. The attacker could then present signatures validated against the poisoned keys.\n\n3. **Kubernetes ServiceAccount Token Leakage**:\n   Fulcio mounts an in-cluster Kubernetes ServiceAccount token to authenticate OIDC discovery requests sent to the local control plane API server (`https://kubernetes.default.svc`).\n   * **Cross-Host Redirects \u0026 JWKS**: The token was previously attached globally by the transport, leaking it to third-party hosts if the issuer performed a redirect or if the `jwks_uri` pointed to a different domain.\n   * **Wildcard MetaIssuers**: If a wildcard `MetaIssuer` of type `kubernetes` (e.g., matching external EKS/GKE endpoints) was matched, and a local Kubernetes issuer was present in the config, the transport loaded and attached the local in-cluster ServiceAccount token to outbound requests sent to the external host.\n\n## Patches\n\nThe following mitigations have been applied:\n\n* **Blocked Cross-Host Redirects**: A custom callback is configured on all OIDC discovery HTTP clients to reject redirects that attempt to cross the original issuer\u0027s host boundary.\n* **Restricted Token Injection**: Updated the transport to only attach the ServiceAccount token when the outgoing request\u0027s host exactly matches the configured host of the issuer.\n* **Restricted Local Token Loading**: Constrained the loader to only load and wrap the transport with the local ServiceAccount token when the target issuer URL exactly matches the private local API server (`https://kubernetes.default.svc`).\n\n## Workarounds\n\nNone, upgrade to v1.8.6",
  "id": "GHSA-f5mr-q85p-6hh6",
  "modified": "2026-06-30T18:38:45Z",
  "published": "2026-06-30T18:38:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/fulcio/security/advisories/GHSA-f5mr-q85p-6hh6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/fulcio"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fulcio has OIDC Discovery Redirect Following Allows SSRF and JWKS Substitution for Meta-Issuer Paths, with Kubernetes Service-Account Token Leakage"
}

GHSA-F5Q7-Q5C3-56H8

Vulnerability from github – Published: 2025-12-19 00:31 – Updated: 2025-12-19 00:31
VLAI
Details

Custom Question Answering Elevation of Privilege Vulnerability

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-64663"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-18T22:16:00Z",
    "severity": "CRITICAL"
  },
  "details": "Custom Question Answering Elevation of Privilege Vulnerability",
  "id": "GHSA-f5q7-q5c3-56h8",
  "modified": "2025-12-19T00:31:42Z",
  "published": "2025-12-19T00:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64663"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-64663"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F622-26HM-XGJ8

Vulnerability from github – Published: 2021-12-17 00:00 – Updated: 2021-12-23 00:01
VLAI
Details

A Server-Side Request Forgery (SSRF) vulnerability in the EPPUpdateService component of Bitdefender Endpoint Security Tools allows an attacker to proxy requests to the relay server. This issue affects: Bitdefender Bitdefender GravityZone versions prior to 3.3.8.272

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-3959"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-16T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability in the EPPUpdateService component of Bitdefender Endpoint Security Tools allows an attacker to proxy requests to the relay server. This issue affects: Bitdefender Bitdefender GravityZone versions prior to 3.3.8.272",
  "id": "GHSA-f622-26hm-xgj8",
  "modified": "2021-12-23T00:01:55Z",
  "published": "2021-12-17T00:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3959"
    },
    {
      "type": "WEB",
      "url": "https://www.bitdefender.com/support/security-advisories/server-side-request-forgery-in-bitdefender-gravityzone-update-server-in-relay-mode-va-10145"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.

← Back to the CWE list