CVE-2026-54492 in Koel
Summary
by MITRE • 08/20/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
Koel is an open-source music streaming application that provides a Subsonic-compatible API for client compatibility. A significant security vulnerability exists within the createPodcastChannel.view endpoint, which allows authenticated users to supply arbitrary URLs during podcast channel creation. Prior to version 9.7.0, the input validation logic in app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php fails to enforce the SafeUrl constraints that are applied to other parts of the podcast API. This inconsistency creates a gap where user-supplied input is passed directly into internal service layers without adequate sanitization or restriction on destination addresses.
The technical flaw manifests when the controller passes the unvalidated URL to PodcastService::addPodcast(), which subsequently invokes Poddle::fromUrl(). This function triggers an immediate HTTP request from the server to the provided address. Because there are no restrictions preventing access to internal network ranges, attackers can craft requests targeting loopback interfaces, Docker bridge networks, or private RFC1918 IP addresses. This behavior classifies as a Server-Side Request Forgery vulnerability, specifically enabling blind SSRF where the attacker cannot directly observe the response body but can infer information based on timing differences or side-channel effects such as port scanning internal services.
The operational impact of this flaw is primarily limited to reconnaissance and potential interaction with internal microservices that may lack proper authentication mechanisms. Since generic response-body exfiltration was not demonstrated, the immediate risk involves probing for vulnerable internal endpoints rather than direct data theft through this specific vector. However, in environments where internal services are exposed without additional security controls, an attacker could potentially interact with administrative interfaces or sensitive APIs residing on private networks. This aligns with CWE-918, which addresses Server-Side Request Forgery, and maps to the ATT&CK technique T1571 for establishing connections to internal resources via proxying through a compromised application server.
Mitigation strategies involve upgrading Koel to version 9.7.0 or later, where this validation gap has been addressed by applying consistent SafeUrl checks across all relevant API routes. For organizations unable to upgrade immediately, implementing network-level controls such as firewall rules that block outbound HTTP requests from the application host to private IP ranges can provide effective defense in depth. Additionally, ensuring that internal services are not directly accessible from the public-facing web server layer reduces the attack surface for any potential SSRF exploitation attempts.