Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-27T02:17:23.583Z",
  "pubdate": "2026-09-27T02:17:23.583Z",
  "executiveSummary": "AzuraCast contains a Server-Side Request Forgery (SSRF) vulnerability due to insufficient validation of user-provided Remote Relay URLs. The application validates the syntax and scheme of these URLs but fails to implement necessary host or IP address filtering.\nA user assigned the 'RemoteRelays' permission can manipulate the system into initiating arbitrary HTTP requests toward internal network resources, including loopback interfaces, private IP ranges, and sensitive cloud provider metadata services (e.g., 169.254.169.254).\nBecause the application's background 'Now Playing' synchronization process (AbstractRemote::getNowPlayingAsync) automatically executes these requests, an attacker can perform continuous, automated polling of internal infrastructure. This vulnerability poses a significant risk as it allows an authenticated user to bypass network security boundaries, potentially leading to unauthorized information disclosure, interaction with internal services, or the discovery of network topology. Exploitation requires authenticated access to a station where the attacker possesses the specific 'RemoteRelays' permission.",
  "technicalDetails": "The vulnerability resides in the validation logic within Utilities\\Urls::parseUserUrl, which is invoked by StationRemote::getUrlAsUri. The implementation performs superficial validation, checking only for syntactical correctness and the presence of an http/https URI scheme. Crucially, the implementation lacks an allowlist or denylist mechanism to prevent the resolution of sensitive hostnames or reserved IP address spaces.\nThe exploitation flow begins when an attacker, authorized with the station-scoped 'RemoteRelays' permission, updates a station's Remote Relay URL configuration to target internal or local endpoints. By providing payloads such as 'http://127.0.0.1:<port>/' or 'http://169.254.169.254/latest/meta-data/', the attacker forces the application to treat these malicious inputs as legitimate relay endpoints.\nThe core of the issue lies in the periodic background task handled by AbstractRemote::getNowPlayingAsync. Once the malicious URL is stored in the application configuration, this automated service regularly issues HTTP requests to the attacker-defined address as part of its 'Now Playing' sync routine. Because the application server itself performs these requests, the traffic originates from the trusted environment where the AzuraCast instance is hosted.\nThis behavior facilitates a powerful SSRF primitive. An attacker can probe internal services that may not be exposed to the public internet, potentially bypassing firewalls, interacting with internal APIs, or exfiltrating data from cloud metadata services. Since the sync process is periodic, the server repeatedly probes the target, providing an attacker with a mechanism to receive ongoing updates or verify the presence of internal services through side-channel timing or response data analysis.\nThe affected components are primarily located in the core logic handling station metadata and external relay synchronization. The vulnerability is present in versions of AzuraCast before 0.23.8, including the main branch up to commit bcf8754eef3a268ad82c3db4d81f7920c3c28b56. Successful exploitation is limited by the requirement of having station-scoped permissions; however, within a multi-tenant or collaborative environment, this significantly elevates the threat posed by malicious or compromised user accounts."
}