A Hidden Flaw in Popular Web Radio Software Could Let Hackers Take Over Your Station

If someone on your team can upload music to your web radio station, they may also be able to quietly seize control of your entire server — and the software that millions of independent broadcasters rely on just confirmed it.

Who's at Risk — and How Big Is This?

AzuraCast is the go-to self-hosted platform for independent internet radio operators: community stations, college broadcasters, podcast networks, hobbyist DJs, and small media organizations who want to run their own stream without handing data to a commercial provider. The project has been downloaded hundreds of thousands of times and powers stations across dozens of countries. If your station runs on AzuraCast and you haven't updated recently, this vulnerability — officially tracked as CVE-2026-42605 — puts your entire server at risk of a silent, complete takeover.

The impact goes beyond losing your radio station. These servers often live on shared infrastructure. A compromised machine can become a launchpad for attacks on other services, a host for malware, or a surveillance tool. For volunteer-run community stations, that kind of breach can be existential — legally, financially, and reputationally.

What an Attacker Can Actually Do

Here's the scenario in plain English. Imagine you run a community radio station and you've given a volunteer DJ — someone you trust — the ability to upload music files through your station's web interface. That's a completely normal, everyday permission. Under this vulnerability, that same DJ could craft a specially named file upload request that tricks the server into saving a file outside the folder where music is supposed to live. Instead of landing in your station's audio library, the file lands somewhere far more dangerous: the web server's public folder, which the internet can directly access and execute.

What gets dropped there isn't a song. It's a "webshell" — a tiny but devastating piece of code disguised as a normal web file. Once it's sitting in the right place, the attacker simply visits a URL in their browser. The server, not knowing any better, runs the code. From that moment on, the attacker has the same level of access as the software itself — they can read every file on the machine, steal credentials stored in the station's database, install persistent backdoors, pivot to other systems on the same network, or simply hold the whole thing for ransom. And they can do all of this while your station keeps broadcasting, with no visible sign that anything has gone wrong.

The particularly uncomfortable part: this doesn't require a sophisticated outside hacker. It requires someone who already has a login and permission to manage media — a bar that's often quite low in volunteer-run or community broadcasting environments where access is shared casually.

The Technical Detail That Matters

For security researchers and administrators who want the specifics: the vulnerability lives in the Flow.js media upload endpoint (POST /api/station/{station_id}/files/upload). The currentDirectory request parameter — which tells the server where to save the uploaded file — is passed directly to the filesystem without any sanitization of path traversal sequences (i.e., ../ chains). On the default local filesystem storage backend, this allows an authenticated user to walk up and out of the station's designated media directory and write to any path the web process has permission to reach, including the PHP-executable web root. The vulnerability is classified as a path traversal leading to remote code execution and carries a CVSS score of 8.8 (HIGH).

Has Anyone Been Attacked Yet?

As of publication, no active exploitation has been confirmed in the wild. The AzuraCast development team patched the issue in version 0.23.6 and disclosed it responsibly. There are no known campaigns, no reported victims, and no public proof-of-concept exploit code circulating — yet. But security teams familiar with how these disclosures play out know that window can close fast. Once a CVE is public and the patch is available, attackers routinely reverse-engineer the fix to build working exploits within days, sometimes hours. The authentication requirement offers some protection — a random internet stranger can't just walk in — but insider threats, compromised volunteer accounts, or stations with weak password hygiene are all realistic attack vectors.

The vulnerability was discovered and reported to the AzuraCast project, which responded with a patch. The community should treat this as a serious, time-sensitive issue even without confirmed in-the-wild exploitation.

What You Need to Do Right Now

There are three steps every AzuraCast operator should take immediately, in this order:

1. Update to AzuraCast version 0.23.6 or later — today. This is the patched release. Log into your server, pull the latest update using your standard AzuraCast update process (./update.sh for most installations), and verify the version number in your admin dashboard afterward. If your station is managed by a third party or hosting service, contact them immediately and confirm they have applied the patch.
2. Audit who has media management permissions on your station. Go to your station's user permission settings and review every account that has the ability to upload or manage files. Remove permissions from accounts that don't actively need them. Change passwords for all accounts with elevated access — especially shared or volunteer accounts — and enable two-factor authentication if your setup supports it. Least-privilege access isn't bureaucracy; this vulnerability is exactly why it exists.
3. Check your web root for unexpected PHP files. If you have any concern that your station may have been compromised before you patched, inspect the publicly accessible directories of your AzuraCast installation for any .php files that don't belong there. A quick command like find /var/azuracast/www -name "*.php" -newer /var/azuracast/www/index.php can surface recently created files worth investigating. If you find anything suspicious, treat the server as compromised: take it offline, preserve logs, and rebuild from a known-clean backup rather than trying to clean in place.

CVE-2026-42605 affects all AzuraCast installations prior to version 0.23.6 running on the default local filesystem storage backend. Cloud storage backends may limit exploitability but users should still update immediately. CVSS score: 8.8 (HIGH).