Summary
AzuraCast versions before 0.23.8 contain a DQL injection vulnerability in the sortOrder parameter used by a searchable-list API action. An attacker who can submit requests to the affected endpoint may inject DQL expressions and retrieve sensitive database information, including user credentials and station settings.
Affected context
The vulnerability occurs in AzuraCast deployments using the affected searchable-list API action and processing client-controlled sortOrder values as part of a database query. Risk depends on the endpoint being reachable by an attacker and on the application account having access to sensitive records.
Exploit preconditions
- Attack surface: An API endpoint that accepts the
sortOrderparameter - Required access: Ability to send requests to the affected API action; authentication requirements depend on deployment and endpoint controls
- Trigger point: Server-side construction or execution of a database query using the supplied sort-order expression
- Why exploitation is possible: Untrusted query fragments are incorporated into DQL without sufficiently restricting the permitted sort fields or expressions
Why this happens
The underlying bug is an injection flaw in which externally supplied sorting data is treated as executable DQL rather than as a constrained data value. When query structure is assembled from untrusted input without allowlisting valid fields and directions, an attacker may alter query behavior or introduce expressions that expose data. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, a category that also covers injection into database query languages such as DQL.
Potential impact
- Sensitive database records may be disclosed
- User credentials or credential-related data could be exposed
- Station settings and other application configuration may be retrieved
- Query integrity may be affected
- Exposed information could support further attacks against the application or its users
General mitigation guidance
Mitigation generally focuses on ensuring that sort criteria cannot alter query structure.
Common defensive patterns include:
- Mapping client-provided sort names to a fixed server-side allowlist of fields
- Accepting only explicitly supported sort directions
- Building queries with framework-supported identifiers rather than concatenated fragments
- Applying parameterization wherever values, rather than identifiers, are supplied
- Enforcing authorization and least-privilege database permissions
- Reducing sensitive data exposure through narrowly scoped query projections
- Treating all API parameters as untrusted, including parameters intended only for ordering
How teams detect issues like this
Organizations can assess for this class of issue through:
- Static analysis rules that flag concatenation of request parameters into DQL or SQL
- Code review checks for dynamic query construction in sorting, filtering, and pagination logic
- Tests that verify unsupported sort fields and expressions are rejected
- Runtime monitoring for unusual query errors, unexpected sorting expressions, or abnormal data-access patterns
- API policy enforcement that constrains sort parameters to documented field names and directions
Automated security review tools may help identify unsafe query construction, but findings should be validated against the application's query framework and authorization model.
