AzuraCast EUVD-2026-87838

Requires an authenticated user with the station Media permission to create/update a playlist configured with source=remote_url and remote_type=playlist. The deployment must have PHP allow_url_fopen enabled - this is the default, including the official Docker image, so it is the common case. Retrieving the disclosed data additionally requires an account with the station Broadcasting permission reading GET /api/station/{station_id}/queue (a single user can hold both permissions and complete the chain). Exploitation is limited by needing valid low-privilege authentication and by being confined to files/HTTP endpoints readable by the web container; at publication no patched version existed, so mitigation depends on disabling allow_url_fopen or restricting Media-permission accounts.

This is a legitimate but moderate-priority issue whose real-world risk is bounded by authentication and impact type rather than reach. The vendor CVSS 4.0 base is 4.8 (AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L). Two of the vendor's metric choices are questionable: AV:L is inconsistent with the description, which describes exploitation entirely through authenticated web API calls (POST/PUT to create/update a playlist, then GET /api/station/{id}/queue) - that is a network vector (AV:N), not local. More importantly VC:N contradicts the core of the finding, which is disclosure of host files such as /etc/passwd and the application .env (secrets/DB credentials) - that is a real, potentially high confidentiality impact, not none. My independent read scores confidentiality materially higher (see assessed vectors). Exploitation status: no public exploit identified at time of analysis - there is no EPSS score, no CISA KEV listing, and no POC referenced in the two provided advisories (AzuraCast GHSA-rrjx-wrhf-8v47 and VulnCheck). No SSVC decision data was supplied. The mitigating realities: it requires an authenticated account with the station Media permission (PR:L), and at publication no patched version existed, so defenders must rely on configuration hardening. Net: a real but lower-tier priority - an authenticated info-disclosure/SSRF, not a wormable unauthenticated RCE.

An authenticated user holding the station Media permission creates or edits a playlist with source=remote_url and remote_type=playlist, setting remote_url to file:///etc/passwd, file://.../.env, or an internal/loopback/link-local HTTP endpoint (e.g. cloud metadata). When AutoDJ builds the queue, the backend calls file_get_contents() on that URL with no scheme allowlist and no private-IP policy (allow_url_fopen is on by default, including the Docker image), parses the returned lines as M3U/PLS entries, and stores them in StationQueue.autodj_custom_uri, where any user with Broadcasting permission reads them back via GET /api/station/{id}/queue. No public exploit is known, but the mechanics are fully described in the advisory.