Summary
AzuraCast webhook URL validation can allow a station-scoped user to configure Generic or Discord webhooks that target loopback, private-network, or other internal addresses. When the webhook is tested or triggered, the server may send station Now Playing data to the selected destination, creating a server-side request forgery risk.
Affected context
The issue occurs in AzuraCast deployments where users with the station-scoped WebHooks permission can create or modify Generic or Discord webhook connectors. The validation logic blocks only literal link-local IP addresses, while loopback and RFC1918 private ranges remain usable; hostnames that cause IP parsing to fail may also bypass the intended check. The webhook test endpoint provides an on-demand trigger for the outbound request.
Exploit preconditions
- Attack surface: Station webhook configuration and the webhook test endpoint
- Required access: A user account with station-scoped WebHooks permission
- Trigger point: Webhook delivery or an explicit request to the station webhook test endpoint
- Target condition: The configured URL resolves to a loopback, private-network, internal, or otherwise reachable server-side destination
- Why exploitation is possible: URL validation does not comprehensively restrict internal destinations and may skip filtering when hostname parsing fails
Why this happens
The vulnerability results from incomplete server-side URL validation. The implementation evaluates only a narrow set of literal link-local addresses, does not consistently reject loopback or private-network destinations, and treats address-parsing failures as a reason to bypass the restriction. This maps to CWE-918: Server-Side Request Forgery, where attacker-influenced URLs cause a trusted server to make requests to destinations the attacker could not directly access.
Potential impact
- An attacker may cause requests to internal services from the AzuraCast server
- Internal endpoints may receive station Now Playing data
- Cloud or infrastructure metadata could potentially be exposed if reachable
- Network boundaries and access controls may be bypassed through the server's connectivity
- Internal services could be probed or affected by unexpected HTTP requests
General mitigation guidance
Mitigation typically focuses on enforcing a complete outbound-request policy rather than relying on a narrow denylist.
Common defensive patterns include:
- Resolve configured destinations and reject loopback, link-local, private, reserved, multicast, and otherwise non-public address ranges
- Validate the final destination after DNS resolution and again when following redirects
- Prefer an allowlist of approved webhook hosts or egress destinations
- Restrict outbound network access from the application to only required services
- Revalidate URLs at request time to account for DNS changes and rebinding behavior
- Minimize the data included in webhook payloads and apply least-privilege service networking
- Treat hostname parsing failures and ambiguous address formats as validation failures rather than bypass conditions
How teams detect issues like this
Organizations can detect SSRF exposure through:
- Static analysis checks for user-controlled URLs passed to HTTP clients
- Code review of hostname parsing, DNS resolution, redirect handling, and IP-range filtering
- Tests covering loopback, private, link-local, IPv6, encoded, mixed-format, and DNS-rebinding destinations
- Egress firewall, proxy, and service-mesh policies that alert on application traffic to restricted networks
- Monitoring webhook destinations and outbound requests for unexpected internal address ranges
- Policy enforcement requiring approved webhook domains and explicit outbound network permissions
Automated security review tools may help identify URL-fetching code, but runtime network controls remain important.
