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 url_get_contents()
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 url_get_contents() 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:

http://127.0.0.1:9998/probe.mp4

3. Confirm that the service is not reachable externally.
4. Send:

POST /objects/aVideoEncoder.json.php
downloadURL=http://127.0.0.1:9998/probe.mp4
format=mp4

5. If needed, replay once against the returned videos_id with first_request=1 so the fetched bytes land in the normal media path.