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.

6158 vulnerabilities reference this CWE, most recent first.

GHSA-3PQ3-5FJ3-CG6V

Vulnerability from github – Published: 2026-09-30 15:02 – Updated: 2026-09-30 15:02
VLAI
Summary
Axios: HTTP/2 adapter bypasses configured DNS lookup and proxy controls
Details

Summary

Axios for Node.js does not apply configured DNS lookup or proxy controls when a request uses httpVersion: 2. The HTTP/1 adapter path wraps and forwards config.lookup, builds normal request options, and applies proxy routing through setProxy(). The HTTP/2 path builds a session with http2.connect() using only options.http2Options, which drops the top-level lookup, agent, and proxy state.

Applications are affected when they allow a user to influence request destinations, enable axios HTTP/2, and rely on axios lookup or proxy routing to prevent SSRF or enforce outbound network policy.

Impact

In affected server-side deployments, an attacker can cause axios to connect directly to destinations that the configured resolver or proxy would have rejected. Depending on reachable services, this can expose cloud metadata, internal service responses, or allow state-changing requests to internal systems.

This is not an unconditional SSRF in every axios deployment. It requires httpVersion: 2 and an application-level trust boundary where user-influenced URLs are constrained by lookup or proxy policy.

Affected Functionality

Affected:

  • Node.js HTTP adapter with httpVersion: 2.
  • config.lookup supplied as a DNS policy.
  • Explicit config.proxy and environment-derived proxy settings for HTTPS HTTP/2 requests.

Not affected:

  • Browser adapters.
  • Node HTTP/1 requests, which pass lookup to the transport and apply proxy handling.
  • Applications that validate destination hosts independently before calling axios.

Technical Details

In lib/adapters/http.js, the adapter reads lookup, wraps it, stores it on the request options, and applies setProxy() before selecting a transport. For HTTP/2, http2Transport.request() builds an authority from options.protocol, options.hostname, and options.port, then calls:

const { http2Options, headers } = options;
const session = http2Sessions.getSession(authority, http2Options);

lib/helpers/Http2Sessions.js ultimately calls http2.connect(authority, options) with only the http2Options object. The configured DNS lookup and the proxy or tunneling agent installed on the top-level request options are not forwarded into that call.

Local verification on axios 1.18.1 showed lookupCalls: 0 while an HTTP/2 request to a local h2 origin succeeded. A second local HTTPS h2 verification with an explicit rejecting HTTP proxy showed the origin received the request and the proxy observed no traffic.

Proof of Concept of Attack

Local constrained demonstration:

  1. Start an HTTP/2 server on loopback.
  2. Call axios.get("http://localhost:<port>/internal", { httpVersion: 2, lookup }) where lookup throws EPOLICY.
  3. Observe that the request succeeds and the lookup counter remains 0.

For proxy routing:

  1. Start an HTTPS HTTP/2 origin and a local HTTP proxy that rejects every request and CONNECT.
  2. Call axios with httpVersion: 2, http2Options: { rejectUnauthorized: false }, and explicit proxy.
  3. Observe that the origin receives the request and the proxy receives nothing.

Expected safe behavior is that either the lookup policy blocks the request or the proxy observes and rejects the request.

Workarounds

Use the HTTP/1 adapter path for requests that depend on axios lookup or proxy controls. Alternatively, enforce destination allow/deny policy before calling axios, outside the adapter transport path.

Original report

### Summary I found that Axios does not apply the configured `lookup` function or proxy when a request uses `httpVersion: 2`. The HTTP/1 adapter applies both controls, but the HTTP/2 path connects straight to the URL's hostname using `http2.connect()`. This matters for server applications that accept a user-influenced URL and use a custom DNS lookup or mandatory outbound proxy to prevent SSRF. Switching the Axios instance to HTTP/2 silently removes those controls, allowing the request to reach an address the application intended to block. I reproduced this on the current npm release, Axios 1.18.1. ### Details The HTTP adapter reads and wraps the caller's `lookup` function, builds the normal request options, and calls `setProxy()`: - `lib/adapters/http.js`, around lines 530-578: reads and wraps `lookup` - `lib/adapters/http.js`, around lines 895-954: adds `lookup` to `options` and applies `setProxy()` For HTTP/2, however, the adapter selects `http2Transport`. That transport creates an authority from the destination and only passes `options.http2Options` to the session pool: 
const { http2Options, headers } = options;
const session = http2Sessions.getSession(authority, http2Options);
`lib/helpers/Http2Sessions.js` then calls: 
const session = http2.connect(authority, options);
At this point `options` is only the `http2Options` object. The top-level `lookup`, the proxy tunnelling agent created by `setProxy()`, and the selected `httpAgent`/`httpsAgent` are not forwarded. The request therefore uses the system resolver and opens a direct connection to the origin. The same root cause affects both explicit proxy configuration and environment-derived proxy configuration. I kept the PoC local and used an explicit proxy so the result does not depend on shell environment variables. ### PoC I attached [axios_http2_transport_controls_poc.mjs](https://drive.google.com/file/d/1lKXBOLDoysOFRmaRyV1tMVLx3P0Ah4gV/view?usp=sharing). The PoC is entirely local and sets up three pieces: 1. An HTTPS origin with HTTP/2 enabled. If reached, it records the request and returns `REACHED_BLOCKED_ORIGIN`. 2. An HTTP proxy that records traffic but rejects every normal request and every CONNECT request with `502 Bad Gateway`. 3. A custom Axios `lookup` callback that rejects every DNS lookup with an `EPOLICY` error. The first request is an HTTP/1 control request. It uses the blocking `lookup` callback and has proxying disabled. Axios calls the callback, receives `EPOLICY`, and does not reach the origin. This confirms that the callback works and that the hostname is blocked through the normal adapter path. The second request targets the same URL with `httpVersion: 2`. It is given both security controls: the same blocking `lookup` callback and the rejecting proxy. If Axios honors either one, this request cannot reach the origin. It should fail with `EPOLICY`, or it should reach the proxy and receive its `502` response. Instead, the request returns HTTP 200 with `REACHED_BLOCKED_ORIGIN`. The lookup counter does not increase, and the proxy records no request or CONNECT attempt. The origin is the only server that records traffic. This shows that the HTTP/2 path skipped both controls and connected directly using the system resolver. To reproduce, run the attachment from the root of an Axios checkout: Run it from the root of an Axios checkout: 
git checkout v1.18.1
npm install --ignore-scripts
node /path/to/axios_http2_transport_controls_poc.mjs
Relevant output from my run: 
{
  "axiosVersion": "1.18.1",
  "configuredControls": {
    "lookup": "reject every DNS lookup with EPOLICY",
    "proxy": "http://127.0.0.1:<port> (reject every request)"
  },
  "http1Control": "EPOLICY: blocked by application DNS policy",
  "http2Result": {
    "status": 200,
    "data": "REACHED_BLOCKED_ORIGIN"
  },
  "lookupCalls": 1,
  "proxyObservedTraffic": false,
  "events": [
    {
      "server": "origin",
      "protocol": "h2",
      "path": "/internal"
    }
  ]
}
The important parts of the output are: - `http1Control` contains `EPOLICY`, proving the DNS policy blocks the destination under HTTP/1. - `lookupCalls` is still `1` after both requests, proving HTTP/2 never called the configured resolver. - `proxyObservedTraffic` is `false`, proving HTTP/2 did not use the configured proxy. - `http2Result.status` is `200`, and the sole event belongs to the origin, proving Axios connected directly to the blocked destination. ### Impact The vulnerable configuration is a Node.js application that: - enables Axios HTTP/2 using `httpVersion: 2`; - lets an application user influence the request destination; and - relies on Axios's `lookup` option or proxy routing to enforce a destination or egress policy. In that setup, an unauthenticated application user may be able to make the server connect directly to loopback, private-network, or link-local services that the lookup policy or proxy would have rejected. Depending on the reachable service, this can expose cloud credentials or internal data, modify internal services, or affect availability. HTTP/2 support is marked experimental, but neither the HTTP/2 documentation nor the proxy documentation says that `lookup` and proxy controls are ignored. The proxy documentation states that HTTPS requests are sent through a CONNECT tunnel. More importantly, Axios's threat model tells callers that destination validation is their responsibility; this behavior silently bypasses such caller-supplied validation. I did not test against any third-party or production service. The PoC only uses listeners on my own machine.
Severity
7.0 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.13.0"
            },
            {
              "fixed": "1.20.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-101898"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T15:02:14Z",
    "nvd_published_at": "2026-09-28T18:17:17Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAxios for Node.js does not apply configured DNS lookup or proxy controls when a request uses `httpVersion: 2`. The HTTP/1 adapter path wraps and forwards `config.lookup`, builds normal request options, and applies proxy routing through `setProxy()`. The HTTP/2 path builds a session with `http2.connect()` using only `options.http2Options`, which drops the top-level `lookup`, `agent`, and proxy state.\n\nApplications are affected when they allow a user to influence request destinations, enable axios HTTP/2, and rely on axios `lookup` or proxy routing to prevent SSRF or enforce outbound network policy.\n\n## Impact\n\nIn affected server-side deployments, an attacker can cause axios to connect directly to destinations that the configured resolver or proxy would have rejected. Depending on reachable services, this can expose cloud metadata, internal service responses, or allow state-changing requests to internal systems.\n\nThis is not an unconditional SSRF in every axios deployment. It requires `httpVersion: 2` and an application-level trust boundary where user-influenced URLs are constrained by `lookup` or proxy policy.\n\n## Affected Functionality\n\nAffected:\n\n- Node.js HTTP adapter with `httpVersion: 2`.\n- `config.lookup` supplied as a DNS policy.\n- Explicit `config.proxy` and environment-derived proxy settings for HTTPS HTTP/2 requests.\n\nNot affected:\n\n- Browser adapters.\n- Node HTTP/1 requests, which pass `lookup` to the transport and apply proxy handling.\n- Applications that validate destination hosts independently before calling axios.\n\n## Technical Details\n\nIn `lib/adapters/http.js`, the adapter reads `lookup`, wraps it, stores it on the request `options`, and applies `setProxy()` before selecting a transport. For HTTP/2, `http2Transport.request()` builds an authority from `options.protocol`, `options.hostname`, and `options.port`, then calls:\n\n```js\nconst { http2Options, headers } = options;\nconst session = http2Sessions.getSession(authority, http2Options);\n```\n\n`lib/helpers/Http2Sessions.js` ultimately calls `http2.connect(authority, options)` with only the `http2Options` object. The configured DNS lookup and the proxy or tunneling agent installed on the top-level request options are not forwarded into that call.\n\nLocal verification on axios `1.18.1` showed `lookupCalls: 0` while an HTTP/2 request to a local h2 origin succeeded. A second local HTTPS h2 verification with an explicit rejecting HTTP proxy showed the origin received the request and the proxy observed no traffic.\n\n## Proof of Concept of Attack\n\nLocal constrained demonstration:\n\n1. Start an HTTP/2 server on loopback.\n2. Call `axios.get(\"http://localhost:\u003cport\u003e/internal\", { httpVersion: 2, lookup })` where `lookup` throws `EPOLICY`.\n3. Observe that the request succeeds and the lookup counter remains `0`.\n\nFor proxy routing:\n\n1. Start an HTTPS HTTP/2 origin and a local HTTP proxy that rejects every request and CONNECT.\n2. Call axios with `httpVersion: 2`, `http2Options: { rejectUnauthorized: false }`, and explicit `proxy`.\n3. Observe that the origin receives the request and the proxy receives nothing.\n\nExpected safe behavior is that either the lookup policy blocks the request or the proxy observes and rejects the request.\n\n## Workarounds\n\nUse the HTTP/1 adapter path for requests that depend on axios `lookup` or proxy controls. Alternatively, enforce destination allow/deny policy before calling axios, outside the adapter transport path.\n\n\u003cdetails\u003e\n  \u003csummary\u003e\u003ch3\u003eOriginal report\u003c/h3\u003e\u003c/summary\u003e\n  \n  ### Summary\n\nI found that Axios does not apply the configured `lookup` function or proxy when a request uses `httpVersion: 2`. The HTTP/1 adapter applies both controls, but the HTTP/2 path connects straight to the URL\u0027s hostname using `http2.connect()`.\n\nThis matters for server applications that accept a user-influenced URL and use a custom DNS lookup or mandatory outbound proxy to prevent SSRF. Switching the Axios instance to HTTP/2 silently removes those controls, allowing the request to reach an address the application intended to block.\n\nI reproduced this on the current npm release, Axios 1.18.1.\n\n### Details\n\nThe HTTP adapter reads and wraps the caller\u0027s `lookup` function, builds the normal request options, and calls `setProxy()`:\n\n- `lib/adapters/http.js`, around lines 530-578: reads and wraps `lookup`\n- `lib/adapters/http.js`, around lines 895-954: adds `lookup` to `options` and applies `setProxy()`\n\nFor HTTP/2, however, the adapter selects `http2Transport`. That transport creates an authority from the destination and only passes `options.http2Options` to the session pool:\n\n```js\nconst { http2Options, headers } = options;\nconst session = http2Sessions.getSession(authority, http2Options);\n```\n\n`lib/helpers/Http2Sessions.js` then calls:\n\n```js\nconst session = http2.connect(authority, options);\n```\n\nAt this point `options` is only the `http2Options` object. The top-level `lookup`, the proxy tunnelling agent created by `setProxy()`, and the selected `httpAgent`/`httpsAgent` are not forwarded. The request therefore uses the system resolver and opens a direct connection to the origin.\n\nThe same root cause affects both explicit proxy configuration and environment-derived proxy configuration. I kept the PoC local and used an explicit proxy so the result does not depend on shell environment variables.\n\n### PoC\n\nI attached [axios_http2_transport_controls_poc.mjs](https://drive.google.com/file/d/1lKXBOLDoysOFRmaRyV1tMVLx3P0Ah4gV/view?usp=sharing). The PoC is entirely local and sets up three pieces:\n\n1. An HTTPS origin with HTTP/2 enabled. If reached, it records the request and returns `REACHED_BLOCKED_ORIGIN`.\n2. An HTTP proxy that records traffic but rejects every normal request and every CONNECT request with `502 Bad Gateway`.\n3. A custom Axios `lookup` callback that rejects every DNS lookup with an `EPOLICY` error.\n\nThe first request is an HTTP/1 control request. It uses the blocking `lookup` callback and has proxying disabled. Axios calls the callback, receives `EPOLICY`, and does not reach the origin. This confirms that the callback works and that the hostname is blocked through the normal adapter path.\n\nThe second request targets the same URL with `httpVersion: 2`. It is given both security controls: the same blocking `lookup` callback and the rejecting proxy. If Axios honors either one, this request cannot reach the origin. It should fail with `EPOLICY`, or it should reach the proxy and receive its `502` response.\n\nInstead, the request returns HTTP 200 with `REACHED_BLOCKED_ORIGIN`. The lookup counter does not increase, and the proxy records no request or CONNECT attempt. The origin is the only server that records traffic. This shows that the HTTP/2 path skipped both controls and connected directly using the system resolver.\n\nTo reproduce, run the attachment from the root of an Axios checkout:\n\nRun it from the root of an Axios checkout:\n\n```bash\ngit checkout v1.18.1\nnpm install --ignore-scripts\nnode /path/to/axios_http2_transport_controls_poc.mjs\n```\n\nRelevant output from my run:\n\n```json\n{\n  \"axiosVersion\": \"1.18.1\",\n  \"configuredControls\": {\n    \"lookup\": \"reject every DNS lookup with EPOLICY\",\n    \"proxy\": \"http://127.0.0.1:\u003cport\u003e (reject every request)\"\n  },\n  \"http1Control\": \"EPOLICY: blocked by application DNS policy\",\n  \"http2Result\": {\n    \"status\": 200,\n    \"data\": \"REACHED_BLOCKED_ORIGIN\"\n  },\n  \"lookupCalls\": 1,\n  \"proxyObservedTraffic\": false,\n  \"events\": [\n    {\n      \"server\": \"origin\",\n      \"protocol\": \"h2\",\n      \"path\": \"/internal\"\n    }\n  ]\n}\n```\n\nThe important parts of the output are:\n\n- `http1Control` contains `EPOLICY`, proving the DNS policy blocks the destination under HTTP/1.\n- `lookupCalls` is still `1` after both requests, proving HTTP/2 never called the configured resolver.\n- `proxyObservedTraffic` is `false`, proving HTTP/2 did not use the configured proxy.\n- `http2Result.status` is `200`, and the sole event belongs to the origin, proving Axios connected directly to the blocked destination.\n\n### Impact\n\nThe vulnerable configuration is a Node.js application that:\n\n- enables Axios HTTP/2 using `httpVersion: 2`;\n- lets an application user influence the request destination; and\n- relies on Axios\u0027s `lookup` option or proxy routing to enforce a destination or egress policy.\n\nIn that setup, an unauthenticated application user may be able to make the server connect directly to loopback, private-network, or link-local services that the lookup policy or proxy would have rejected. Depending on the reachable service, this can expose cloud credentials or internal data, modify internal services, or affect availability.\n\nHTTP/2 support is marked experimental, but neither the HTTP/2 documentation nor the proxy documentation says that `lookup` and proxy controls are ignored. The proxy documentation states that HTTPS requests are sent through a CONNECT tunnel. More importantly, Axios\u0027s threat model tells callers that destination validation is their responsibility; this behavior silently bypasses such caller-supplied validation.\n\nI did not test against any third-party or production service. The PoC only uses listeners on my own machine.\n\u003c/details\u003e\n\n---",
  "id": "GHSA-3pq3-5fj3-cg6v",
  "modified": "2026-09-30T15:02:14Z",
  "published": "2026-09-30T15:02:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-3pq3-5fj3-cg6v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101898"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/11141"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/d19040bda7a8be2f82c3c6e1a5bc03917daee39a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v1.20.0"
    }
  ],
  "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:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Axios: HTTP/2 adapter bypasses configured DNS lookup and proxy controls"
}

GHSA-3PX8-2P4Q-XPWM

Vulnerability from github – Published: 2025-05-07 15:31 – Updated: 2026-04-28 21:35
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in ThimPress WP Pipes allows Server Side Request Forgery. This issue affects WP Pipes: from n/a through 1.4.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-47664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-07T15:16:18Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in ThimPress WP Pipes allows Server Side Request Forgery. This issue affects WP Pipes: from n/a through 1.4.2.",
  "id": "GHSA-3px8-2p4q-xpwm",
  "modified": "2026-04-28T21:35:36Z",
  "published": "2025-05-07T15:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47664"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/wp-pipes/vulnerability/wordpress-wp-pipes-1-4-2-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3Q6G-QMPX-RQW4

Vulnerability from github – Published: 2024-03-14 20:37 – Updated: 2024-03-14 20:37
VLAI
Summary
Whoogle Search Server-Side Request Forgery vulnerability
Details

Whoogle Search is a self-hosted metasearch engine. In versions 0.8.3 and prior, the window endpoint does not sanitize user-supplied input from the location variable and passes it to the send method which sends a GET request on lines 339-343 in request.py, which leads to a server-side request forgery. This issue allows for crafting GET requests to internal and external resources on behalf of the server. For example, this issue would allow for accessing resources on the internal network that the server has access to, even though these resources may not be accessible on the internet. This issue is fixed in version 0.8.4.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "whoogle-search"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-22205"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-14T20:37:57Z",
    "nvd_published_at": "2024-01-23T18:15:18Z",
    "severity": "CRITICAL"
  },
  "details": "Whoogle Search is a self-hosted metasearch engine. In versions 0.8.3 and prior, the `window` endpoint does not sanitize user-supplied input from the `location` variable and passes it to the `send` method which sends a `GET` request on lines 339-343 in `request.py,` which leads to a server-side request forgery. This issue allows for crafting GET requests to internal and external resources on behalf of the server. For example, this issue would allow for accessing resources on the internal network that the server has access to, even though these resources may not be accessible on the internet. This issue is fixed in version 0.8.4.\n\n",
  "id": "GHSA-3q6g-qmpx-rqw4",
  "modified": "2024-03-14T20:37:57Z",
  "published": "2024-03-14T20:37:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22205"
    },
    {
      "type": "WEB",
      "url": "https://github.com/benbusby/whoogle-search/commit/3a2e0b262e4a076a20416b45e6b6f23fd265aeda"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/benbusby/whoogle-search"
    },
    {
      "type": "WEB",
      "url": "https://github.com/benbusby/whoogle-search/blob/92e8ede24e9277a5440d403f75877209f1269884/app/request.py#L339-L343"
    },
    {
      "type": "WEB",
      "url": "https://github.com/benbusby/whoogle-search/blob/92e8ede24e9277a5440d403f75877209f1269884/app/routes.py#L479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/benbusby/whoogle-search/blob/92e8ede24e9277a5440d403f75877209f1269884/app/routes.py#L496-L557"
    },
    {
      "type": "WEB",
      "url": "https://github.com/benbusby/whoogle-search/blob/92e8ede24e9277a5440d403f75877209f1269884/app/routes.py#L497"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/whoogle-search/PYSEC-2024-18.yaml"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2023-186_GHSL-2023-189_benbusby_whoogle-search"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Whoogle Search Server-Side Request Forgery vulnerability"
}

GHSA-3Q7G-M267-RP98

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

NVIDIA Dynamo for Linux contains a vulnerability where an attacker may cause server-side request forgery. A successful exploit of this vulnerability might lead to information disclosure.

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-2026-47614"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-04T18:16:50Z",
    "severity": "HIGH"
  },
  "details": "NVIDIA Dynamo for Linux contains a vulnerability where an attacker may cause server-side request forgery. A successful exploit of this vulnerability might lead to information disclosure.",
  "id": "GHSA-3q7g-m267-rp98",
  "modified": "2026-08-04T18:31:29Z",
  "published": "2026-08-04T18:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47614"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NVIDIA/product-security/tree/main/2026/5842"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47614"
    }
  ],
  "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-3Q8X-VX89-4P24

Vulnerability from github – Published: 2025-08-13 15:30 – Updated: 2025-08-13 21:30
VLAI
Details

Server side request forgery (SSRF) vulnerability in makeplane plane 0.23.1 via the password recovery.

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-50251"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-13T15:15:34Z",
    "severity": "CRITICAL"
  },
  "details": "Server side request forgery (SSRF) vulnerability in makeplane plane 0.23.1 via the password recovery.",
  "id": "GHSA-3q8x-vx89-4p24",
  "modified": "2025-08-13T21:30:27Z",
  "published": "2025-08-13T15:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50251"
    },
    {
      "type": "WEB",
      "url": "https://packetstorm.news/files/id/190475"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/52211"
    }
  ],
  "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-3QHM-QFJ3-4RRX

Vulnerability from github – Published: 2022-05-13 01:06 – Updated: 2024-02-06 18:00
VLAI
Summary
elFinder Server Side Request Forgery (SSRF)
Details

A Server Side Request Forgery (SSRF) vulnerability in elFinder before 2.1.49 could allow a malicious user to access the content of internal network resources. This occurs in get_remote_contents() in php/elFinder.class.php.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "studio-42/elfinder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.49"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-6257"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-10T19:31:04Z",
    "nvd_published_at": "2019-01-14T08:29:00Z",
    "severity": "HIGH"
  },
  "details": "A Server Side Request Forgery (SSRF) vulnerability in elFinder before 2.1.49 could allow a malicious user to access the content of internal network resources. This occurs in `get_remote_contents()` in `php/elFinder.class.php`.",
  "id": "GHSA-3qhm-qfj3-4rrx",
  "modified": "2024-02-06T18:00:03Z",
  "published": "2022-05-13T01:06:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6257"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Studio-42/elFinder/commit/2f522db8f037a66ce9040ee0b216aa4a0359286c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/studio-42/elfinder/CVE-2019-6257.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Studio-42/elFinder"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Studio-42/elFinder/blob/2.1.49/Changelog"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Studio-42/elFinder/releases/tag/2.1.49"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "elFinder Server Side Request Forgery (SSRF)"
}

GHSA-3QMC-RWV9-Q36H

Vulnerability from github – Published: 2026-09-26 03:30 – Updated: 2026-09-26 03:30
VLAI
Details

OpenClaw versions before 2026.8.1 fail to validate video asset URLs returned by providers, allowing server-side requests to private destinations. A malicious or compromised provider can return private or loopback URLs to cause the CLI to make requests to internal services accessible from the OpenClaw host.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-100577"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-26T03:17:05Z",
    "severity": "MODERATE"
  },
  "details": "OpenClaw versions before 2026.8.1 fail to validate video asset URLs returned by providers, allowing server-side requests to private destinations. A malicious or compromised provider can return private or loopback URLs to cause the CLI to make requests to internal services accessible from the OpenClaw host.",
  "id": "GHSA-3qmc-rwv9-q36h",
  "modified": "2026-09-26T03:30:27Z",
  "published": "2026-09-26T03:30:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-fvxr-9g24-x3hf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100577"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-before-2026.8.1-server-side-request-forgery-via-video-asset"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3QQC-XVF4-H32Q

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

OX App Suite through 7.10.3 allows SSRF via the the /ajax/messaging/message message API.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-15002"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-23T05:15:00Z",
    "severity": "MODERATE"
  },
  "details": "OX App Suite through 7.10.3 allows SSRF via the the /ajax/messaging/message message API.",
  "id": "GHSA-3qqc-xvf4-h32q",
  "modified": "2022-05-24T17:31:56Z",
  "published": "2022-05-24T17:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15002"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/fulldisclosure/2020/Oct/20"
    },
    {
      "type": "WEB",
      "url": "https://www.open-xchange.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3QWH-W55V-784G

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

Appspace 6.2.4 allows SSRF via the api/v1/core/proxy/jsonprequest url parameter.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-27670"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-25T01:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Appspace 6.2.4 allows SSRF via the api/v1/core/proxy/jsonprequest url parameter.",
  "id": "GHSA-3qwh-w55v-784g",
  "modified": "2022-05-24T17:43:03Z",
  "published": "2022-05-24T17:43:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27670"
    },
    {
      "type": "WEB",
      "url": "https://github.com/h3110mb/PoCSSrfApp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3QX3-XHMF-4JCC

Vulnerability from github – Published: 2023-11-29 09:30 – Updated: 2023-11-29 09:30
VLAI
Details

A server-side request forgery vulnerability in ESM prior to version 11.6.8 allows a low privileged authenticated user to upload arbitrary content, potentially altering configuration. This is possible through the certificate validation functionality where the API accepts uploaded content and doesn't parse for invalid data

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-6070"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-29T09:15:21Z",
    "severity": "MODERATE"
  },
  "details": "\nA server-side request forgery vulnerability in ESM prior to version 11.6.8 allows a low privileged authenticated user to upload arbitrary content, potentially altering configuration. This is possible through the certificate validation functionality where the API accepts uploaded content and doesn\u0027t parse for invalid data\n\n",
  "id": "GHSA-3qx3-xhmf-4jcc",
  "modified": "2023-11-29T09:30:27Z",
  "published": "2023-11-29T09:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6070"
    },
    {
      "type": "WEB",
      "url": "https://kcm.trellix.com/corporate/index?page=content\u0026id=SB10413"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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