CVE-2026-54494 in Koel
Summary
by MITRE • 08/20/2026
Koel is a free, open-source music streaming solution. Prior to 9.7.1, App\Helpers\Network::isPublicHost() uses filter_var() with FILTER_FLAG_NO_PRIV_RANGE and FILTER_FLAG_NO_RES_RANGE, which treats NAT64 64:ff9b::/96 and 6to4 2002::/16 wrappers of private, loopback, or link-local IPv4 addresses as public. An authenticated user can place such an address in a podcast RSS <enclosure url> and reach app/Values/Podcast/EpisodePlayable.php through EpisodePlayable::createForEpisode(), where isSafeUrl() accepts the target and Http::sink($file)->get($url) fetches it. On a host with NAT64 or 6to4 routing, Koel can request internal services or cloud metadata and return the response body to the user. This issue is fixed in version 9.7.1
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Koel prior to version 9.7.1 represents a critical Server-Side Request Forgery (SSRF) flaw rooted in improper validation of network addresses within the application's helper logic. Specifically, the App\Helpers\Network::isPublicHost() function relies on PHP’s filter_var() function with flags FILTER_FLAG_NO_PRIV_RANGE and FILTER_FLAG_NO_RES_RANGE to determine if an IP address is public. This approach fails to account for IPv6 transition mechanisms such as NAT64 (prefix 64:ff9b::/96) and 6to4 (prefix 2002::/16). These prefixes are designed to encapsulate private, loopback, or link-local IPv4 addresses within IPv6 packets. Consequently, when an attacker provides a specially crafted IPv6 address that maps to an internal resource via these transition mechanisms, the validation logic incorrectly classifies it as a public internet host, thereby bypassing security controls intended to restrict external requests to non-internal destinations.
An authenticated user can exploit this flaw by manipulating podcast RSS feed data. By injecting a malicious URL into the enclosure tag of an RSS item that utilizes one of these vulnerable IPv6 prefixes pointing to internal services or cloud metadata endpoints, the attacker triggers the application's media processing pipeline. The flow proceeds through EpisodePlayable::createForEpisode(), which calls isSafeUrl() and subsequently Http::sink($file)->get($url). Because the initial IP validation was bypassed due to the NAT64 or 6to4 mapping error, the HTTP client successfully connects to internal targets that should have been blocked. On systems configured with NAT64 or 6to4 routing capabilities, this allows the Koel server to act as a proxy for requests directed at local network services, database interfaces, API endpoints, or cloud instance metadata services such as AWS EC2 or Azure IMDS.
The operational impact of this vulnerability is severe, particularly in environments where internal services are not adequately segmented from web-facing applications. Successful exploitation enables an authenticated attacker to perform port scanning, service fingerprinting, and data exfiltration from the server's local network. Furthermore, access to cloud metadata endpoints can lead to credential theft or full instance compromise if combined with other vulnerabilities. This behavior aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where a web application fetches a remote resource without validating the user-supplied URL. In terms of offensive security frameworks, this vulnerability maps directly to MITRE ATT&CK technique T1059.004, Command and Scripting Interpreter via System Network Utilities, specifically leveraging SSRF for lateral movement or data access within the network perimeter.
Mitigation requires immediate upgrading to Koel version 9.7.1 or later, where the validation logic has been corrected to properly handle IPv6 transition prefixes and internal address ranges. For organizations unable to patch immediately, implementing a strict allowlist of permitted external domains at the application level can reduce exposure. Additionally, network-level controls such as egress filtering should be enforced on Koel servers to prevent outbound connections to private IP ranges regardless of application-layer validation failures. Deploying Web Application Firewalls with SSRF detection capabilities may also provide an additional layer of defense by inspecting outgoing requests for patterns indicative of internal address access or cloud metadata queries.