WWBN AVideo CVE-2026-41060

Requires an authenticated session with upload permission (User::canUpload()) OR a valid per-video video_id_hash token accepted by useVideoHashOrLogin(); this is the primary limiting factor. The attacker must know or reuse the instance's public hostname as configured in webSiteRootURL and target it with a non-default port (e.g. https://<site-host>:9998/), because only same-hostname URLs hit the vulnerable shortcircuit. Exploitation is meaningful only when a service actually listens on another port of the AVideo host that the server can reach. Retrieval of exfiltrated data additionally requires that the cache/tmpFile/ directory under the videos storage path remains web-accessible. Affects AVideo 29.0 and below; no user interaction beyond the attacker's own requests is needed.

Signals are mostly consistent and point to a real but moderate, non-urgent priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N = 7.7) reflects network reach, low complexity, low-privilege authentication, a scope change (reaching a separate internal service context), and high confidentiality impact with no integrity or availability effect - matching the description of read-only exfiltration. SSVC agrees: Exploitation is only 'poc' (not active), Automatable 'no' (authentication and per-target hostname configuration prevent mass scripting), and Technical Impact 'partial'. EPSS is very low (0.03%, 8th percentile) and the CVE is NOT in CISA KEV, so there is no evidence of in-the-wild use. The key limiting factor is PR:L: exploitation requires an account with upload permission (User::canUpload()) or a valid per-video video_id_hash, so exposure depends heavily on whether an instance allows self-registration or public uploads. Net: prioritize patching on internet-facing multi-user instances, but this is not a drop-everything emergency. No conflicting signals of note; the main real-world variable is whether internal services actually listen on the AVideo host's other ports.

An attacker registers or uses a low-privileged AVideo account with upload rights (or obtains a valid video_id_hash), then submits downloadURL=https://avideo.example.com:9998/ to objects/aVideoEncoder.json.php; because the hostname matches webSiteRootURL, isSSRFSafeURL() returns true and the server fetches the internal service on port 9998. The response is stored under cache/tmpFile/ and the attacker downloads it from the web-accessible path to exfiltrate internal data. A working proof-of-concept (authenticate, then send the alternate-port request) is published in the GHSA advisory, and low attack complexity makes it straightforward to reproduce.