AzuraCast CVE-2026-100849

Requires an authenticated AzuraCast user holding the station-scoped WebHooks permission (PR:L) - not unauthenticated. The affected connectors are the Generic and Discord webhook connectors, whose getValidUrl() filter only blocks literal link-local IPs (169.254.0.0/16, fe80::/10); loopback and RFC1918 private ranges pass, and any non-literal hostname makes the IP-parsing call throw, skipping the check entirely. Exploitation is meaningful only where the AzuraCast host can route to sensitive internal/loopback services. The PUT /station/{id}/webhook/{id}/test endpoint lets the same low-privileged user trigger the request on demand. Limiting factors: valid low-privilege account required, impact is largely a blind outbound POST (Now-Playing payload) rather than confirmed response exfiltration, and no patch exists so mitigation must be compensating (network egress controls, restricting WebHooks permission).

This is a moderate, not urgent, priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) correctly reflects a network-reachable flaw with low attack complexity that requires an authenticated, low-privileged account - specifically a user holding the station-scoped WebHooks permission - so it is NOT unauthenticated. No EPSS score, CISA KEV listing, or public POC is present in the provided intelligence; SSVC-style signals are therefore effectively 'exploitation: none / automatable: unknown'. That means there is no evidence of active exploitation, and the requirement for a valid WebHooks-capable account meaningfully narrows the attacker population. The primary caveats are: (1) no patched version existed at advisory time, so there is no clean remediation path, and (2) the vendor's CVSS 4.0 rates confidentiality high (VC:H) whereas the described impact is a blind/semi-blind outbound POST of Now-Playing data to an attacker-chosen internal target - internal-service reachability and limited data exposure, which I assess as lower (C:L). Net: a real but bounded SSRF that matters most where AzuraCast is co-located with sensitive internal services.

A user with only the station-scoped WebHooks permission configures a Generic or Discord webhook whose URL points at an internal, loopback (127.0.0.1), or RFC1918 private address that the host-based IP filter fails to reject. They then call PUT /station/{id}/webhook/{id}/test to make the AzuraCast server issue an outbound HTTP POST to that internal target on demand, reaching services not exposed to the internet. No public exploit code is identified at time of analysis, though the mechanics are fully detailed in the VulnCheck and GitHub advisories.