CVE-2026-50552: Koel Server-Side Request Forgery (SSRF) Vulnerability
MODERATECVE-2026-50552 is a MODERATE (CVSS 6.3) server-side request forgery (ssrf) vulnerability (CWE-918: Server-Side Request Forgery (SSRF)) affecting Koel libraries in the Packagist ecosystem. The issue involves server-side request forgery (ssrf) in radio station creation due to missing validation bail. Remediation is available by upgrading affected packages to version 9.7.1.
CVE-2026-50552 at a Glance
Security Impact
CVSS: 6.3
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L).
How to Fix CVE-2026-50552
To remediate this vulnerability, upgrade all affected Koel dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade phanan/koel to 9.7.1
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for phanan/koel
How to Check if You Are Affected
To determine whether your application is affected by CVE-2026-50552, inspect your project dependencies for Koel:
inspect dependencies for phanan/koel
Analyze the terminal output to locate any version of Koel in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 9.7.1), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-918: Server-Side Request Forgery (SSRF), where 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. In Koel, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-50552 Affected Koel Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
phanan/koel
|
Packagist |
< 9.7.1
|
9.7.1
|
References
Frequently Asked Questions
What is CVE-2026-50552?
Which Koel versions are affected?
What version fixes CVE-2026-50552?
Is phanan/koel affected?
What is the CVSS score of CVE-2026-50552?
What CWE is associated with CVE-2026-50552?
How can I check Packagist dependencies for CVE-2026-50552?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-jr4p-4xjh-fwvw",
"modified" : "2026-07-15T18:21:04Z",
"published" : "2026-07-15T18:21:04Z",
"aliases" : [ "CVE-2026-50552" ],
"summary" : "Koel: Server-Side Request Forgery (SSRF) in radio station creation due to missing validation bail",
"details" : "Summary\n\nKoel v9.5.0 contains a Server-Side Request Forgery (SSRF) vulnerability in the radio station creation endpoint (POST /api/radio/stations). The url field validation rules are declared without the bail keyword, so the HasAudioContentType rule — which issues HTTP requests to the supplied URL — still executes even after the SafeUrl rule has rejected the URL as pointing to a private/reserved address. Any authenticated, non-admin user can therefore coerce the server into making HEAD/GET requests to arbitrary internal hosts.\n\nThis is a blind SSRF: the response body is never returned to the client, but the two distinct validation error messages form a reliable internal-network reachability oracle.\n\nSeverity\n\nMedium — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (5.4)\n\nAuthenticated (low-privilege) actor; blind SSRF (no response-body exfiltration). Confidentiality (L) reflects the internal reachability oracle; Integrity (L) reflects state-changing internal endpoints that act on GET/HEAD.\n\nAffected Component\n\n- Version: Koel v9.5.0 (latest release, HEAD b2e9a34, verified 2026-05-30)\n- Endpoint: POST /api/radio/stations\n- Files:\n - app/Http/Requests/API/Radio/RadioStationStoreRequest.php (missing bail)\n - app/Rules/HasAudioContentType.php (unguarded HTTP fetch)\n\nRoot Cause\n\napp/Http/Requests/API/Radio/RadioStationStoreRequest.php (lines 25-34):\n\n 'url' => [\n 'required',\n 'url',\n Rule::unique('radio_stations')->where(function ($query) {\n return $query->where('user_id', $this->user()->id);\n }),\n new SafeUrl(),\n new HasAudioContentType(),\n ],\n\nIn Laravel, validation rules within a single attribute run in sequence and do not stop on the first failure unless bail is present or FormRequest::$stopOnFirstFailure is set. Neither is the case here (App\\Http\\Requests\\Request does not override stopOnFirstFailure, and authorize() simply returns true).\n\nFor a directly-supplied private/reserved address (e.g. http://169.254.169.254, http://127.0.0.1:6379, http://192.168.0.1):\n\n1. SafeUrl (app/Rules/SafeUrl.php lines 45-49) calls isPublicHost($uri->host()), fails it, calls $fail(...) and returns. SafeUrl itself does not make a request in this path — good.\n2. Because there is no bail, validation continues to HasAudioContentType.\n3. HasAudioContentType::resolveContentType() (app/Rules/HasAudioContentType.php lines 41-57) issues the request with no IP/host validation of its own:\n\n private function resolveContentType(string $url): string\n {\n try {\n $response = Http::head($url); // <-- SSRF\n if ($response->successful()) {\n return $response->header('Content-Type');\n }\n } catch (Throwable) { }\n \n // Falls back to a streaming GET\n $response = Http::withHeaders(['Icy-MetaData' => '1'])\n ->withOptions(['stream' => true])\n ->get($url); // <-- SSRF\n return $response->header('Content-Type');\n }\n\nThe rule's own docblock (line 13-14) states \"Should be used after SafeUrl to ensure the URL is safe to reach.\" — that assumption is silently violated by the missing bail.\n\nAuthorization Context\n\nThe endpoint is reachable by any authenticated user, not just admins:\n\n- routes/api.base.php line 108 wraps the route group in Route::middleware('auth') only.\n- routes/api.base.php line 268: Route::apiResource('stations', RadioStationController::class).\n- RadioStationController::store() (lines 31-37) carries only #[DisabledInDemo] — no $this->authorize(...), no #[RequiresPlus], no permission check.\n\nReachability Oracle (Information Disclosure)\n\nHasAudioContentType::validate() returns two distinct messages:\n\n- Host unreachable / request throws → \"The url couldn't be reached.\" (line 26)\n- Host reachable but Content-Type is not audio/* → \"The url doesn't look like a valid radio station URL.\" (line 32)\n\nBy diffing these responses an attacker can enumerate which internal hosts/ports are live behind the firewall (internal host discovery and coarse port scanning).\n\nProof of Concept\n\nAs any regular authenticated user:\n\n POST /api/radio/stations HTTP/1.1\n Host: koel.example.com\n Authorization: Bearer <regular_user_token>\n Content-Type: application/json\n \n {\n \"name\": \"probe\",\n \"url\": \"http://127.0.0.1:6379\"\n }\n\n- If the internal service answers → \"The url doesn't look like a valid radio station URL.\"\n- If nothing is listening → \"The url couldn't be reached.\"\n\nThe server has now issued a HEAD and a streaming GET to 127.0.0.1:6379 despite SafeUrl having rejected it.\n\nImpact\n\n- Blind SSRF: server-side HEAD/GET to attacker-chosen internal addresses. The response body is never returned to the client, so this cannot directly exfiltrate content (e.g. cloud-metadata bodies).\n- Internal reachability oracle: reliable live-host / open-port discovery via the two distinct error strings.\n- Side-effect requests: any internal endpoint that performs a state-changing action on GET/HEAD can be triggered.\n\nNote on scope: because SafeUrl calls $fail() for a private host, the overall request validation fails (Laravel aggregates all rule failures; a single failure yields a 422), so RadioStationController::store() never runs and no station is persisted. The impact is therefore limited to the out-of-band HEAD/GET requests issued by HasAudioContentType during validation, plus the reachability oracle — it does not chain into a stored station or into the authenticated radio stream proxy via this path.\n\nRecommended Fix\n\nAdd bail so HasAudioContentType only runs after SafeUrl passes, restoring the rule's documented precondition:\n\n 'url' => [\n 'required',\n 'url',\n 'bail',\n Rule::unique('radio_stations')->where(/* ... */),\n new SafeUrl(),\n new HasAudioContentType(),\n ],\n\n(Place bail before SafeUrl/HasAudioContentType; the unique check is local DB only and safe to keep ahead of it if preferred.)\n\nDefense in depth\n\nHave HasAudioContentType::resolveContentType() re-validate the host with Network::isPublicHost() (or reuse Network::isSafeUrl()) before issuing any request, so the rule is safe regardless of ordering. The same Network helper is already used by PodcastService for enclosure URLs.\n\nRelationship to CVE-2026-47260\n\nCVE-2026-47260 addressed SSRF via podcast episode enclosure URLs; the current code guards that sink in app/Services/Podcast/PodcastService.php (line 143) with Network::isSafeUrl(). The radio-station path relies instead on the SafeUrl validation rule, but the missing bail lets the adjacent HasAudioContentType fetch run anyway — leaving an SSRF reachable from the same class of untrusted, user-supplied URLs. I have not been able to confirm the exact upstream fix commit for CVE-2026-47260 from the release tarball, so I am presenting this as an independent finding rather than asserting it is the same code change.\n\nDisclosure\n\n- 2026-05-30: Identified via source review of v9.5.0 (b2e9a34).\n- Verified entirely by source inspection (route middleware, controller, FormRequest base class, and both validation rules). No live PoC was executed against a third-party host.\n\nIf the maintainers agree this is a distinct issue, would you consider requesting a CVE identifier for it through GitHub Security Advisories? Happy to provide any further detail or testing.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Packagist",
"name" : "phanan/koel"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "9.7.1"
} ]
} ],
"database_specific" : {
"last_known_affected_version_range" : "<= 9.7.0"
}
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/koel/koel/security/advisories/GHSA-jr4p-4xjh-fwvw"
}, {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-50552"
}, {
"type" : "WEB",
"url" : "https://github.com/koel/koel/pull/2549"
}, {
"type" : "WEB",
"url" : "https://github.com/koel/koel/commit/5f6ce2cefd08f437a269236b677ad971517ccbb6"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/koel/koel"
}, {
"type" : "WEB",
"url" : "https://github.com/koel/koel/releases/tag/v9.7.1"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-918" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-07-15T18:21:04Z",
"nvd_published_at" : "2026-06-12T20:16:47Z"
}
}