CVE-2026-41064: WWBN AVideo RCE Vulnerability

CVE-2026-41064 Overview

WWBN AVideo is an open source video platform that contains a command injection vulnerability due to an incomplete security fix. In versions up to and including 29.0, the test.php file was previously patched to add escapeshellarg protection for wget commands, but this fix left the file_get_contents and curl code paths unsanitized. Additionally, the URL validation regex /^http/ is insufficient as it accepts malicious strings like httpevil[.]com, allowing attackers to bypass intended URL restrictions.

Critical Impact

Remote attackers can exploit unsanitized URL handling in AVideo's test.php to execute arbitrary commands or access sensitive server-side resources without authentication.

Affected Products

• WWBN AVideo versions up to and including 29.0
• AVideo instances using vulnerable test.php file
• Deployments without commit 78bccae74634ead68aa6528d631c9ec4fd7aa536 applied

Discovery Timeline

• 2026-04-22 - CVE CVE-2026-41064 published to NVD
• 2026-04-22 - Last updated in NVD database

Technical Details for CVE-2026-41064

Vulnerability Analysis

This vulnerability (CWE-78: Improper Neutralization of Special Elements used in an OS Command) stems from an incomplete remediation of a previous security issue in AVideo's test.php file. While the original fix addressed command injection via the wget utility by implementing escapeshellarg sanitization, the developers failed to apply equivalent protections to parallel code paths that utilize file_get_contents and curl functions.

The root cause is compounded by a weak URL validation regex that only checks if a URL starts with "http" using the pattern /^http/. This regex is fundamentally flawed because it matches any string beginning with "http" regardless of what follows, including malicious domains like httpevil.com or URLs with embedded shell metacharacters.

Successful exploitation allows network-based attackers to manipulate URL parameters without requiring authentication, potentially leading to server-side request forgery (SSRF) or command injection depending on the code path triggered. The vulnerability affects the confidentiality and integrity of affected systems.

Root Cause

The vulnerability exists because of inconsistent security controls applied during a prior security fix. While escapeshellarg was added to sanitize input for wget commands, the file_get_contents and curl code paths remained vulnerable to injection attacks. The weak URL validation regex /^http/ provides no meaningful security benefit as it only performs a prefix check without validating the full URL structure, allowing attackers to craft malicious URLs that pass validation.

Attack Vector

The attack is network-accessible and requires no authentication or user interaction. An attacker can send specially crafted HTTP requests to the test.php endpoint with malicious URL parameters. By constructing URLs that bypass the weak regex validation (e.g., httpevil.com/malicious_payload), attackers can exploit the unsanitized file_get_contents or curl code paths. This can result in unauthorized access to internal resources, exfiltration of sensitive data, or execution of arbitrary commands on the underlying server.

The vulnerability mechanism involves bypassing URL validation through the weak regex pattern and then exploiting the unsanitized input handling. For technical details on the vulnerable code paths and exploitation techniques, see the GitHub Security Advisory GHSA-3fpm-8rjr-v5mc and the related advisory GHSA-pq8p-wc4f-vg7j.

Detection Methods for CVE-2026-41064

Indicators of Compromise

• Unusual HTTP requests to test.php containing malformed or suspicious URL parameters
• Server logs showing requests with URL patterns designed to bypass /^http/ validation (e.g., URLs like httpevil.com)
• Unexpected outbound connections from the web server to external hosts
• Evidence of file_get_contents or curl accessing internal or unexpected resources

Detection Strategies

• Monitor web application logs for requests to test.php with unusual URL parameters or payloads
• Implement web application firewall (WAF) rules to detect command injection attempts and SSRF patterns
• Deploy network monitoring to identify unexpected outbound connections from AVideo server instances
• Use intrusion detection systems configured with signatures for command injection and SSRF attacks

Monitoring Recommendations

• Enable verbose logging for the AVideo application to capture all requests to vulnerable endpoints
• Set up alerts for any access to test.php from external IP addresses
• Monitor for signs of data exfiltration or unusual curl/wget activity from the server
• Implement behavioral analysis to detect anomalous URL patterns in application requests

How to Mitigate CVE-2026-41064

Immediate Actions Required

• Apply the security fix contained in commit 78bccae74634ead68aa6528d631c9ec4fd7aa536 immediately
• Restrict access to test.php via web server configuration or firewall rules until patched
• Review web server logs for evidence of exploitation attempts
• Consider temporarily disabling or removing the test.php file if not required for production operations

Patch Information

The vulnerability has been addressed in commit 78bccae74634ead68aa6528d631c9ec4fd7aa536. This commit provides an updated fix that properly sanitizes all code paths including file_get_contents and curl handlers. Users should update their AVideo installation to a version containing this commit or manually apply the patch. The initial incomplete fix was implemented in commit 1e6cf03e93b5a5318204b010ea28440b0d9a5ab3, but this should not be relied upon as it does not address all vulnerable code paths.

Workarounds

• Block external access to test.php via web server configuration (e.g., Apache .htaccess or Nginx location blocks)
• Implement a reverse proxy with strict URL validation to filter requests before they reach AVideo
• Deploy a web application firewall with rules to block requests containing suspicious URL patterns
• If test.php functionality is not required, remove or rename the file to eliminate the attack surface

# Configuration example - Block access to test.php in Apache
# Add to .htaccess or Apache configuration
<Files "test.php">
    Require all denied
</Files>

# Alternative: Nginx configuration to block test.php
location = /test.php {
    deny all;
    return 403;
}