AVideo vulnerable to unauthenticated SSRF via HTTP redirect bypass in LiveLinks proxy
Date: 2026-03
Affected: composer/wwbn/avideo
Attack vector: ssrf
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2026-33039
CWE: CWE-918
CVSS: 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N)

## Summary The `plugin/LiveLinks/proxy.php` endpoint validates user-supplied URLs against internal/private networks using `isSSRFSafeURL()`, but only checks the initial URL. When the initial URL responds with an HTTP redirect (`Location` header), the redirect target is fetched via `fakeBrowser()` without re-validation, allowing an attacker to reach internal services (cloud metadata, RFC1918 addresses) through an attacker-controlled redirect. ## Affected Component - `plugin/LiveLinks/proxy.php` — lines 38-42 (redirect handling without SSRF re-validation) - `objects/functionsBrowser.php` — `fakeBrowser()` (line 123, raw cURL fetch with no SSRF protections) ## Description ### Missing SSRF re-validation after HTTP redirect The `proxy.php` endpoint validates the user-supplied `livelink` parameter against internal networks on line 18, using the comprehensive `isSSRFSafeURL()` function (which blocks private IPs, loopback, link-local/metadata, cloud metadata hostnames, and resolves DNS to detect rebinding). However, after calling `get_headers()` on line 38 — which follows HTTP redirects — the code extracts the `Location` header and passes it directly to `fakeBrowser()` without re-applying the SSRF check: ```php // plugin/LiveLinks/proxy.php — lines 17-42 // SSRF Protection: Block requests to internal/private networks if (!isSSRFSafeURL($_GET['livelink'])) { // line 18: only checks initial URL _error_log("LiveLinks proxy: SSRF protection blocked URL: " . $


Mitigations:

Architectural layers (MAESTRO):