Skip to content
CVE Alert: CVE-2026-100849 – AzuraCast

CVE Alert: CVE-2026-100849 – AzuraCast

Redpacketsecurity •admin • September 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.

**Risk verdict:** High risk for internet-reachable deployments; urgency cannot be confirmed because KEV, SSVC, PoC and EPSS data were not provided.

**Why this matters:** A station-level account may abuse webhook configuration to make the server reach internal services, potentially exposing accessible data or probing systems on trusted networks. Requests also carry station Now Playing data, creating a risk of disclosure to attacker-controlled destinations.

**Most likely attack path:** An attacker needs network access to the management interface and only low-level station permissions; no further user action or complex setup is indicated. The application’s scope remains unchanged, but its server-side network position may let an attacker reach services unavailable from the internet.

**Who is most exposed:** Internet-accessible, self-hosted radio-management instances with station webhook permissions granted to untrusted or compromised users are most exposed.

Review webhook destinations for loopback, private, link-local or unexpected hostnames.

Alert on outbound POSTs from the application host to internal address ranges.

Correlate webhook test requests with unusual DNS lookups or connections to infrastructure services.

Check proxy, DNS and firewall logs for repeated destination changes or failed internal connection attempts.

Mitigation and prioritisation

Confirm the vendor’s current remediation and deploy a fixed release promptly; the supplied data does not establish current patch availability.

Until patched, restrict webhook creation and testing to trusted administrators.

Block application-server egress to loopback, private and link-local ranges, including after DNS resolution.

Review existing webhooks and investigate suspicious outbound activity; apply changes through normal testing and change control.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.

Extracted Entities