Summary
AzuraCast before 0.23.6 contains a code injection vulnerability in the remote relay password field caused by incomplete migration from an unsafe string-cleaning method. An attacker with RemoteRelays station permission may inject nested Liquidsoap interpolation syntax, potentially executing arbitrary code in the Liquidsoap process, exposing internal API keys, or disrupting station operations.
Affected context
The issue occurs in AzuraCast station configurations that support remote relays and process relay password values through Liquidsoap. It becomes risky when a user has the RemoteRelays station permission and the affected input reaches Liquidsoap without complete neutralization of interpolation syntax.
Exploit preconditions
- Attack surface: The remote relay password configuration field
- Required access: A station account or role with RemoteRelays permission
- Trigger point: Processing the configured relay password by the Liquidsoap process
- Why exploitation is possible: Incomplete input sanitization allows nested Liquidsoap interpolation syntax to be interpreted as executable logic
Why this happens
The vulnerability results from an incomplete migration between string-processing methods, leaving the remote relay password field exposed to a less restrictive cleaning path. As a result, attacker-controlled input can retain nested Liquidsoap interpolation constructs that are evaluated by the interpreter rather than treated solely as data. This behavior maps to CWE-94: Improper Control of Generation of Code, because input is allowed to influence executable expressions in a processing context.
Potential impact
- Arbitrary code execution within the Liquidsoap process
- Disclosure of internal API keys or other process-accessible secrets
- Modification or disruption of station operation
- Compromise of data or services accessible to the affected process
- Potential lateral movement if the process has excessive permissions
General mitigation guidance
Mitigation generally focuses on ensuring that relay credentials remain data-only values throughout configuration processing.
Common defensive patterns include:
- Applying one consistent, context-appropriate encoding or validation routine to every relay password input
- Using allowlist validation for credential formats and rejecting interpreter control syntax
- Keeping user-controlled values separate from generated Liquidsoap expressions
- Avoiding dynamic code construction when structured configuration APIs are available
- Running Liquidsoap and related station services with least-privilege permissions
- Limiting access to internal API keys and using narrowly scoped credentials
- Treating station-level configuration permissions as security-sensitive
How teams detect issues like this
Organizations can look for this vulnerability class through:
- Static analysis rules that identify user-controlled values concatenated into Liquidsoap expressions or other executable configuration
- Code review checks for incomplete migrations between sanitization or encoding methods
- Tests using nested interpolation markers and other interpreter-control characters as benign security cases
- Runtime monitoring for unexpected Liquidsoap process behavior, configuration changes, or access to protected endpoints
- Policy enforcement requiring strict schemas and context-specific output encoding for station configuration fields
Automated code review and dependency assessment tools may help identify unsafe data-to-code boundaries, but findings should be validated against the actual interpreter behavior.
