CVE-2026-100849 in AzuraCast
Summary
by MITRE • 09/27/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/27/2026
AzuraCast is a widely deployed self-hosted web radio management suite that facilitates the broadcasting and administration of internet radio stations. A critical security vulnerability exists within versions prior to 0.23.8, specifically affecting the station webhook URL validation logic implemented in the AbstractConnector::getValidUrl() method located at backend/src/Webhook/Connector/AbstractConnector.php. This function is utilized by both the Generic and Discord webhook connectors to validate destination URLs before they are used for sending data. The vulnerability stems from an insufficient input validation mechanism that fails to adequately restrict internal network destinations, thereby enabling server-side request forgery attacks against low-privileged users who possess only station-scoped WebHooks permissions.
The technical flaw lies in the specific logic employed by the URL validator. The implementation rejects URLs where the host is a literal link-local IP address belonging to the 169.254.0.0/16 or fe80::/10 ranges. However, it fails to reject loopback addresses such as 127.0.0.1 or IPv6 localhost equivalents, nor does it block RFC1918 private IP ranges like 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Furthermore, the validation logic contains a critical exception handling flaw: when the hostname of a provided URL is not a literal IP address but rather a domain name that causes an error during IP parsing, the code catches this exception and skips the security check entirely. This means that any non-literal-IP hostname effectively bypasses internal network restrictions because the validation logic does not perform DNS resolution or further checks to ensure the resolved IP addresses are external and safe.
The operational impact of this vulnerability is significant due to its potential for server-side request forgery, commonly known as SSRF. An attacker with low-level privileges can configure a webhook target pointing at an internal service, such as a database administration interface, cloud metadata endpoint, or other sensitive internal APIs that are not exposed to the public internet but are accessible from the AzuraCast host machine. By doing so, the server is compelled to issue outbound HTTP POST requests containing sensitive station data, including Now Playing information and potentially authentication tokens if they are included in the webhook payload. This can lead to unauthorized access to internal services, data exfiltration, or further exploitation of other vulnerabilities within the local network infrastructure that rely on trust from the AzuraCast server.
This vulnerability is classified under CWE-918 Server-Side Request Forgery (SSRF) and aligns with MITRE ATT&CK technique T1557, which covers Adversary-in-the-Middle or Lateral Tool Transfer scenarios where an attacker uses a compromised system to pivot into other parts of the network. The ability to trigger these requests on demand via the PUT /station/{id}/webhook/{id}/test endpoint exacerbates the risk, as it allows for immediate exploitation without waiting for scheduled webhook events. This functionality enables attackers to probe internal networks systematically and test connectivity to various services from the perspective of the AzuraCast server.
Mitigation strategies should focus on implementing robust URL validation that strictly adheres to a whitelist approach or explicitly blocks all private, loopback, link-local, and documentation IP ranges in addition to literal IPs. Developers must ensure that DNS resolution for hostnames is performed securely and that the resolved IP addresses are also validated against internal network restrictions. Additionally, exception handling logic should not bypass security checks; instead, it should treat parsing errors as validation failures. Until a patched version is available, administrators can mitigate this risk by restricting outbound HTTP traffic from the AzuraCast server using firewall rules or network segmentation policies that prevent connections to private IP ranges and loopback interfaces. Regular audits of webhook configurations and limiting permissions for users who can manage webhooks are also recommended defensive measures.