Azuracast
Monthly
Authenticated command injection in AzuraCast through 0.23.8 lets any station user holding the standard Profile permission run arbitrary OS commands on the station backend by planting shell metacharacters in the StereoTool settings, resulting in compromise of the AzuraCast/Liquidsoap container. Exploitation is not anonymous and is not universal: it requires the StereoTool binary to be installed and configured on the target station, and the injected command only fires when the station backend restarts or the Liquidsoap configuration is regenerated. A detailed proof-of-concept request is published in the project's GitHub security advisory, but there is no confirmed active exploitation (not in CISA KEV) and no vendor-released patch was identified at time of analysis; this is a credible, above-average-priority issue rather than an emergency.
Authenticated station managers in AzuraCast through 0.23.8 can turn a station profile edit into root-level command execution by placing a newline-delimited Supervisor [program:] block inside the station timezone field. The value is written into the generated supervisord.conf with only % characters escaped, so the injected program is parsed and executed as root (uid=0 in the vendor's reproduction) when the station configuration is regenerated - whether through the restart API or any later regeneration trigger. The vendor advisory (GHSA-23wx-88m8-pfm2) ships a reproduced proof of concept against 0.23.8 on the official Docker image; this is a this-week priority with no vendor patch available at time of analysis, and exploitation is confined to the AzuraCast runtime (no Docker or host escape was demonstrated).
Configuration injection in AzuraCast through 0.23.8 lets an authenticated station user who holds only the 'Manage station profile' permission rewrite the live Shoutcast sc_serv.conf of a shoutcast2-type station, overriding adminpassword, password and portbase or appending arbitrary directives via newline-bearing keys. The root cause is an authorization gap: PUT /station/{id}/profile/edit strips privileged Liquidsoap backend custom sections for users without 'Manage station broadcasting' but leaves frontend_config.custom_config writable, and that stored JSON is written verbatim as key=value lines into the config file. The injection only materializes when the station or frontend is restarted (in the published proof-of-concept the restart is performed by an admin), and because the Shoutcast binary is absent from stock images, actual daemon execution of the hijacked configuration was not observed. No CISA KEV entry or in-the-wild exploitation is reported, though the upstream GitHub advisory publishes a detailed proof-of-concept and an automated verification script.
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.
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.
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.
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.
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 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.
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.
Remote code execution in AzuraCast ≤0.23.8 is reachable by any authenticated station manager due to a serialization group mismatch that exposes Liquidsoap custom configuration fields through the profile-edit API endpoint, which enforces only the lower-privilege StationPermissions::Profile rather than the StationPermissions::Broadcasting required by the dedicated Liquidsoap configuration endpoint. An attacker injects arbitrary Liquidsoap script constructs - including process.run() or process.exec() OS command primitives - into fields that ConfigWriter::writeCustomConfigurationSection() emits verbatim into the generated .liq script, with execution triggered automatically by the built-in sync task whenever needs_restart is set. No public exploit has been identified at time of analysis, and this CVE is not listed in the CISA KEV catalog, but the attack path is fully described in advisory GHSA-q8wg-3qg7-8pc7 and presents a straightforward escalation from station manager to host OS command execution.
Stored CSV formula injection in AzuraCast 0.23.8 and earlier allows a station user holding the Media permission to persist formula-prefixed values (leading =, +, -, @, tab, or carriage return) in media titles, artists, albums, genres, lyrics, ISRC, extra metadata, or station custom fields through POST /api/station/{station_id}/files/bulk. The injected payload is neutralized nowhere on export, so it becomes live the moment a second authorized user downloads the station's bulk media CSV via GET /api/station/{station_id}/files/bulk and opens it in a formula-evaluating spreadsheet such as Microsoft Excel. Impact is confined to the downstream spreadsheet client - the advisory explicitly disclaims server-side or OS-level code execution inside the AzuraCast process - and success depends on victim interaction plus the spreadsheet's version and security settings; no public exploit code was identified at time of analysis and the issue is not in CISA KEV, consistent with a medium-severity, non-urgent priority.
CRLF injection in AzuraCast's public PLS playlist generation lets a station user who holds only the Station:MountPoints or Station:RemoteRelays permission plant extra FileN=/TitleN= entries into /public/{station}/playlist.pls, pointing guest listeners at an attacker-controlled stream that still displays the victim station's own name. The advisory scopes affected installations as AzuraCast before 0.24.0 and verifies the flaw on rolling release commit 2cb84e2f874d08ad9ff743ebda94fb30bc77041f; exploitation is second-order and depends on a guest downloading the playlist and using a media player that honors the injected entries, so impact stays within content spoofing and listener redirection with no code execution and no data exposure (assessed CVSS:3.1 AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N). Step-by-step reproduction requests are published in GitHub advisory GHSA-cqgx-rqjr-5gf4, so a public PoC reference exists, but it is not verified as working exploit code; no CISA KEV entry or other active-exploitation signal is present, and priority is this_month.
Server-side request forgery in AzuraCast through 0.23.8 lets any station user holding the station-scoped WebHooks permission make the AzuraCast server issue outbound HTTP requests to attacker-chosen internal addresses. The flaw is an incomplete fix for GHSA-3jp3-3wqw-jvw4: the Mastodon (instance_url), Telegram (api), GroupMe (api) and RadioReg (webhookurl) connectors were never routed through the UserUrlFilter guard, so a low-privilege user can point them at loopback, private-network or cloud-metadata endpoints and fire the test webhook endpoint (PUT /station/{id}/webhook/{id}/test) for immediate dispatch, with the response captured in the HTTP log. Exploitation is gated by the WebHooks permission rather than being anonymous, and the highest-impact outcomes (metadata credential theft, Docker-internal pivoting) depend on such endpoints being reachable from the host; no public exploit code was identified at time of analysis and the issue is prioritised as a this-month item rather than an emergency.
AzuraCast's station waveform endpoints (GET and POST /api/station/{station_id}/waveform/{media_id}) are missing the Permissions middleware that every sibling station-scoped media route carries, so any authenticated user - even one with no station assignment at all - can read another station's cached waveform JSON and overwrite it with arbitrary content. Successful abuse gives limited cross-station data disclosure and limited tampering with the Visual Cue Editor waveform data, not access to media files, credentials, or arbitrary filesystem paths (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N; CVSS 4.0 base 5.3). Authentication of the lowest privilege tier is required and the attacker must reach the API with a target station_id and media_id; VulnCheck and the upstream advisory provide a PoC reference that boots the real application and introspects its compiled route table to prove the missing middleware - it is not verified as working end-to-end exploit code, and there is no KEV listing or active-exploitation reporting.
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.
Unauthenticated HTTP requests to AzuraCast 0.23.1's internal sftpgo integration endpoints (/api/internal/sftp-auth and /api/internal/sftp-event) can corrupt a station's media database records - specifically deleting the media record's playlist associations and custom metadata - by forging a 'pre-delete' event that the application believes came from sftpgo. Exploitation is constrained by two prerequisites: the attacker must know a valid SFTP username for the target station and must know or guess the internal filesystem path of the media file, and the endpoint returns no data, so paths cannot be enumerated through it. Publicly available exploit code exists (a curl proof-of-concept is published in the GitHub advisory) but there is no evidence of active exploitation (not in CISA KEV), and EPSS is 0.25% at the 15th percentile, reflecting low real-world prioritization. Scanner and advisory titles referencing file deletion or RCE overstate the documented and independently assessed impact, which is limited to low-severity integrity loss.
Improper Restriction of Excessive Authentication Attempts in GitHub repository azuracast/azuracast prior to 0.18.3. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository azuracast/azuracast prior to 0.18. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Authenticated command injection in AzuraCast through 0.23.8 lets any station user holding the standard Profile permission run arbitrary OS commands on the station backend by planting shell metacharacters in the StereoTool settings, resulting in compromise of the AzuraCast/Liquidsoap container. Exploitation is not anonymous and is not universal: it requires the StereoTool binary to be installed and configured on the target station, and the injected command only fires when the station backend restarts or the Liquidsoap configuration is regenerated. A detailed proof-of-concept request is published in the project's GitHub security advisory, but there is no confirmed active exploitation (not in CISA KEV) and no vendor-released patch was identified at time of analysis; this is a credible, above-average-priority issue rather than an emergency.
Authenticated station managers in AzuraCast through 0.23.8 can turn a station profile edit into root-level command execution by placing a newline-delimited Supervisor [program:] block inside the station timezone field. The value is written into the generated supervisord.conf with only % characters escaped, so the injected program is parsed and executed as root (uid=0 in the vendor's reproduction) when the station configuration is regenerated - whether through the restart API or any later regeneration trigger. The vendor advisory (GHSA-23wx-88m8-pfm2) ships a reproduced proof of concept against 0.23.8 on the official Docker image; this is a this-week priority with no vendor patch available at time of analysis, and exploitation is confined to the AzuraCast runtime (no Docker or host escape was demonstrated).
Configuration injection in AzuraCast through 0.23.8 lets an authenticated station user who holds only the 'Manage station profile' permission rewrite the live Shoutcast sc_serv.conf of a shoutcast2-type station, overriding adminpassword, password and portbase or appending arbitrary directives via newline-bearing keys. The root cause is an authorization gap: PUT /station/{id}/profile/edit strips privileged Liquidsoap backend custom sections for users without 'Manage station broadcasting' but leaves frontend_config.custom_config writable, and that stored JSON is written verbatim as key=value lines into the config file. The injection only materializes when the station or frontend is restarted (in the published proof-of-concept the restart is performed by an admin), and because the Shoutcast binary is absent from stock images, actual daemon execution of the hijacked configuration was not observed. No CISA KEV entry or in-the-wild exploitation is reported, though the upstream GitHub advisory publishes a detailed proof-of-concept and an automated verification script.
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.
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.
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.
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.
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 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.
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.
Remote code execution in AzuraCast ≤0.23.8 is reachable by any authenticated station manager due to a serialization group mismatch that exposes Liquidsoap custom configuration fields through the profile-edit API endpoint, which enforces only the lower-privilege StationPermissions::Profile rather than the StationPermissions::Broadcasting required by the dedicated Liquidsoap configuration endpoint. An attacker injects arbitrary Liquidsoap script constructs - including process.run() or process.exec() OS command primitives - into fields that ConfigWriter::writeCustomConfigurationSection() emits verbatim into the generated .liq script, with execution triggered automatically by the built-in sync task whenever needs_restart is set. No public exploit has been identified at time of analysis, and this CVE is not listed in the CISA KEV catalog, but the attack path is fully described in advisory GHSA-q8wg-3qg7-8pc7 and presents a straightforward escalation from station manager to host OS command execution.
Stored CSV formula injection in AzuraCast 0.23.8 and earlier allows a station user holding the Media permission to persist formula-prefixed values (leading =, +, -, @, tab, or carriage return) in media titles, artists, albums, genres, lyrics, ISRC, extra metadata, or station custom fields through POST /api/station/{station_id}/files/bulk. The injected payload is neutralized nowhere on export, so it becomes live the moment a second authorized user downloads the station's bulk media CSV via GET /api/station/{station_id}/files/bulk and opens it in a formula-evaluating spreadsheet such as Microsoft Excel. Impact is confined to the downstream spreadsheet client - the advisory explicitly disclaims server-side or OS-level code execution inside the AzuraCast process - and success depends on victim interaction plus the spreadsheet's version and security settings; no public exploit code was identified at time of analysis and the issue is not in CISA KEV, consistent with a medium-severity, non-urgent priority.
CRLF injection in AzuraCast's public PLS playlist generation lets a station user who holds only the Station:MountPoints or Station:RemoteRelays permission plant extra FileN=/TitleN= entries into /public/{station}/playlist.pls, pointing guest listeners at an attacker-controlled stream that still displays the victim station's own name. The advisory scopes affected installations as AzuraCast before 0.24.0 and verifies the flaw on rolling release commit 2cb84e2f874d08ad9ff743ebda94fb30bc77041f; exploitation is second-order and depends on a guest downloading the playlist and using a media player that honors the injected entries, so impact stays within content spoofing and listener redirection with no code execution and no data exposure (assessed CVSS:3.1 AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N). Step-by-step reproduction requests are published in GitHub advisory GHSA-cqgx-rqjr-5gf4, so a public PoC reference exists, but it is not verified as working exploit code; no CISA KEV entry or other active-exploitation signal is present, and priority is this_month.
Server-side request forgery in AzuraCast through 0.23.8 lets any station user holding the station-scoped WebHooks permission make the AzuraCast server issue outbound HTTP requests to attacker-chosen internal addresses. The flaw is an incomplete fix for GHSA-3jp3-3wqw-jvw4: the Mastodon (instance_url), Telegram (api), GroupMe (api) and RadioReg (webhookurl) connectors were never routed through the UserUrlFilter guard, so a low-privilege user can point them at loopback, private-network or cloud-metadata endpoints and fire the test webhook endpoint (PUT /station/{id}/webhook/{id}/test) for immediate dispatch, with the response captured in the HTTP log. Exploitation is gated by the WebHooks permission rather than being anonymous, and the highest-impact outcomes (metadata credential theft, Docker-internal pivoting) depend on such endpoints being reachable from the host; no public exploit code was identified at time of analysis and the issue is prioritised as a this-month item rather than an emergency.
AzuraCast's station waveform endpoints (GET and POST /api/station/{station_id}/waveform/{media_id}) are missing the Permissions middleware that every sibling station-scoped media route carries, so any authenticated user - even one with no station assignment at all - can read another station's cached waveform JSON and overwrite it with arbitrary content. Successful abuse gives limited cross-station data disclosure and limited tampering with the Visual Cue Editor waveform data, not access to media files, credentials, or arbitrary filesystem paths (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N; CVSS 4.0 base 5.3). Authentication of the lowest privilege tier is required and the attacker must reach the API with a target station_id and media_id; VulnCheck and the upstream advisory provide a PoC reference that boots the real application and introspects its compiled route table to prove the missing middleware - it is not verified as working end-to-end exploit code, and there is no KEV listing or active-exploitation reporting.
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.
Unauthenticated HTTP requests to AzuraCast 0.23.1's internal sftpgo integration endpoints (/api/internal/sftp-auth and /api/internal/sftp-event) can corrupt a station's media database records - specifically deleting the media record's playlist associations and custom metadata - by forging a 'pre-delete' event that the application believes came from sftpgo. Exploitation is constrained by two prerequisites: the attacker must know a valid SFTP username for the target station and must know or guess the internal filesystem path of the media file, and the endpoint returns no data, so paths cannot be enumerated through it. Publicly available exploit code exists (a curl proof-of-concept is published in the GitHub advisory) but there is no evidence of active exploitation (not in CISA KEV), and EPSS is 0.25% at the 15th percentile, reflecting low real-world prioritization. Scanner and advisory titles referencing file deletion or RCE overstate the documented and independently assessed impact, which is limited to low-severity integrity loss.
Improper Restriction of Excessive Authentication Attempts in GitHub repository azuracast/azuracast prior to 0.18.3. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository azuracast/azuracast prior to 0.18. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.