CVE-2026-39370: 
PHP vulnerability analysis and mitigation

CVE-2026-39370 is a Server-Side Request Forgery (SSRF) vulnerability in WWBN AVideo, an open source video platform, affecting versions 26.0 and prior. The flaw exists in objects/aVideoEncoder.json.php and represents an incomplete fix for a prior SSRF vulnerability, CVE-2026-27732. It was published on April 7, 2026, with the GitHub advisory (GHSA-cmcr-q4jf-p6q9) released on April 8, 2026. The vulnerability carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory, WWBN Advisory).

The root cause is CWE-918 (Server-Side Request Forgery), stemming from an extension-based bypass in the SSRF validation logic within objects/aVideoEncoder.json.php. The function downloadVideoFromDownloadURL() extracts the file extension from the attacker-controlled downloadURL parameter and checks it against an allowlist of common media/archive formats (.mp4, .mp3, .zip, .jpg, .png, .gif, .webm); when a match is found, the isSSRFSafeURL() check is skipped entirely. The URL is then fetched via url_get_contents() and the response body is written to video storage and exposed through normal media metadata endpoints, enabling full response exfiltration. An authenticated uploader with low privileges is the only precondition for exploitation (WWBN Advisory, GitHub Advisory).

Successful exploitation allows an authenticated uploader to make the AVideo server fetch loopback or internal HTTP resources (e.g., http://127.0.0.1:9998/probe.mp4) and persist the response as publicly retrievable media content. This enables exfiltration of responses from private APIs, admin endpoints, and internal services not directly accessible from the attacker's network. The primary impact is high confidentiality loss, with a low integrity impact due to unauthorized content being stored in the media library; availability is not affected (WWBN Advisory).

No public proof-of-concept exploit code has been released, and there is no evidence of in-the-wild exploitation at this time. The vulnerability requires authentication as a low-privilege uploader, which slightly limits the attack surface. The EPSS score is approximately 0.036% (0.000280), placing it in the 11th percentile for exploitation likelihood. The CVE is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

1. Authenticate: Log in to the AVideo instance as a low-privilege user with uploader permissions.
2. Set up an internal target: Identify or deploy an HTTP service reachable only from within the application's network environment (e.g., http://127.0.0.1:9998/probe.mp4), confirming it is not externally accessible.
3. Submit malicious upload request: Send a POST request to /objects/aVideoEncoder.json.php with the downloadURL parameter set to the internal URL using an allowlisted extension: POST /objects/aVideoEncoder.json.php with body downloadURL=http://127.0.0.1:9998/probe.mp4&format=mp4. The extension .mp4 causes isSSRFSafeURL() to be skipped, and the server fetches the internal resource.
4. Trigger media storage: If needed, replay the request against the returned videos_id with first_request=1 to ensure the fetched bytes are written to the normal media storage path.
5. Retrieve exfiltrated data: Query GET /objects/videos.json.php?showAll=1, locate the videosURL.mp4.url field in the response, and download the media file — its contents will match the internal-only HTTP response byte-for-byte (WWBN Advisory, GitHub Advisory).

• Network: Outbound HTTP requests from the AVideo application server to loopback (127.0.0.1) or RFC-1918 internal IP addresses; unusual connections to internal ports not normally accessed by the web application process.
• Logs: Web server access logs showing POST requests to /objects/aVideoEncoder.json.php with downloadURL values pointing to internal or loopback addresses with media/archive extensions (.mp4, .jpg, .gif, .zip, etc.); subsequent GET requests to /objects/videos.json.php?showAll=1 from the same session.
• File System: Unexpected files appearing in the AVideo video storage directory (/videos/) with content that does not match legitimate user-uploaded media; files whose byte content matches internal service responses rather than actual video or image data.
• Application Behavior: New video entries in the media library created by uploader-role accounts with source URLs referencing internal network addresses (WWBN Advisory).

As of the advisory publication date, no patched version of WWBN AVideo is available (all versions ≤ 26.0 are affected). The recommended fix from the advisory is to apply isSSRFSafeURL() to all downloadURL inputs regardless of file extension, remove extension-based exceptions from SSRF enforcement, and move initial-destination SSRF validation into url_get_contents() itself. As interim mitigations: restrict the upload-by-URL feature to trusted users only, implement network segmentation to prevent the application server from reaching internal resources, and validate downloadURL inputs against a strict allowlist of trusted external domains. Monitor for suspicious upload activity targeting internal IP ranges (WWBN Advisory, GitHub Advisory).