Most recent entries from all

EUVD-2026-356644

2026-10-15T16:30:52.892789+00:00

EUVD-2026-356644

fkie_cve-2026-54492

2026-10-15T16:30:52.892818+00:00

Koel is a free, open-source music streaming solution. Prior to 9.7.0, the Subsonic-compatible createPodcastChannel.view route accepts an authenticated user's private URL because app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php does not apply the SafeUrl validation used by the regular podcast API. app/Http/Controllers/Subsonic/CreatePodcastChannelController.php passes the URL to app/Services/Podcast/PodcastService.php, where PodcastService::addPodcast() and createParser() invoke Poddle::fromUrl() during channel creation, causing immediate server-side requests to loopback, Docker bridge, or RFC1918 HTTP destinations. The confirmed impact is blind internal request execution because generic response-body exfiltration was not demonstrated through this route. This issue is fixed in version 9.7.0.

GHSA-w79m-f3jx-779v — Koel: Authenticated Blind SSRF via Subsonic Podcast Channel Creation

2026-10-15T16:30:52.892853+00:00

Affected: Packagist: phanan/koel

### Summary Koel `v9.6.0` protects the regular podcast subscription API with `SafeUrl`, but the Subsonic-compatible `createPodcastChannel.view` route does not apply the same protection. An authenticated user can supply a private URL and cause Koel to fetch it server-side during podcast parsing.

This was validated against `v9.6.0` (`352ea5ec27fa22294da8fb6beacb3d5552f0d09c`) using the official `phanan/koel:9.6.0` image.

This is distinct from `GHSA-7j2f-6h2r-6cqc`, which fixed unsafe episode enclosure URLs in versions `<= 9.3.4`. The issue here is a newer validation gap in the Subsonic route itself, still present in `v9.6.0`.

### Details #### SafeUrl protects the regular podcast API only

The regular podcast subscription path validates the feed URL with `SafeUrl`:

- `app/Http/Requests/API/Podcast/PodcastStoreRequest.php`

```php return [ 'url' => ['required', 'url', new SafeUrl()], ]; ```

The Subsonic-compatible route does not:

- `routes/subsonic.php` - `createPodcastChannel.view` - `app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php`

```php return [ 'url' => ['required', 'string', 'url'], ]; ```

That creates the same kind of trust-boundary mismatch as the radio issue: the main API rejects private targets, while the compatibility route accepts them.

#### The URL is fetched immediately by the podcast parser

The attacker-controlled URL is used by the podcast service during channel creation:

- `app/Http/Controllers/Subsonic/CreatePodcastChannelControl…