🛡️ GHSA-qff7-q5fm-8p76 — azuracast
Description
AzuraCast has Missing Permissions Check on Media File Download, Allowing Cross-Station Data Exfiltration
Summary
The GET /api/station/{station_id}/file/{id}/play endpoint, handled by PlayAction, is missing the Middleware\Permissions check that protects all sibling routes in the same /file/{id} route group. Any authenticated user can download media files from any station, regardless of whether they have permissions on that station. In multi-tenant deployments, this enables cross-station media exfiltration.
Details
In backend/config/routes/api_station.php, the /file/{id} route group (lines 407-429) defines four endpoints:
```php
// Line 407-429
$group->group(
'/file/{id}',
function (RouteCollectorProxy $group) {
// GET /file/{id} — has Permissions check ✓
$group->get('', ...)->add(new Middleware\Permissions(StationPermissions::Media, true));
// PUT /file/{id} — has Permissions check ✓
$group->put('', ...)->add(new Middleware\Permissions(StationPermissions::Media, true));
// DELETE /file/{id} — has Permissions check ✓
$group->delete('', ...)->add(new Middleware\Permissions(StationPermissions::DeleteMedia, true));
// GET /file/{id}/play — NO Permissions check ✗
$group->get('/play', Controller\Api\Stations\Files\PlayAction::class)
->setName('api:stations:files:play');
}
);
```
The middleware chain for the /play endpoint is: GetStation → RequireStation → RequireLogin → StationSupportsFeature(Media) → PlayAction. The RequireLogin middleware (backend/src/Middleware/RequireLogin.php) only verifies a valid session/API key exists — it does not check station-level permissions.
The controller at backend/src/Controller/Api/Stations/Files/PlayAction.php:84 calls $this->mediaRepo->requireForStation($id, $station), which verifies the media belongs to the station but performs no authorization check. The findForStation method (StationMediaRepository.php:46-66) accepts both auto-increment integer IDs and unique IDs, making enumeration trivial via sequential integers.
This is notably similar to the regression fixed in commit 7fbc7dd (2026-02-26), which restored a missing group-level Permissions middleware on the adjacent /files group. The /play route was missed in that fix.
PoC
```bash
# Step 1: Create two stations (Station A and Station B) in a multi-tenant AzuraCast instance.
# Upload media files to Station B.
# Step 2: Create a user with permissions ONLY on Station A. Generate an API key for this user.
API_KEY="user-with-only-station-a-access"
# Step 3: Enumerate and download media from Station B (station_id=2) using sequential IDs
# This should return 403 Forbidden, but instead returns the file content
curl -H "X-API-Key: $API_KEY" https://target/api/station/2/file/1/play -o stolen1.mp3
# HTTP 200 OK — file downloaded successfully
curl -H "X-API-Key: $API_KEY" https://target/api/station/2/file/2/play -o stolen2.mp3
# HTTP 200 OK — file downloaded successfully
# Step 4: Verify the same user is correctly blocked on other endpoints in the same group
curl -H "X-API-Key: $API_KEY" https://target/api/station/2/file/1
# HTTP 403 Forbidden — permission check works here
```
Impact
- Any authenticated user can download the full media library of any station in the instance, regardless of their assigned permissions.
- In multi-tenant deployments (e.g., hosting providers running multiple radio stations), a user of Station A can exfiltrate all copyrighted audio content from Station B.
- Media IDs use auto-increment integers (
HasAutoIncrementIdtrait onStationMedia), enabling trivial enumeration of all media files. - The confidentiality impact is High: full media file contents (MP3, FLAC, etc.) are exposed.
Recommended Fix
Add the Permissions middleware to the /play route, matching the pattern used by the adjacent routes:
```php
// backend/config/routes/api_station.php, line 426-427
// Before:
$group->get('/play', Controller\Api\Stations\Files\PlayAction::class)
->setName('api:stations:files:play');
// After:
$group->get('/play', Controller\Api\Stations\Files\PlayAction::class)
->setName('api:stations:files:play')
->add(new Middleware\Permissions(StationPermissions::Media, true));
```
How this vulnerability can be exploited
This issue can be reached over the network, attack complexity is low, an attacker needs low-level privileges on the target. No user interaction is required. The scope is unchanged, so the impact stays within the vulnerable component. Rated impact: confidentiality high, integrity none, availability none.
Weakness class
GHSA-qff7-q5fm-8p76 is classified as CWE-862: Missing Authorization. No authorisation check is performed before carrying out a restricted action.
Affected software
GHSA-qff7-q5fm-8p76 is recorded against 1 package.
- azuracast/azuracast (fixed in 0.23.6)
Timeline and source
Published on 4 May 2026 and last revised on 5 May 2026. No public exploit is currently recorded for this entry. Record sourced from OSV.
References
Details
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Affected Packages
| Software | From version | Fixed in |
|---|---|---|
| azuracast/azuracast | — | 0.23.6 |
References
Similar Threats
- High CVE-2026-42605
- High CVE-2026-42606
- Unknown GHSA-4fm3-ggg2-c6qx
- High GHSA-q4ph-8x8g-95f8
- High GHSA-93fx-5qgc-wr38
Free Vulnerability Check
Is your site affected by GHSA-qff7-q5fm-8p76?
BotEraser helps you identify potentially vulnerable plugins and themes by checking your installation against GHSA-qff7-q5fm-8p76 and other known CVE records.
Scan My Site Free →No credit card required · Results in minutes
ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.