<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 15 Oct 2026 15:33:29 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-356644</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-356644</link>
      <description>EUVD-2026-356644</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-356644</guid>
    </item>
    <item>
      <title>fkie_cve-2026-54492</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-54492</link>
      <description>&lt;p&gt;Koel is a free, open-source music streaming solution. Prior to 9.7.0, the Subsonic-compatible createPodcastChannel.view route accepts an authenticated user&amp;#39;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Koel is a free, open-source music streaming solution. Prior to 9.7.0, the Subsonic-compatible createPodcastChannel.view route accepts an authenticated user&amp;#39;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-54492</guid>
    </item>
    <item>
      <title>GHSA-w79m-f3jx-779v — Koel: Authenticated Blind SSRF via Subsonic Podcast Channel Creation</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-w79m-f3jx-779v</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: phanan/koel&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;This was validated against `v9.6.0` (`352ea5ec27fa22294da8fb6beacb3d5552f0d09c`) using the official `phanan/koel:9.6.0` image.&lt;/p&gt;
&lt;p&gt;This is distinct from `GHSA-7j2f-6h2r-6cqc`, which fixed unsafe episode enclosure URLs in versions `&amp;lt;= 9.3.4`. The issue here is a newer validation gap in the Subsonic route itself, still present in `v9.6.0`.&lt;/p&gt;
&lt;p&gt;### Details
#### SafeUrl protects the regular podcast API only&lt;/p&gt;
&lt;p&gt;The regular podcast subscription path validates the feed URL with `SafeUrl`:&lt;/p&gt;
&lt;p&gt;- `app/Http/Requests/API/Podcast/PodcastStoreRequest.php`&lt;/p&gt;
&lt;p&gt;```php
return [
    &amp;#39;url&amp;#39; =&amp;gt; [&amp;#39;required&amp;#39;, &amp;#39;url&amp;#39;, new SafeUrl()],
];
```&lt;/p&gt;
&lt;p&gt;The Subsonic-compatible route does not:&lt;/p&gt;
&lt;p&gt;- `routes/subsonic.php`
  - `createPodcastChannel.view`
- `app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php`&lt;/p&gt;
&lt;p&gt;```php
return [
    &amp;#39;url&amp;#39; =&amp;gt; [&amp;#39;required&amp;#39;, &amp;#39;string&amp;#39;, &amp;#39;url&amp;#39;],
];
```&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;#### The URL is fetched immediately by the podcast parser&lt;/p&gt;
&lt;p&gt;The attacker-controlled URL is used by the podcast service during channel creation:&lt;/p&gt;
&lt;p&gt;- `app/Http/Controllers/Subsonic/CreatePodcastChannelControl…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: phanan/koel&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;This was validated against `v9.6.0` (`352ea5ec27fa22294da8fb6beacb3d5552f0d09c`) using the official `phanan/koel:9.6.0` image.&lt;/p&gt;
&lt;p&gt;This is distinct from `GHSA-7j2f-6h2r-6cqc`, which fixed unsafe episode enclosure URLs in versions `&amp;lt;= 9.3.4`. The issue here is a newer validation gap in the Subsonic route itself, still present in `v9.6.0`.&lt;/p&gt;
&lt;p&gt;### Details
#### SafeUrl protects the regular podcast API only&lt;/p&gt;
&lt;p&gt;The regular podcast subscription path validates the feed URL with `SafeUrl`:&lt;/p&gt;
&lt;p&gt;- `app/Http/Requests/API/Podcast/PodcastStoreRequest.php`&lt;/p&gt;
&lt;p&gt;```php
return [
    &amp;#39;url&amp;#39; =&amp;gt; [&amp;#39;required&amp;#39;, &amp;#39;url&amp;#39;, new SafeUrl()],
];
```&lt;/p&gt;
&lt;p&gt;The Subsonic-compatible route does not:&lt;/p&gt;
&lt;p&gt;- `routes/subsonic.php`
  - `createPodcastChannel.view`
- `app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php`&lt;/p&gt;
&lt;p&gt;```php
return [
    &amp;#39;url&amp;#39; =&amp;gt; [&amp;#39;required&amp;#39;, &amp;#39;string&amp;#39;, &amp;#39;url&amp;#39;],
];
```&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;#### The URL is fetched immediately by the podcast parser&lt;/p&gt;
&lt;p&gt;The attacker-controlled URL is used by the podcast service during channel creation:&lt;/p&gt;
&lt;p&gt;- `app/Http/Controllers/Subsonic/CreatePodcastChannelControl…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-w79m-f3jx-779v</guid>
    </item>
  </channel>
</rss>
