AzuraCast vulnerabilities

AzuraCast before 0.23.4 contains a code injection vulnerability in the ConfigWriter::cleanUpString() method that fails to sanitize Liquidsoap string interpolation sequences. Authenticated users with Media or Profile permissions can inject arbitrary Liquidsoap code into station configuration, leading to shell command execution as the azuracast user when the station restarts.

AzuraCast before 0.23.6 contains a code injection vulnerability in the remote relay password field due to incomplete migration from the vulnerable cleanUpString method to toRawString. Attackers with RemoteRelays station permission can inject nested Liquidsoap interpolation syntax to execute arbitrary code in the Liquidsoap process, disclose internal API keys, or disrupt station operation.

AzuraCast before 0.23.6 contains a missing permission check vulnerability in the GET /api/station/{station_id}/file/{id}/play endpoint that allows authenticated users to download media files from any station. Attackers can enumerate media files using sequential IDs and exfiltrate the complete media library of stations they lack permissions for.

AzuraCast before 0.23.6 lacks RequireInternalConnection middleware on the Liquidsoap API endpoint and incorrectly derives the AutoDJ flag from header presence rather than validated value. Users with View station permission can inject arbitrary now-playing metadata, disrupt live broadcasts, and disclose filesystem paths.

In AzuraCast before 0.23.8, the public On-Demand download endpoint fails to verify playlist-level access controls, allowing unauthenticated users to download media files excluded from On-Demand-enabled playlists. Attackers can bypass the station operator's intended access restrictions by directly requesting media via the download endpoint using valid media identifiers, exposing private or restricted audio content.

Command injection vulnerability in AzuraCast before 0.23.8 in Liquidsoap config generation for live recording, due to failure to quote streamer username in process.run calls.

AzuraCast before 0.23.8 contains a broken access control vulnerability in the GET /api/station/{id}/vue/profile endpoint that allows authenticated users with only View Station Page permission to read Icecast/Shoutcast admin, source, and relay passwords. Attackers with View-only access can call this endpoint and receive plaintext frontend credentials in the JSON response, then use the admin password to authenticate to the Icecast admin interface without Broadcasting permission.

AzuraCast before 0.23.8 contains a server-side request forgery and local file read vulnerability in the AutoDJ remote playlist fetch (getMediaFromRemoteUrl()). A user with Media permission can create a playlist with source=remote_url and remote_type=playlist pointing to a file:// path or internal HTTP endpoint. When AutoDJ builds the queue, the backend passes the URL directly to file_get_contents() with no scheme allowlist or private/loopback IP policy, allowing disclosure of host files (e.g., /etc/passwd or .env) and bodies of internal HTTP requests. No patched version was available at the time of publication.

AzuraCast before 0.23.8 contains an SSRF vulnerability in webhook URL validation. The validation only rejects link-local IP addresses, not loopback or private ranges, and non-IP hostnames bypass the check entirely. A user with WebHooks permission can configure a webhook to internal resources and trigger an HTTP POST with Now Playing data.

AzuraCast before 0.23.8 contains an SSRF vulnerability in Remote Relay URL validation. The validation only checks URL syntax and scheme, with no host or IP restrictions. A user with RemoteRelays permission can set a URL to loopback, private network, or cloud metadata addresses, and the automatic Now Playing sync will send requests to those addresses.

AzuraCast before 0.23.8 contains a DQL injection vulnerability in the sortOrder parameter in AbstractSearchableListAction.php. Attackers can inject arbitrary DQL expressions to extract sensitive database information, including user credentials and station settings.

AzuraCast exposes the Liquidsoap custom configuration fields through an endpoint that does not require the permission guarding them. The backend_config property in Station.php is annotated with GROUP_GENERAL, and PUT /api/station/{station_id}/profile/edit deserializes with that group while requiring only StationPermissions::Profile. AbstractArrayEntity::fromArray() then assigns every public property with no field-level permission check, so custom_config_top, custom_config, custom_config_pre_playlists, custom_config_pre_live, custom_config_pre_fade and custom_config_bottom are writable through it. ConfigWriter::writeCustomConfigurationSection() emits those values verbatim into the generated Liquidsoap .liq script, where the process.run() and process.exec() built-ins execute operating system commands when the backend restarts, which the built-in sync task triggers automatically once needs_restart is set. The dedicated endpoint for the same data, PUT /api/station/{id}/liquidsoap-config, requires StationPermissions::Broadcasting, so a station manager holding only the profile permission reaches configuration that the intended boundary reserves for broadcasting operators.

AzuraCast before version 0.23.6 has a vulnerability in the ApplyXForwarded middleware that unconditionally trusts the X-Forwarded-Host header without a trusted proxy allowlist. An unauthenticated attacker can poison the password reset URL by injecting this header during the forgot-password flow. When the victim clicks the link, the reset token is exfiltrated, allowing full account takeover and destruction of 2FA configuration.

A vulnerability in AzuraCast prior to version 0.23.6 allows an authenticated user with media management permissions to write arbitrary files outside the station's media storage directory via an unsanitized currentDirectory parameter in the Flow.js upload endpoint. This can lead to remote code execution by writing a PHP webshell.

AzuraCast version 0.23.1 mistakenly exposes an API endpoint intended for internal use by the SFTP software sftpgo through the public-facing HTTP API. A user with specific internal knowledge of a station's operations can craft a custom HTTP request that affects the contents of a station's database. This issue is fixed in version 0.23.2.