AzuraCast before 0.24.0 SSRF Filter Bypass via Webhook Connector Redirects
Affects AzuraCast before 0.24.0 when a Mastodon, Telegram, GroupMe, or RadioReg webhook connector uses a redirecting URL, reachable by users with the station WebHooks permission. Fixed in 0.24.0.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 0.24.0
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. Mastodon, Telegram, GroupMe, or RadioReg webhook connector configured with a redirecting URL Attacker holds the station-scoped WebHooks permission Filter for local user URLs is enabled (its default)
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 15/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
AzuraCast, the web radio management platform, is affected by a server-side request forgery flaw in its webhook connectors. An attacker who has the station WebHooks permission can reach it remotely over the network with low-privilege login, and can use redirecting URLs to reach internal services and read their responses through the test logs.
Read the original description
AzuraCast before 0.24.0 contains a server-side request forgery vulnerability that allows users with station WebHooks permission to bypass the UserUrlFilter SSRF guard through HTTP redirects. Attackers can configure Mastodon, Telegram, GroupMe, or RadioReg webhooks pointing to a redirecting URL, causing the Guzzle client to reach internal services and expose responses via test logs.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure8/25Specific setups only, reachable over the network
- Reach?/20Unknown. No tracked technology or package matched
- Severity7.1/10CVSS 7.1
- No patch0/5No signal
What would change the score
- Would score about 65 if added to CISA KEV
- Would score about 60 if CISA's SSVC rates exploitation active
- Would score about 22 if CISA's SSVC rates it automatable
What to do
Check whether your setup matches what the bug needs.
Mastodon, Telegram, GroupMe, or RadioReg webhook connector configured with a redirecting URL Attacker holds the station-scoped WebHooks permission Filter for local user URLs is enabled (its default)Upgrade to a fixed version: 0.24.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- AzuraCast AzuraCast
fixed in 0.24.0
Evidence 2
- Advisory
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-124442
Is CVE-2026-124442 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
A user with the station-scoped WebHooks permission can set a webhook to a URL that redirects to internal addresses, which gets past the SSRF filter. The server then requests those internal addresses, and the responses appear in the webhook test log, where the user can read them, such as internal services or cloud metadata.Source: vulncheck.com, github.com
Which versions are affected by CVE-2026-124442?
AzuraCast: before 0.24.0.Source: cve.now feed data
Am I affected, and how do I check?
Versions before 0.24.0 are affected. The setup involves a Mastodon, Telegram, GroupMe, or RadioReg webhook connector configured with a redirecting URL, and the local user URL filter is on by default. To check, look at the AzuraCast version and at the webhook connector URLs configured on each station.Source: vulncheck.com, github.com
How do I fix CVE-2026-124442?
Upgrade AzuraCast to 0.24.0 or later. The sources give no workaround.Source: vulncheck.com, github.com