AzuraCast SSRF, Injection, and Access Control Flaws

Code injection in AzuraCast through 0.23.5 lets an authenticated user holding the RemoteRelays station permission inject nested Liquidsoap interpolation syntax (for example #{#{EXPR}}) into the remote relay password field, achieving arbitrary code execution inside the Liquidsoap process, disclosing internal API keys, or disrupting station operation. The root cause is an incomplete migration in ConfigWriter.php from the vulnerable cleanUpString() sanitizer to the safe toRawString() helper; a prior commit (ff49ef4) migrated host, username, mount, name, description, genre, and URL fields but left the password field behind. No public exploit identified at time of analysis, and exploitation is gated by the RemoteRelays privilege (PR:L) and by the station's Liquidsoap configuration being regenerated and loaded.

Unauthenticated DQL injection in AzuraCast before 0.23.8 allows remote attackers to extract sensitive database information, including user credentials and station settings, via the sortOrder parameter in the search/list API. No authentication or user interaction is required (CVSS 4.0 PR:N/UI:N), though exploitation requires network reachability to the AzuraCast web interface. No public exploit identified at time of analysis, but the flaw is trivially exploitable and affects many internet-facing radio panel deployments.

Command execution as the Liquidsoap process user is possible in AzuraCast through 0.23.x when an authenticated station user with Streamers and Profile permissions sets a streamer username containing shell metacharacters and a live recording session closes. The flaw (CWE-78, CVSS 8.7) requires the live-recording feature to be active and the malicious username to be passed unquoted into process.run during Liquidsoap config generation; there is no public exploit identified at time of analysis, and exploitation is limited to insiders or attackers who already hold streamer-level credentials on a station where recording is enabled.

Authenticated code injection in AzuraCast 0.23.3 and earlier lets a user holding StationPermissions::Media or StationPermissions::Profile plant Liquidsoap interpolation sequences (#{...}) into playlist remote URLs or station metadata fields, which the ConfigWriter::cleanUpString() helper writes unsanitized into the generated .liq configuration. When the affected station's Liquidsoap backend is next restarted and re-parses that config, the embedded #{process.run(...)} expression is evaluated and executes arbitrary shell commands as the azuracast service user. Exploitation is not confirmed in the wild (no CISA KEV listing), but the vendor advisory publishes proof-of-concept payloads for both the Media-permission and Profile-permission paths; the trigger is delayed and interaction-dependent, requiring a station restart after the malicious value is saved.

Unauthenticated media exposure in AzuraCast before 0.23.8 allows remote attackers to download audio files that station operators intended to keep private, because the public On-Demand download endpoint does not verify playlist-level access controls before serving a requested media item (CWE-862 Missing Authorization). Any deployment that exposes the On-Demand endpoint and relies on playlist membership to restrict content is affected, and no authentication or user interaction is required once an attacker has a valid media identifier for the target station. The impact is confidentiality-only with no write or availability effect; exploitation is not confirmed as actively exploited and no public exploit code identified at time of analysis, so despite the vendor's 8.2 score this is a genuine but moderate-severity access-control flaw.

Authenticated users with only View Station Page permission on AzuraCast before 0.23.8 can retrieve plaintext Icecast/Shoutcast admin, source, and relay passwords from the GET /api/station/{id}/vue/profile endpoint. The exposed admin credentials permit logging into the Icecast admin interface without holding Broadcasting permission, escalating the attacker's effective access within the streaming infrastructure. This broken access control issue (CWE-200) is rated moderate severity and is realistically exploitable only in multi-user or multi-tenant deployments where untrusted or semi-trusted parties hold low-privilege View-only accounts; no public exploit identified at time of analysis.

Server-side request forgery in AzuraCast before 0.23.8 allows an authenticated user with the station-scoped WebHooks permission to make the server send outbound HTTP POST requests to internal, loopback, or RFC1918 addresses through the Generic and Discord webhook connectors. The AbstractConnector::getValidUrl() validation only rejects literal link-local IPs and skips validation entirely when the hostname is not a literal IP, and the same user can trigger the request on demand via the webhook test endpoint. No public exploit identified at time of analysis; risk is moderate because exploitation requires a low-privileged account and impact is largely a blind Now Playing POST unless the target internal service is reachable and responsive.

Server-side request forgery in AzuraCast (Composer package azuracast/azuracast, versions before 0.23.8 per the advisory) lets an authenticated user who holds the station-scoped RemoteRelays permission set a station's Remote Relay URL to loopback, private-network, or cloud-metadata addresses such as http://127.0.0.1:<port>/ or http://169.254.169.254/latest/meta-data/. Because the URL is validated only for syntax and an http/https scheme, the platform's periodic background Now Playing sync (AbstractRemote::getNowPlayingAsync) then automatically and repeatedly fetches that attacker-chosen address on the server's behalf, yielding blind SSRF against internal services and - on cloud-hosted instances with a reachable metadata endpoint - potentially exposing instance credentials or configuration. This is not an unauthenticated internet-facing flaw: exploitation requires an authenticated account with the RemoteRelays permission (PR:L in both the vendor's CVSS 4.0 vector and our CVSS 3.1 assessment), there is no public exploit code identified at time of analysis, and no patched release was confirmed at the time of the advisory.

Missing authorization on AzuraCast's GET /api/station/{station_id}/file/{id}/play endpoint lets any authenticated user - including one whose API key or session is scoped to a single station - download the complete media library of every other station on a multi-tenant installation running 0.23.5 or earlier. Because the endpoint accepts sequential auto-increment media IDs, an attacker can trivially enumerate and exfiltrate files from stations they have no permissions on, with no user interaction and impact limited to confidentiality (vendor CVSS 4.0 base 7.1; assessed as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). The vendor advisory (GHSA-qff7-q5fm-8p76) ships step-by-step proof-of-concept reproduction instructions; there is no indication of confirmed active exploitation (CISA KEV) at time of analysis.

AzuraCast 0.23.5 and earlier exposes its internal Liquidsoap API endpoint (/api/internal/{station_id}/liquidsoap/{action}) to the public web interface, allowing any authenticated user who holds only the basic View station permission to invoke privileged Liquidsoap commands. The endpoint is missing the RequireInternalConnection middleware that guards the sibling /sftp-auth and /sftp-event routes, and the $asAutoDj flag is derived from the mere presence of the X-Liquidsoap-Api-Key header rather than its validated value, so the header value is never checked when the ACL check passes. Practical impact is bounded to spoofed now-playing metadata visible to all listeners, disruption of live broadcast tracking, and disclosure of absolute filesystem paths (assessed CVSS:3.1 5.3, C:L/I:L/A:L) - a genuine but moderate CWE-862 access-control flaw, most relevant to multi-tenant installations where untrusted users hold station accounts. A vendor fix is available in 0.23.6; no public exploit code has been identified at time of analysis.

AzuraCast deployments before 0.23.8 expose a server-side request forgery and local file read flaw in the AutoDJ remote playlist fetcher, letting an authenticated user who holds the station Media permission point a remote_url playlist at a file:// path or an internal/loopback HTTP endpoint and have the backend fetch it with file_get_contents(). The retrieved lines are stored as queue entries and then disclosed through GET /api/station/{station_id}/queue to any user with the Broadcasting permission, exposing host files readable by the web container (such as /etc/passwd or the application .env) and the bodies of non-blind internal HTTP requests. Exploitation is bounded by valid low-privilege authentication and by the privileges of the web container, and no public exploit code was identified at time of analysis; the advisory data states that no patched version was available at publication, so mitigation depends on disabling PHP allow_url_fopen or tightening Media-permission access.