CVE-2026-39370: WWBN AVideo has an Allowlisted downloadURL media extensions bypass SSRF protection and enable internal response exfiltration (Incomplete fix for CVE-2026-27732)
Summary
The fix for CVE-2026-27732 is incomplete.
objects/aVideoEncoder.json.php still 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.
Details
objects/aVideoEncoder.json.php accepts attacker-controlled downloadURL and passes it to downloadVideoFromDownloadURL().
Inside that function:
1. the URL extension is extracted from the attacker-controlled path 2. the extension is checked against an allowlist of normal encoder formats 3. isSSRFSafeURL() is skipped for common media and archive extensions 4. the URL is fetched via urlgetcontents() 5. the fetched body is written into video storage and exposed through normal media metadata
The current code still contains:
- an extension-based bypass for SSRF validation - no mandatory initial-destination SSRF enforcement inside urlgetcontents() itself
This means internal URLs such as:
http://127.0.0.1:9998/probe.mp4
remain reachable from the application host.
This issue is best described as an incomplete fix / patch bypass of CVE-2026-27732, not a separate unrelated SSRF class.
Proof of concept
1. Log in as a low-privilege uploader. 2. Start an HTTP service reachable only from inside the application environment, for example:
text http://127.0.0.1:9998/probe.mp4
3. Confirm that the service is not reachable externally. 4. Send:
text POST /objects/aVideoEncoder.json.php downloadURL=http://127.0.0.1:9998/probe.mp4 format=mp4
5. If needed, replay once against the returned videosid with firstrequest=1 so the fetched bytes land in the normal media path. 6. Query:
text GET /objects/videos.json.php?showAll=1
7. Recover videosURL.mp4.url. 8. Download that media URL and observe that the body matches the internal-only response byte-for-byte.
Impact
An authenticated uploader can make the AVideo server fetch loopback or internal HTTP resources and persist the response as media content by supplying a downloadURL ending in an allowlisted extension such as .mp4, .jpg, .gif, or .zip. Because SSRF validation is skipped for those extensions, the fetched body is stored and later retrievable through the generated /videos/... media URL. Successful exploitation allows internal response exfiltration from private APIs, admin endpoints, or other internal services reachable from the application host.
Recommended fix
- Apply isSSRFSafeURL() to all downloadURL inputs regardless of extension - Remove extension-based exceptions from SSRF enforcement - Move initial-destination SSRF validation into urlgetcontents() so call sites cannot skip it - Avoid storing arbitrary fetched content directly as publicly retrievable media - Consider restricting upload-by-URL to an explicit allowlist of trusted fetch origins
Other sources
WWBN AVideo is an open source video platform. In versions 26.0 and prior, objects/aVideoEncoder.json.php still 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. The vulnerability is caused by an incomplete fix for CVE-2026-27732.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update objects/aVideoEncoder.json.php so SSRF validation runs for every downloadURL value, not only for non-media/archived extensions; remove any extension-based exceptions (e.g., for .mp4, .mp3, .zip, .jpg, .png, .gif, .webm). Ensure upload-by-URL cannot persist loopback/internal HTTP responses as media by relying on extension-agnostic SSRF enforcement.
AVideo (objects/aVideoEncoder.json.php) - download-by-URL SSRF enforcement isSSRFSafeURL() usage for downloadURL = Apply isSSRFSafeURL() to all downloadURL inputs regardless of extension (remove extension-based bypass). - Configuration
Move/ensure initial-destination SSRF validation inside url_get_contents() itself so call sites cannot skip it (i.e., url_get_contents() must enforce the same SSRF checks before fetching).
AVideo url_get_contents() Initial-destination SSRF validation enforcement = Mandatory inside url_get_contents() - Configuration
If upload-by-URL is required, restrict allowed downloadURL origins to an explicit allowlist of trusted fetch sources to prevent attackers from fetching loopback/internal services (e.g., the internal-only HTTP service reachable from the app host).
AVideo (upload-by-URL) - fetch origin restriction Allowlist of trusted fetch origins for upload-by-URL = Restrict to an explicit allowlist of trusted fetch origins - Compensating control
Confirm the AVideo service is not reachable externally; restrict network exposure so the attacker cannot interact with the upload-by-URL endpoint from outside the application environment.