CVE-2026-50552

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

• Version: Koel v9.5.0 (latest release, HEAD b2e9a34, verified 2026-05-30)
• Endpoint: POST /api/radio/stations
• Files:
  • app/Http/Requests/API/Radio/RadioStationStoreRequest.php (missing bail)
  • app/Rules/HasAudioContentType.php (unguarded HTTP fetch)

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):

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.

2. Because there is no bail, validation continues to HasAudioContentType.

3. 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:

• 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.

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.