Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Koel's outbound-URL guard App\Helpers\Network::isPublicHost() classifies an IP as "public" using PHP's filtervar($ip, FILTERVALIDATEIP, FILTERFLAGNOPRIVRANGE | FILTERFLAGNORESRANGE). That flag set does not recognise IPv6 transition-address forms that embed a private/loopback/link-local IPv4: NAT64 well-known prefix 64:ff9b::/96 (RFC 6052) and 6to4 2002::/16 (RFC 3056). An address such as 64:ff9b::7f00:1 (= 127.0.0.1), 64:ff9b::a9fe:a9fe (= 169.254.169.254, the cloud metadata endpoint), or 2002:a00:1:: (= 10.0.0.1) is reported as a public address, so the guard returns true and Koel proceeds to fetch the URL. The guard is the only SSRF defense in front of App\Values\Podcast\EpisodePlayable::createForEpisode(), which downloads a podcast episode with Http::sink($file)-get($url) and streams the response body back to the requesting user. Because an attacker fully controls the <enclosure url of any RSS feed they host (and any authenticated user can subscribe to a feed), they can…
Recommended action: Upgrade to 9.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Koel v9.5.0 contains a Server-Side Request Forgery (SSRF) vulnerability in the radio station creation endpoint (POST /api/radio/stations). The url field validation rules are declared without the bail keyword, so the HasAudioContentType rule — which issues HTTP requests to the supplied URL — still executes even after the SafeUrl rule has rejected the URL as pointing to a private/reserved address. Any authenticated, non-admin user can therefore coerce the server into making HEAD/GET requests to arbitrary internal hosts. This is a blind SSRF: the response body is never returned to the client, but the two distinct validation error messages form a reliable internal-network reachability oracle. Severity Medium — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (5.4) Authenticated (low-privilege) actor; blind SSRF (no response-body exfiltration). Confidentiality (L) reflects the internal reachability oracle; Integrity (L) reflects state-changing internal endpoints that act on GET/HEAD.…
Recommended action: Upgrade to 9.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for CVE-2026-47260 (v9.3.5) added an initial isSafeUrl() check to several fetchers (synchronizeEpisodes, getStreamableUrl, AddRadioStation, EpisodePlayable), but the redirect-target validation — the per-hop Guzzle onredirect callback added in follow-up commit be1e867 — was applied to only one path, EpisodePlayable. Every other server-side fetcher therefore has only the initial check, which an HTTP 302 redirect to an internal address bypasses, or no check at all. DNS rebinding (validation and connection resolve DNS separately, with no IP pinning) bypasses the initial check on every path. An authenticated, non-admin user can thus cause the Koel server to issue requests to arbitrary internal / cloud-metadata endpoints (SSRF) by supplying a URL on an attacker-controlled host that 302-redirects to an internal address. Note: commit be1e867 shows the redirect-based SSRF vector was recognised, but the redirect defense was applied to a single call site rather than generalised…
Recommended action: Upgrade to 9.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Koel's Subsonic createPodcastChannel.view endpoint accepts a user supplied podcast feed URL and fetches it server-side before applying the safe URL checks that are used for podcast episode enclosure URLs. An authenticated Subsonic API user can provide a loopback or internal URL as the feed URL and cause the Koel backend to issue a request to that address. A related redirect gap exists in the podcast stream helper: PodcastService::getStreamableUrl() validates only the original URL, then lets Guzzle follow redirects and accepts the final redirected URL without re-validating it. Impact An attacker with any valid Koel account and Subsonic API key can trigger server-side requests from the Koel host to loopback or internal network services. This can be used for blind SSRF against internal HTTP endpoints reachable by the Koel deployment. If an internal service returns valid RSS/XML or permissive CORS responses, parts of the response or final URL may be reflected back through normal…
Recommended action: Upgrade to 9.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Koel v9.6.0 validates radio station URLs on the regular web API, but the Subsonic-compatible radio endpoints do not apply the same SSRF protections. An authenticated user can create or update a radio station with a private URL and then use Koel's radio streaming feature to make the server fetch that URL and return the upstream response body. This was validated against v9.6.0 (352ea5ec27fa22294da8fb6beacb3d5552f0d09c) using the official phanan/koel:9.6.0 image. Details SafeUrl is applied on the web API, but not on the Subsonic endpoints Koel's regular radio API protects station URLs with SafeUrl and HasAudioContentType: - app/Http/Requests/API/Radio/RadioStationStoreRequest.php - app/Http/Requests/API/Radio/RadioStationUpdateRequest.php The Subsonic-compatible routes do not reuse those checks: - routes/subsonic.php - createInternetRadioStation.view - updateInternetRadioStation.view - app/Http/Requests/Subsonic/CreateInternetRadioStationRequest.php -…
Recommended action: Upgrade to 9.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 The Subsonic-compatible route does not: - routes/subsonic.php - createPodcastChannel.view - app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php That creates the same kind of trust-boundary…
Recommended action: Upgrade to 9.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Koel validates the podcast feed URL via the SafeUrl rule (DNS resolution + public IP check), but the individual episode <enclosure url="..." values extracted from the RSS XML are stored directly into the database without any SSRF validation. When a user plays an episode, the server downloads the full HTTP response from the unvalidated enclosure URL via Http::sink()-get() and streams it back to the user, enabling full-read SSRF against internal services. --- Vulnerability Details Episode URL Stored Without Validation File: app/Services/Podcast/PodcastService.php, line 146 The SafeUrl rule is applied to the podcast feed URL at subscription time (SubscribeToPodcastRequest), but episode enclosure URLs parsed from the feed XML are stored as-is. SSRF Trigger: Full Content Download File: app/Values/Podcast/EpisodePlayable.php, line 42 When an episode is played, PodcastStreamerAdapter::stream() first attempts getStreamableUrl() (OPTIONS/HEAD requests to the episode URL). If no CORS…
Recommended action: Upgrade to 9.3.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Koel before 5.1.4 lacks login throttling, lacks a password strength policy, and shows whether a failed login attempt had a valid username. This might make brute-force attacks easier.
Recommended action: Upgrade to 5.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.