Ghsa — CraftedSignal Threat Feed

AzuraCast Liquidsoap Code Injection in Remote Relay Password

hello@craftedsignal.io — Mon, 04 May 2026 21:19:55 +0000

AzuraCast versions 0.23.5 and earlier are vulnerable to a Liquidsoap code injection vulnerability in the remote relay password field. This flaw stems from an incomplete migration of user-controlled fields from the vulnerable cleanUpString() method to the safe toRawString() method. Specifically, while commit ff49ef4 (dated 2026-03-06) addressed most fields, the remote relay password field continues to use cleanUpString(), which can be bypassed via nested Liquidsoap interpolation syntax (#{#{EXPR}}). An attacker with the RemoteRelays station permission can exploit this to inject arbitrary Liquidsoap code, potentially achieving remote code execution, disclosing internal API keys, reading and writing files within the Liquidsoap container, and disrupting station operation. This vulnerability allows attackers with minimal privileges to escalate their access within the AzuraCast environment.

Attack Chain

An attacker with RemoteRelays station permission crafts a malicious payload containing nested Liquidsoap interpolation syntax (#{#{EXPR}}).
The attacker sends a PUT request to /api/station/{station_id}/remote/{id} to update the remote relay’s password, including the crafted payload in the source_password field.
The mb_substr function truncates the password to 100 characters, but the payload remains within this limit.
The ConfigWriter::getOutputString() function calls the vulnerable cleanUpString() method on the password during station configuration regeneration.
The cleanUpString() method’s ungreedy regex fails to properly sanitize the nested interpolation, resulting in a bypass.
The bypassed payload is embedded within a double-quoted string in the Liquidsoap configuration file.
The Liquidsoap process loads the updated configuration file, triggering the evaluation of the injected Liquidsoap code.
The attacker achieves arbitrary code execution within the Liquidsoap process container or gains access to sensitive information, such as the internal API key.

Impact

Successful exploitation of this vulnerability can lead to severe consequences, including arbitrary code execution within the Liquidsoap process container, potentially compromising the entire AzuraCast installation. The disclosure of the internal API key grants the attacker full control over the station’s API. Furthermore, the ability to read and write files within the Liquidsoap container allows for further exploitation and persistence. The attacker can also disrupt station operation by injecting malicious configurations that crash the Liquidsoap process. The low privilege requirement (only RemoteRelays permission) makes this vulnerability highly accessible to malicious actors.

Recommendation

Immediately replace the cleanUpString() method with toRawString() for the remote relay password field in ConfigWriter.php, as described in the provided fix, to prevent Liquidsoap code injection.
Adjust the Shoutcast suffix append logic to ensure compatibility with raw strings after applying the toRawString() fix in ConfigWriter.php.
Deploy the Sigma rule “Detect AzuraCast Liquidsoap Code Injection via API” to detect attempts to exploit this vulnerability through malicious API requests targeting the remote relay password field.
Monitor webserver logs for PUT requests to /api/station/*/remote/* containing the string #{#{ in the request body, indicating a potential injection attempt, as shown in the PoC.

Note Mark OIDC Authentication Bypass via Hardcoded Password

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

A critical authentication bypass vulnerability affects note-mark deployments configured with OIDC authentication. The vulnerability stems from the IsPasswordMatch function in backend/db/models.go, which falls back to a hardcoded bcrypt("null") hash when a user has no stored password. This occurs because OIDC-registered users are created with an empty password. As a result, any attacker can authenticate as an OIDC user by submitting the password “null” to the internal login endpoint (POST /api/auth/token). This issue affects note-mark version 0.19.2 and potentially earlier versions. The default configuration ships with both authentication paths side-by-side, so any site that turns on OIDC is affected, allowing for potential account takeover and data exfiltration.

Attack Chain

An attacker identifies a note-mark instance with OIDC enabled and internal login enabled (default configuration). The attacker can confirm this by accessing /api/info.
The attacker enumerates valid usernames via the /api/users/search endpoint (anonymous user search enabled by default).
The attacker sends a POST request to /api/auth/token with the target username and password “null”.
The IsPasswordMatch function in backend/db/models.go is called. Since OIDC-registered users have an empty password, the function uses the nullPasswordHash.
The bcrypt.CompareHashAndPassword function compares nullPasswordHash with the provided password “null”, resulting in a successful match.
The server issues an Auth-Session-Token cookie to the attacker.
The attacker uses the valid session cookie to access the target user’s account via /api/users/me or other authenticated endpoints.
The attacker persists access by updating the target user’s password via PUT /api/users/me/password using “null” as the existing password, locking out the legitimate user and gaining persistent access.

Impact

Successful exploitation of this vulnerability allows an attacker to fully take over OIDC-only user accounts on affected note-mark deployments. This includes reading private notebooks, note markdown, and uploaded assets. An attacker can also write, edit, or delete anything the compromised user owns, leading to significant data loss and confidentiality breaches. The vulnerability is especially severe due to the default configuration enabling both OIDC and internal login paths, making it easy for attackers to exploit.

Recommendation

Apply the recommended fix by rejecting the login path for users with no stored password in backend/services/auth.go and backend/services/users.go as detailed in the advisory. This directly addresses the vulnerability by preventing authentication with the “null” password.
Monitor network traffic for POST requests to /api/auth/token with a request body containing "password":"null" to identify potential exploitation attempts using the provided Sigma rule.
Consider disabling internal logins (EnableInternalLogin) if OIDC is the sole authentication method used, mitigating the risk by removing the vulnerable login path.