CVE-2026-121432 in AzuraCast
Summary
by MITRE • 11/03/2026
AzuraCast before 0.24.0 contains a CRLF injection vulnerability that allows low-privilege station users to inject playlist entries by embedding CR/LF sequences in mount or remote relay display_name values. Attackers with Station:MountPoints or Station:RemoteRelays permission can inject FileN= and TitleN= lines into the public playlist.pls to redirect guest listeners to attacker-controlled streams under the victim station's name.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in AzuraCast versions prior to 0.24.0 represents a critical input validation failure within the application’s handling of metadata fields associated with mount points and remote relays. Specifically, the flaw resides in the processing of display_name values for these entities. When an authenticated user possessing Station:MountPoints or Station:RemoteRelays permissions provides input containing carriage return (CR) and line feed (LF) characters, the system fails to sanitize or escape these sequences before writing them to configuration files used by the underlying streaming server software. This lack of proper validation allows for a Carriage Return Line Feed injection attack, commonly referred to as CRLF injection. The core technical issue is that the application treats user-supplied strings containing control characters as literal text rather than recognizing them as delimiters or structural elements that could alter file parsing logic.
The operational impact of this vulnerability is significant due to its potential for social engineering and traffic redirection. By injecting CR/LF sequences into the display_name field, an attacker can break out of the intended metadata structure and inject arbitrary lines into the public playlist.pls file generated by AzuraCast. This playlist file is typically accessed by listeners connecting to the station’s stream. The injected content allows the insertion of FileN= and TitleN= directives, which are standard parameters in Playlist Source (PLS) files used by media players like Winamp or VLC to determine where audio streams should be fetched from. Consequently, an attacker can manipulate these entries to point listeners toward a malicious server controlled by the adversary while maintaining the appearance that the stream is originating from the legitimate victim station.
This manipulation facilitates several adverse outcomes for both the victims and their audience. For the station administrators, this constitutes a severe reputation risk as they may be perceived as distributing malware or hosting illicit content if the redirected streams contain such material. Furthermore, it enables traffic hijacking where listeners are silently switched to an attacker-controlled stream without any visual indication in many media players that the source has changed. This can lead to unauthorized broadcasting of copyrighted material, phishing attempts via embedded links in metadata, or distribution of malicious payloads disguised as audio content. The vulnerability effectively allows low-privilege users to escalate their impact from simple configuration changes to active network manipulation and potential legal liability for the station owner.
From a classification perspective, this flaw aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component, as the application fails to neutralize special elements that could change the intended command or structure when passed to downstream components like the playlist generator and streaming server. It also relates to CWE-182 Incorrect Behavior Order which suggests that validation may occur after data has already been processed for output in certain code paths. In terms of adversary tactics, this aligns with MITRE ATT&CK techniques related to Command and Control via Application Layer Protocol, specifically the abuse of legitimate services to redirect traffic or establish covert channels. The exploitation requires authentication but only low-level permissions, highlighting a deficiency in role-based access control granularity regarding sensitive configuration outputs.
Mitigation for this vulnerability involves immediate upgrading to AzuraCast version 0.24.0 or later where the input validation logic has been corrected to strictly reject or properly escape CR and LF characters within display_name fields. For organizations unable to upgrade immediately, a temporary workaround includes implementing strict input filtering at the web application firewall level to block requests containing carriage return (%0D) or line feed (%0A) characters in parameters related to mount points and remote relays. Additionally, administrators should review access controls for Station:MountPoints and Station:RemoteRelays permissions, ensuring that only trusted users with a legitimate need can modify these settings. Regular auditing of playlist files and stream metadata is also recommended to detect any signs of tampering or unauthorized redirections promptly.