AzuraCast EUVD-2026-115853

Requires an authenticated AzuraCast user holding the station-scoped StationPermissions::WebHooks permission for any station (despite the supplied CVSS PR:N, the vendor advisory makes this permission mandatory). The attacker must use one of the four unpatched connectors - Mastodon (instance_url), Telegram (api), GroupMe (api), or RadioReg (webhookurl) - set its destination to an internal address, and trigger the test webhook endpoint (PUT /station/{id}/webhook/{id}/test) for immediate dispatch. Limiting factors: the WebHooks permission gate (not anonymous); only these four connectors are affected while Generic/Discord/MatomoAnalytics are already guarded by UserUrlFilter; and the highest-value outcomes (cloud-metadata credential theft, Docker-internal pivoting) depend on the instance running in a cloud/containerized environment where such internal endpoints are reachable. Affected: all versions through 0.23.8 including the earlier GHSA-3jp3-3wqw-jvw4 fix; resolved only in 0.24.0.

This is a genuine but moderate-priority issue rather than a high-CVSS-but-low-real-risk one, and the signals are mostly consistent. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 6.9 (medium) and emphasizes remote, low-complexity reach with limited integrity/confidentiality impact that lands on subsequent systems (SC:L/SI:L/SA:L) - exactly matching an SSRF that pivots from AzuraCast into internal services. However, there is a clear conflict: the supplied CVSS uses PR:N (unauthenticated), yet the vendor GHSA advisory states the attack requires the station-scoped StationPermissions::WebHooks permission, so real exploitation is authenticated-insider or compromised-account, not anonymous - treat PR:N as inaccurate and PR:L as correct. No EPSS score was provided and the CVE is not in CISA KEV, so there is no evidence of widespread or active exploitation; vuln.today assigns a 'this_month' decision label (not act_now/emergency), consistent with an authenticated SSRF rather than a drive-by. The sharpest risk is deployment-dependent: in cloud or Docker-hosted AzuraCast instances the advisory explicitly demonstrates reaching 169.254.169.254 (cloud metadata) and 172.17.0.1 Docker-internal services, and responses are written to logs - so an attacker with WebHooks permission can read internal/metadata responses, potentially harvesting cloud credentials. Because this is an incomplete fix of GHSA-3jp3-3wqw-jvw4 (the guard was applied to only 3 of 7 connectors), environments that believed they were patched remain exposed, which raises practical urgency above the raw score for cloud-hosted operators.

A low-privilege station user (or someone who has phished/compromised such an account) with the WebHooks permission creates a Mastodon, Telegram, GroupMe, or RadioReg webhook whose destination (instance_url, api, or webhookurl) points at an internal address such as http://169.254.169.254 or a Docker-internal service, then invokes the test endpoint (PUT /station/{id}/webhook/{id}/test) to force an immediate outbound request. The server issues the request to the internal target and logs the response, letting the attacker read cloud-metadata or private-service responses. No weaponized public exploit code is confirmed, but the vendor GHSA advisory publishes a complete step-by-step reproduction chain, and with AV:N/AC:L the technical barrier to reproduction is low.