{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/ghsa/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AzuraCast (\u003c= 0.23.5)"],"_cs_severities":["high"],"_cs_tags":["azuracast","code-injection","liquidsoap","ghsa"],"_cs_type":"advisory","_cs_vendors":["AzuraCast"],"content_html":"\u003cp\u003eAzuraCast 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 \u003ccode\u003ecleanUpString()\u003c/code\u003e method to the safe \u003ccode\u003etoRawString()\u003c/code\u003e method. Specifically, while commit \u003ccode\u003eff49ef4\u003c/code\u003e (dated 2026-03-06) addressed most fields, the remote relay password field continues to use \u003ccode\u003ecleanUpString()\u003c/code\u003e, which can be bypassed via nested Liquidsoap interpolation syntax (\u003ccode\u003e#{#{EXPR}}\u003c/code\u003e). An attacker with the \u003ccode\u003eRemoteRelays\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker with \u003ccode\u003eRemoteRelays\u003c/code\u003e station permission crafts a malicious payload containing nested Liquidsoap interpolation syntax (\u003ccode\u003e#{#{EXPR}}\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker sends a \u003ccode\u003ePUT\u003c/code\u003e request to \u003ccode\u003e/api/station/{station_id}/remote/{id}\u003c/code\u003e to update the remote relay\u0026rsquo;s password, including the crafted payload in the \u003ccode\u003esource_password\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003emb_substr\u003c/code\u003e function truncates the password to 100 characters, but the payload remains within this limit.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eConfigWriter::getOutputString()\u003c/code\u003e function calls the vulnerable \u003ccode\u003ecleanUpString()\u003c/code\u003e method on the password during station configuration regeneration.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ecleanUpString()\u003c/code\u003e method\u0026rsquo;s ungreedy regex fails to properly sanitize the nested interpolation, resulting in a bypass.\u003c/li\u003e\n\u003cli\u003eThe bypassed payload is embedded within a double-quoted string in the Liquidsoap configuration file.\u003c/li\u003e\n\u003cli\u003eThe Liquidsoap process loads the updated configuration file, triggering the evaluation of the injected Liquidsoap code.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves arbitrary code execution within the Liquidsoap process container or gains access to sensitive information, such as the internal API key.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;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 \u003ccode\u003eRemoteRelays\u003c/code\u003e permission) makes this vulnerability highly accessible to malicious actors.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately replace the \u003ccode\u003ecleanUpString()\u003c/code\u003e method with \u003ccode\u003etoRawString()\u003c/code\u003e for the remote relay password field in \u003ccode\u003eConfigWriter.php\u003c/code\u003e, as described in the provided fix, to prevent Liquidsoap code injection.\u003c/li\u003e\n\u003cli\u003eAdjust the Shoutcast suffix append logic to ensure compatibility with raw strings after applying the \u003ccode\u003etoRawString()\u003c/code\u003e fix in \u003ccode\u003eConfigWriter.php\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect AzuraCast Liquidsoap Code Injection via API\u0026rdquo; to detect attempts to exploit this vulnerability through malicious API requests targeting the remote relay password field.\u003c/li\u003e\n\u003cli\u003eMonitor webserver logs for PUT requests to \u003ccode\u003e/api/station/*/remote/*\u003c/code\u003e containing the string \u003ccode\u003e#{#{\u003c/code\u003e in the request body, indicating a potential injection attempt, as shown in the PoC.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T21:19:55Z","date_published":"2026-05-04T21:19:55Z","id":"/briefs/2024-01-azuracast-liquidsoap-injection/","summary":"AzuraCast is vulnerable to a Liquidsoap code injection vulnerability due to the incomplete migration from `cleanUpString()` to `toRawString()` in the remote relay password field, allowing a user with the `RemoteRelays` station permission to inject arbitrary Liquidsoap code by exploiting nested interpolation syntax, leading to arbitrary code execution, API key disclosure, and station disruption.","title":"AzuraCast Liquidsoap Code Injection in Remote Relay Password","url":"https://feed.craftedsignal.io/briefs/2024-01-azuracast-liquidsoap-injection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["note-mark"],"_cs_severities":["critical"],"_cs_tags":["authentication-bypass","credential-access","note-mark","ghsa"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA critical authentication bypass vulnerability affects note-mark deployments configured with OIDC authentication. The vulnerability stems from the \u003ccode\u003eIsPasswordMatch\u003c/code\u003e function in \u003ccode\u003ebackend/db/models.go\u003c/code\u003e, which falls back to a hardcoded \u003ccode\u003ebcrypt(\u0026quot;null\u0026quot;)\u003c/code\u003e 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 \u0026ldquo;null\u0026rdquo; to the internal login endpoint (\u003ccode\u003ePOST /api/auth/token\u003c/code\u003e). 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies a note-mark instance with OIDC enabled and internal login enabled (default configuration). The attacker can confirm this by accessing \u003ccode\u003e/api/info\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates valid usernames via the \u003ccode\u003e/api/users/search\u003c/code\u003e endpoint (anonymous user search enabled by default).\u003c/li\u003e\n\u003cli\u003eThe attacker sends a POST request to \u003ccode\u003e/api/auth/token\u003c/code\u003e with the target username and password \u0026ldquo;null\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eIsPasswordMatch\u003c/code\u003e function in \u003ccode\u003ebackend/db/models.go\u003c/code\u003e is called. Since OIDC-registered users have an empty password, the function uses the \u003ccode\u003enullPasswordHash\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ebcrypt.CompareHashAndPassword\u003c/code\u003e function compares \u003ccode\u003enullPasswordHash\u003c/code\u003e with the provided password \u0026ldquo;null\u0026rdquo;, resulting in a successful match.\u003c/li\u003e\n\u003cli\u003eThe server issues an \u003ccode\u003eAuth-Session-Token\u003c/code\u003e cookie to the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the valid session cookie to access the target user\u0026rsquo;s account via \u003ccode\u003e/api/users/me\u003c/code\u003e or other authenticated endpoints.\u003c/li\u003e\n\u003cli\u003eThe attacker persists access by updating the target user\u0026rsquo;s password via \u003ccode\u003ePUT /api/users/me/password\u003c/code\u003e using \u0026ldquo;null\u0026rdquo; as the existing password, locking out the legitimate user and gaining persistent access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the recommended fix by rejecting the login path for users with no stored password in \u003ccode\u003ebackend/services/auth.go\u003c/code\u003e and \u003ccode\u003ebackend/services/users.go\u003c/code\u003e as detailed in the advisory. This directly addresses the vulnerability by preventing authentication with the \u0026ldquo;null\u0026rdquo; password.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for POST requests to \u003ccode\u003e/api/auth/token\u003c/code\u003e with a request body containing \u003ccode\u003e\u0026quot;password\u0026quot;:\u0026quot;null\u0026quot;\u003c/code\u003e to identify potential exploitation attempts using the provided Sigma rule.\u003c/li\u003e\n\u003cli\u003eConsider disabling internal logins (\u003ccode\u003eEnableInternalLogin\u003c/code\u003e) if OIDC is the sole authentication method used, mitigating the risk by removing the vulnerable login path.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-note-mark-auth-bypass/","summary":"A critical authentication bypass vulnerability in note-mark allows attackers to authenticate as any OIDC-registered user by submitting the password 'null' to the internal login endpoint due to a hardcoded bcrypt hash fallback, potentially leading to account takeover and persistent access.","title":"Note Mark OIDC Authentication Bypass via Hardcoded Password","url":"https://feed.craftedsignal.io/briefs/2024-01-03-note-mark-auth-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed — Ghsa","version":"https://jsonfeed.org/version/1.1"}