CVE-2026-39370 Overview
A Server-Side Request Forgery (SSRF) vulnerability exists in WWBN AVideo, an open source video platform. In versions 26.0 and prior, the objects/aVideoEncoder.json.php endpoint allows attacker-controlled downloadURL values with common media or archive extensions such as .mp4, .mp3, .zip, .jpg, .png, .gif, and .webm to bypass SSRF validation. The server then fetches the response and stores it as media content. This allows an authenticated uploader to turn the upload-by-URL flow into a reliable SSRF response-exfiltration primitive. This vulnerability represents an incomplete fix for CVE-2026-27732.
Critical Impact
Authenticated attackers can leverage the upload-by-URL functionality to perform SSRF attacks, potentially accessing internal network resources and exfiltrating sensitive data through the response storage mechanism.
Affected Products
- WWBN AVideo version 26.0 and prior
Discovery Timeline
- 2026-04-07 - CVE-2026-39370 published to NVD
- 2026-04-08 - Last updated in NVD database
Technical Details for CVE-2026-39370
Vulnerability Analysis
This SSRF vulnerability resides in the objects/aVideoEncoder.json.php endpoint of WWBN AVideo. The vulnerability is classified under CWE-918 (Server-Side Request Forgery), which occurs when a web application fetches a remote resource without sufficiently validating the user-supplied URL.
The root issue stems from an incomplete patch for CVE-2026-27732. While the previous fix attempted to restrict malicious URL requests, attackers discovered they could bypass validation by appending common media file extensions to their malicious URLs. The server fails to properly validate the actual content or destination of URLs that end with trusted extensions like .mp4, .mp3, .zip, .jpg, .png, .gif, and .webm.
Root Cause
The vulnerability exists because the SSRF validation logic relies on file extension checking rather than proper URL and destination validation. When a URL ends with an allowed media extension, the validation is bypassed, allowing the server to make arbitrary requests to attacker-specified endpoints. The server then stores the response as if it were legitimate media content, creating a response-exfiltration channel that can be used to capture and retrieve sensitive internal data.
Attack Vector
The attack requires an authenticated user with upload privileges. An attacker can craft a malicious downloadURL parameter pointing to internal services or cloud metadata endpoints while using an allowed file extension. For example, a request to an internal service could be disguised with a .mp4 extension.
The attack flow proceeds as follows:
- An authenticated attacker with upload privileges accesses the upload-by-URL functionality
- The attacker submits a crafted downloadURL value pointing to an internal resource, appended with an allowed extension (e.g., http://internal-service/sensitive-data.mp4)
- The SSRF validation is bypassed because the URL ends with an allowed media extension
- The AVideo server makes the request to the internal resource
- The response is stored as media content, which the attacker can then retrieve
This creates a reliable primitive for probing internal network infrastructure, accessing cloud metadata services, or exfiltrating data from otherwise unreachable internal services.
Detection Methods for CVE-2026-39370
Indicators of Compromise
- Unusual outbound requests from the AVideo server to internal IP ranges or cloud metadata endpoints (e.g., 169.254.169.254)
- Upload-by-URL requests containing internal hostnames or IP addresses with media file extensions
- Stored media files that contain non-media data (text, JSON, or configuration data)
Detection Strategies
- Monitor network traffic from the AVideo server for requests to internal IP ranges (10.x.x.x, 172.16.x.x-172.31.x.x, 192.168.x.x) or cloud metadata endpoints
- Implement logging for all requests to objects/aVideoEncoder.json.php and analyze downloadURL parameter values
- Configure web application firewall (WAF) rules to detect SSRF patterns in URL parameters
Monitoring Recommendations
- Enable detailed access logging for the AVideo application to capture all upload-by-URL requests
- Set up alerts for outbound connections from the AVideo server to internal network segments
- Monitor for any newly created media files that have unusual content types or sizes inconsistent with their extensions
How to Mitigate CVE-2026-39370
Immediate Actions Required
- Restrict access to the upload-by-URL functionality to only highly trusted users until a patch is available
- Implement network-level controls to prevent the AVideo server from accessing internal resources
- Review access logs for evidence of exploitation attempts targeting the objects/aVideoEncoder.json.php endpoint
Patch Information
At the time of publication, the vulnerability affects WWBN AVideo version 26.0 and prior. Organizations should monitor the GitHub Security Advisory for patch availability and update instructions.
Workarounds
- Disable the upload-by-URL feature entirely if it is not required for business operations
- Implement a whitelist of allowed external domains for URL-based uploads
- Deploy egress filtering to prevent the AVideo server from making requests to internal network ranges and cloud metadata services
# Example iptables rules to block internal network access from AVideo server
# Block requests to private IP ranges
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
# Block cloud metadata endpoint
iptables -A OUTPUT -d 169.254.169.254 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
