Cross-Site Request Forgery (CSRF) in azuracast/azuracast


Reported on

Aug 26th 2021

✍️ Description

Attacker able to enable any Streamer/DJ account section with CSRF attack.

It does not matter at all that your application run in localhost or elsewhere, just it is enough to run on a browser and another low privilege user or attackers know the IP address or hostname of your application.

In CSRF attacks it is necessary that a user logged into your application and just going to a malicious website and after that only with a redirection attacker can perform attack on unprotected endpoint, this means only with visiting a site a unwanted action will be perform without that user aware from that.

Or users with low level privilege can send a link to other users and admins with higher privilege and then their malicious request will be executed without that victim users and admins be aware about that.

🕵️‍♂️ Proof of Concept

1.First of all admin or user with right privileges already should be logged in Browser.

2.Open the PoC.html (it is auto-submit).

3.Here Streamer/DJ accounts section will be enabled after the PoC.html file opened.

// PoC.html

  <script>history.pushState('', '', '/')</script>
    <form action="">
      <input type="hidden" name="enable" value="1" />
      <input type="submit" value="Submit request" />

This PoC can perform attack without that users noticed and Also PoC can send multiple request at same time that means attacker can Bruteforce all possible actions ( with using multiple Iframe )

💥 Impact

This vulnerability is capable of make high damage of integrity of system.


The easiest way that you set strict attribute on each cookie, Or you set Lax and Use GET requests only for receiving data not changing them.

The best way is that you set a CSRF token in each endpoint.

2 years ago


Hey Melbin, I've just emailed the repo's maintainers for you. Waiting to hear back, good job!

2 years ago


@admin Hey dear Ziding Zhang, How are you today? I hope for you to be good. I'm Amammad.

2 years ago


Apologies, how could I get that wrong?! Good day to you too, Amammad.

We have contacted a member of the azuracast team and are waiting to hear back 2 years ago
Buster Neece validated this vulnerability 2 years ago
amammad has been awarded the disclosure bounty
The fix bounty is now up for grabs
Buster Neece
2 years ago


This is perhaps the most significant security issue we've been alerted to in recent memory, and our own investigation confirmed it was indeed valid.

Granted, the exploit's surface is limited to a currently-logged-in user with administrative permissions visiting a specially-crafted web site that exploits those permissions, but the potential for damage is significant if an attacker is determined and knows what API calls to make to, say, make themselves an administrator.

I've overhauled the authentication code for API calls in the latest AzuraCast version to require a CSRF validation token if visiting a non-GET-method API page and the only authentication present is your logged-in user session. This matches the protection that already existed elsewhere in the system for standard forms.

This fix is now available in the Rolling Release channel for AzuraCast and will be included in the next stable release.

Buster Neece marked this as fixed with commit 5a2f1a 2 years ago
Buster Neece has been awarded the fix bounty
This vulnerability will not receive a CVE
to join this conversation