This SSRF in Koel's podcast RSS ingestion is worse than the CVSS suggests. The vulnerability materializes audio content from enclosure URLs through Http::sink()->get(), which means an attacker doesn't need to be present at exploitation time—they inject a malicious RSS feed once, and every user who later streams that episode triggers the request to the target endpoint. The payload is stored in the feed itself, not in a one-time attacker-crafted request.
On cloud-hosted instances (AWS, GCP, Azure), the 169.254.169.254 metadata endpoint is reachable from within the network boundary. This SSRF puts an authenticated user inside that boundary. The difference between 'internal service enumeration' and 'temporary AWS credentials exfiltrated' is categorical, not scalar—CVSS doesn't weight cloud-metadata-access as a distinct impact class, but you should.
The authentication requirement is weaker than it appears. A music streaming app typically allows any registered user—no verification tier, no trusted-entity status. The barrier to exploitation is 'has an account,' not 'has elevated privileges.'
For defenders: verify whether podcast RSS ingestion is enabled in your deployment. If it is, treat any imported feed as untrusted input that can trigger outbound requests from your infrastructure. Check whether the 9.7.1 patch restructures the URL fetching to use network isolation or a safelist, or merely patches the isPublicHost() filter—patching the filter is whack-a-mole given the documented history of IPv6 transition mechanism bypasses in PHP's filter_var(). If podcast support isn't essential to your use case, disabling it eliminates the entire attack surface. Monitor for outbound requests to 169.254.169.254 from your Koel infrastructure, regardless of frequency—the first request may be the only warning you get.