CVE-2026-100855 in AzuraCast
Summary
by MITRE • 09/27/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/27/2026
The AzuraCast platform, prior to version 0.23.6, suffers from a critical access control vulnerability within its API infrastructure that fundamentally undermines the isolation between distinct radio station instances. This flaw resides specifically in the GET /api/station/{station_id}/file/{id}/play endpoint, which is designed to serve media files for playback purposes. The core technical deficiency is a missing permission check during the request processing lifecycle. When an authenticated user submits a request to this endpoint specifying a particular station identifier and file identifier, the backend logic fails to verify whether that specific user possesses the requisite administrative or operational privileges associated with the target station_id. Consequently, the system treats any valid authentication token as sufficient authorization to access resources across all stations hosted on the instance, regardless of the actual role assignments configured in the application database.
This architectural oversight enables a severe unauthorized data exfiltration scenario where attackers can bypass multi-tenant isolation boundaries. By leveraging sequential integer values for the file identifier parameter, an adversary can systematically enumerate and download media assets belonging to any station within the AzuraCast deployment. This process does not require guessing complex identifiers or exploiting secondary vulnerabilities; it relies solely on the predictable nature of database primary keys combined with the lack of authorization validation. The attacker iterates through potential file IDs while maintaining a valid session token, effectively harvesting the complete media library including copyrighted music, podcasts, and promotional content from stations they do not own or manage. This represents a classic instance of insecure direct object references where the application relies on client-supplied identifiers without enforcing server-side access control policies.
The operational impact of this vulnerability is substantial for both service providers operating AzuraCast instances and individual station owners relying on the platform for broadcasting operations. For multi-tenant deployments, the breach compromises data confidentiality across all hosted stations, potentially leading to significant legal liabilities related to copyright infringement if proprietary or licensed content is redistributed without permission. Individual users face direct financial loss through the theft of intellectual property and potential reputational damage if their station's unique audio branding or exclusive content is leaked publicly. Furthermore, the ability to enumerate files may facilitate further reconnaissance by revealing file naming conventions, metadata structures, or other sensitive information embedded within media headers that could aid in crafting more sophisticated attacks against the underlying infrastructure.
From a security classification perspective, this vulnerability aligns with CWE-284, which describes Improper Access Control, specifically highlighting failures to enforce proper authorization checks on API endpoints. It also maps closely to MITRE ATT&CK technique T1078, Valid Accounts, as it exploits legitimate authentication credentials to access unauthorized resources, and potentially T1530, Data from Cloud Storage Object, if the media files are stored in external object storage services commonly integrated with AzuraCast such as AWS S3 or similar cloud providers. The exploitation path is straightforward and does not require complex payload construction, making it highly exploitable by automated tools that can rapidly iterate through ID spaces to harvest large volumes of data.
Mitigation strategies must prioritize immediate patching alongside temporary compensating controls. Administrators running AzuraCast versions earlier than 0.23.6 should upgrade to the latest stable release immediately, as this version contains the necessary code changes to enforce strict ownership verification before serving media files. Until an update can be applied, it is advisable to restrict API access through network-level firewalls or reverse proxy configurations that limit exposure of the /api/station/ endpoints to trusted IP ranges only. Additionally, implementing rate limiting on these specific endpoints can mitigate the speed at which enumeration attacks are conducted, although this does not resolve the underlying authorization flaw. Long-term remediation should involve a comprehensive review of all API endpoints within the application to ensure that every resource access path includes robust identity and permission validation checks consistent with zero-trust principles.