Summary
AzuraCast exposes Icecast and Shoutcast administrative, source, and relay passwords through a station profile API endpoint to users who have only View Station Page permission. An authenticated view-only user may obtain these plaintext credentials and use administrative access to the associated streaming server without requiring Broadcasting permission.
Affected context
The vulnerability occurs in AzuraCast deployments where the station profile endpoint returns frontend configuration data containing Icecast or Shoutcast credentials without sufficiently checking the requesting user's privileges. It is relevant to affected AzuraCast releases before 0.23.8 when a user has View Station Page access but lacks permissions intended for broadcasting or streaming-server administration.
Exploit preconditions
- Attack surface: Authenticated station profile API access
- Required access: An AzuraCast account with View Station Page permission
- Trigger point: Retrieval of the station profile data through the affected API endpoint
- Why exploitation is possible: Authorization checks do not adequately restrict sensitive credential fields to users with a legitimate administrative need, allowing plaintext passwords to be returned in the JSON response
Why this happens
The underlying issue is an authorization boundary failure combined with excessive disclosure of sensitive configuration data. The endpoint exposes credentials to a broader audience than intended because permission enforcement is not aligned with the sensitivity of the returned fields. This maps to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, with the broken access control allowing a lower-privileged authenticated user to obtain secrets reserved for administrative functions.
Potential impact
- Disclosure of Icecast or Shoutcast administrative, source, and relay passwords
- Unauthorized access to streaming-server administrative interfaces
- Changes to station, stream, or relay configuration
- Service disruption or unauthorized content manipulation
- Further compromise if exposed credentials are reused elsewhere
General mitigation guidance
Mitigation generally focuses on enforcing least-privilege authorization at the field and endpoint levels.
Common defensive patterns include:
- Excluding administrative and source credentials from responses intended for view-only users
- Applying explicit authorization checks before returning each sensitive field
- Returning only the minimum data required by the frontend
- Storing secrets outside broadly readable profile objects and avoiding plaintext exposure
- Rotating credentials that may have been disclosed
- Using separate service identities with narrowly scoped permissions
- Preventing credential reuse across application and streaming-server components
How teams detect issues like this
Organizations can identify similar weaknesses through:
- Static and dynamic analysis of API authorization paths
- Code review checks for sensitive fields included in general-purpose JSON serializers
- Permission-matrix testing across view-only, broadcasting, and administrative roles
- API response scanning for passwords, tokens, and other secret-like values
- Policy enforcement that blocks secrets from user-facing API responses
- Audit-log review for unexpected access to station profile endpoints or streaming-server administration
