CVE-2026-100848 in AzuraCast
Summary
by MITRE • 09/27/2026
AzuraCast (Composer package azuracast/azuracast) before 0.23.8 validates a station's "Remote Relay" URL only for URL syntax and an http/https scheme (Utilities\Urls::parseUserUrl, used by StationRemote::getUrlAsUri) and performs no host or IP address restriction. A user holding only the station-scoped RemoteRelays permission can therefore set a Remote Relay URL pointing at loopback, private-network, or cloud-metadata addresses (e.g. http://127.0.0.1:<port>/ or http://169.254.169.254/latest/meta-data/), and AzuraCast's periodic background Now Playing sync (AbstractRemote::getNowPlayingAsync) will automatically and repeatedly issue HTTP requests to that address, resulting in server-side request forgery against internal resources. This affects the main branch as of commit bcf8754eef3a268ad82c3db4d81f7920c3c28b56 (2026-07-31); no patched version is available at the time of the advisory.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in AzuraCast versions prior to 0.23.8 represents a critical server-side request forgery flaw rooted in insufficient input validation within the station configuration subsystem. Specifically, the function Utilities\Urls::parseUserUrl, which is invoked by StationRemote::getUrlAsUri during the processing of Remote Relay settings, performs only superficial checks on user-supplied URLs. The validation logic restricts itself to verifying that the URL syntax is well-formed and that the scheme is either http or https. It completely lacks any mechanism to validate the hostname or IP address component of the URL against a whitelist of allowed external domains or to block access to internal network ranges. This design oversight allows an attacker with station-scoped permissions, specifically those holding only the RemoteRelays permission, to inject arbitrary URLs that point toward sensitive internal infrastructure rather than legitimate public radio relays.
The operational impact of this flaw is significant due to how AzuraCast utilizes these configured remote relay addresses in its background processes. The system includes a periodic Now Playing synchronization feature implemented via AbstractRemote::getNowPlayingAsync, which automatically and repeatedly issues HTTP requests to the URLs defined as Remote Relays. Because there are no host or IP address restrictions, an attacker can configure this field to target loopback interfaces such as 127.0.0.1 on specific ports, private network addresses within the local subnet, or cloud metadata endpoints like http://169.254.169.254/latest/meta-data/. Consequently, every time the background job executes, it sends HTTP requests to these internal targets from the server's own IP address. This effectively turns the AzuraCast instance into a persistent proxy for attacking other services running on the same host or within the same private network segment.
This vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), as it enables an authenticated user to cause the server-side application to make requests to unintended destinations. Furthermore, in the context of cloud environments, targeting 169.254.169.254 facilitates access to instance metadata services, which often contain sensitive information such as temporary security credentials, IAM roles, and configuration data. This activity can be mapped to MITRE ATT&CK technique T1078 Valid Accounts if the attacker leverages legitimate station permissions, or more specifically to SSRF patterns where the application acts as a pivot point for internal network reconnaissance or credential theft. The lack of restriction on IP addresses means that even services protected by firewall rules at the perimeter may be compromised because the traffic originates from within the trusted internal zone.
The severity of this issue is compounded by the fact that no patched version was available at the time of the advisory, affecting the main branch as of commit bcf8754eef3a268ad81f7920c3c28b56 dated July 31, 2026. Organizations running AzuraCast must implement immediate compensating controls to mitigate this risk until an official patch is released. Recommended mitigations include configuring the web server or application firewall to block outbound connections from the AzuraCast process to private IP ranges and cloud metadata endpoints. Additionally, administrators should restrict the RemoteRelays permission to only those users who absolutely require it, thereby limiting the attack surface. Network segmentation strategies that isolate the AzuraCast deployment from critical internal services can also reduce the blast radius of a successful exploitation attempt.