Description

AzuraCast is a self-hosted web radio management suite. In AzuraCast before 0.23.8, the station webhook URL validation in AbstractConnector::getValidUrl() (backend/src/Webhook/Connector/AbstractConnector.php), used by the Generic and Discord webhook connectors, rejects only URLs whose host is a literal link-local IP address (169.254.0.0/16 or fe80::/10). Loopback addresses and RFC1918 private ranges are not rejected, and any non-literal-IP hostname causes the IP parsing call to throw, which skips the check entirely. A user holding only the station-scoped WebHooks permission can therefore configure a webhook pointing at an internal, loopback, or private-network target and cause the server to issue an outbound HTTP POST containing the station's Now Playing data, resulting in server-side request forgery. The PUT /station/{id}/webhook/{id}/test endpoint allows the same low-privileged user to trigger the request on demand. At the time of the advisory no patched version was available.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-27T02:17:23.757Z",
  "pubdate": "2026-09-27T02:17:23.757Z",
  "executiveSummary": "AzuraCast versions prior to 0.23.8 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability due to insufficient URL validation in its webhook connector component.\nThe vulnerability originates from a flawed implementation within the AbstractConnector::getValidUrl() function, which fails to adequately sanitize hostnames against loopback, RFC1918 private address spaces, and non-literal-IP hostnames.\nA low-privileged user possessing the 'station-scoped WebHooks' permission can exploit this flaw to force the AzuraCast server to perform unauthorized outbound HTTP POST requests to internal network services or local loopback interfaces.\nThe attack vector allows for the unauthorized extraction of station-specific data or the potential probing of internal infrastructure that is otherwise inaccessible from the public-facing internet.\nThe impact includes information disclosure and the potential for interaction with sensitive internal services. Exploitation is trivial, requiring only standard station webhook configuration access or the ability to trigger a webhook test via the PUT /station/{id}/webhook/{id}/test endpoint.\nThis vulnerability highlights a failure in input validation and blacklist-based security mechanisms, necessitating comprehensive URI filtering and network-level segmentation to prevent unauthorized communication from the application layer.",
  "technicalDetails": "The root cause of this vulnerability lies in the logic governing URL validation within 'backend/src/Webhook/Connector/AbstractConnector.php'. The AbstractConnector::getValidUrl() method is responsible for verifying webhook target destinations; however, it employs an incomplete blacklist approach that exclusively targets literal link-local IP addresses (169.254.0.0/16 and fe80::/10).\nCritically, the implementation fails to block RFC1918 private address ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and loopback addresses (127.0.0.0/8, ::1). Furthermore, the validation logic is bypassed entirely when a non-literal-IP hostname is provided. If the hostname does not conform to a standard literal IP format, the IP parsing function throws an exception. This exception handling results in the validation logic being skipped, effectively allowing any domain name to be processed without further sanitization.\nThe attack flow proceeds as follows: An attacker authenticated with the 'station-scoped WebHooks' permission navigates to the webhook configuration interface. The attacker defines a malicious webhook URL pointing to an internal service (e.g., http://127.0.0.1:8080/internal-api or a service within the local private network).\nUpon saving the configuration, or by manually triggering the request via the 'PUT /station/{id}/webhook/{id}/test' endpoint, the backend initiates an outbound HTTP POST request to the specified target. The request payload contains the station's 'Now Playing' metadata. Because the application server acts as a proxy for this request, the connection originates from the server's own network interface.\nThis behavior facilitates a classic SSRF attack, enabling the attacker to bypass firewall restrictions and communicate with services protected within the perimeter of the AzuraCast host. By controlling the URL, an attacker can conduct reconnaissance on the internal network, interact with internal APIs, or potentially exploit other vulnerabilities in local services that trust internal traffic.\nThe vulnerability affects all Generic and Discord webhook connectors that utilize the vulnerable AbstractConnector class. Because the validation check is bypassed for hostname-based URLs, any attacker capable of configuring webhooks can bypass intended security constraints, leading to full server-side request forgery capabilities."
}