Packagist · phanan/koel
Koel: Server-Side Request Forgery (SSRF) in radio station creation due to missing validation bail
Summary
Koel 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.
This 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.
Severity
Medium — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (5.4)
Authenticated (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.
Affected Component
Root Cause
app/Http/Requests/API/Radio/RadioStationStoreRequest.php (lines 25-34):
'url' => [
'required',
'url',
Rule::unique('radio_stations')->where(function ($query) {
return $query->where('user_id', $this->user()->id);
}),
new SafeUrl(),
new HasAudioContentType(),
],
In 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).
For a directly-supplied private/reserved address (e.g. http://169.254.169.254, http://127.0.0.1:6379, http://192.168.0.1):
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.
Because there is no bail, validation continues to HasAudioContentType.
HasAudioContentType::resolveContentType() (app/Rules/HasAudioContentType.php lines 41-57) issues the request with no IP/host validation of its own:
private function resolveContentType(string $url): string { try { $response = Http::head($url); // <-- SSRF if ($response->successful()) { return $response->header('Content-Type'); } } catch (Throwable) { } // Falls back to a streaming GET $response = Http::withHeaders(['Icy-MetaData' => '1']) ->withOptions(['stream' => true]) ->get($url); // <-- SSRF return $response->header('Content-Type'); }
The 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.
Authorization Context
The endpoint is reachable by any authenticated user, not just admins:
Reachability Oracle (Information Disclosure)
HasAudioContentType::validate() returns two distinct messages:
By diffing these responses an attacker can enumerate which internal hosts/ports are live behind the firewall (internal host discovery and coarse port scanning).
Proof of Concept
As any regular authenticated user:
POST /api/radio/stations HTTP/1.1
Host: koel.example.com
Authorization: Bearer <regular_user_token>
Content-Type: application/json
{
"name": "probe",
"url": "http://127.0.0.1:6379"
}
The server has now issued a HEAD and a streaming GET to 127.0.0.1:6379 despite SafeUrl having rejected it.
Impact
Note 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.
Recommended Fix
Add bail so HasAudioContentType only runs after SafeUrl passes, restoring the rule's documented precondition:
'url' => [
'required',
'url',
'bail',
Rule::unique('radio_stations')->where(/* ... */),
new SafeUrl(),
new HasAudioContentType(),
],
(Place bail before SafeUrl/HasAudioContentType; the unique check is local DB only and safe to keep ahead of it if preferred.)
Defense in depth
Have 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.
Relationship to CVE-2026-47260
CVE-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.
Disclosure
If 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.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.