Koel: Server-Side Request Forgery (SSRF) in radio station creation due to missing validation bail

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:

• routes/api.base.php line 108 wraps the route group in Route::middleware('auth') only.
• routes/api.base.php line 268: Route::apiResource('stations', RadioStationController::class).
• RadioStationController::store() (lines 31-37) carries only #[DisabledInDemo] — no $this->authorize(...), no #[RequiresPlus], no permission check.

Reachability Oracle (Information Disclosure)

HasAudioContentType::validate() returns two distinct messages:

• Host unreachable / request throws → "The url couldn't be reached." (line 26)
• Host reachable but Content-Type is not audio/* → "The url doesn't look like a valid radio station URL." (line 32)

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"
}

• If the internal service answers → "The url doesn't look like a valid radio station URL."
• If nothing is listening → "The url couldn't be reached."

The server has now issued a HEAD and a streaming GET to 127.0.0.1:6379 despite SafeUrl having rejected it.

Impact

• 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).
• Internal reachability oracle: reliable live-host / open-port discovery via the two distinct error strings.
• Side-effect requests: any internal endpoint that performs a state-changing action on GET/HEAD can be triggered.

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

• 2026-05-30: Identified via source review of v9.5.0 (b2e9a34).
• 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.

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.