WWBN AVideo CVE-2026-86720

Exploitation requires an attacker to hold an authenticated account on the target AVideo instance with the canStream permission granted. The canStream role is the specific authorization gate - users without it cannot reach the vulnerable code path. The attack is purely network-based against the PHP web endpoint and requires no special platform configuration beyond the default restreaming feature being in use by other users. What limits exploitation: access to a canStream account (legitimate or compromised), and the victim must have at least one active live_restreams_id record configured. Exploitation does not require admin privileges, prior knowledge of specific IDs (sequential enumeration suffices), or any victim interaction.

The CVSS 4.0 base score of 8.6 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) is well-calibrated for this finding: the attack requires authenticated access with the canStream role, which limits blast radius in strict user-provisioning environments but may be broadly granted on community or multi-tenant AVideo instances. The VC:H and VI:H ratings are defensible because exposure of a victim's platform stream key gives an attacker full read and write-equivalent control over their streaming presence. EPSS data was not included in the source intelligence; however, no public exploit code or CISA KEV entry exists at time of analysis, suggesting opportunistic mass exploitation has not yet materialized. Real-world risk is highest in multi-tenant deployments where canStream is granted to untrusted or competing users - even a mid-sized municipal media or education operator in opole should treat this as urgent if running a shared AVideo instance. The absence of an availability impact metric is accurate: the vulnerability does not crash or disable the platform, but the reputational and business-continuity consequences of stream hijacking on live broadcasts are disproportionate to the A:N rating alone.

An attacker registers or gains canStream permission on a shared AVideo instance, then iterates live_restreams_id integer values in POST requests to resendRestreamer.json.php until a valid ID belonging to another user is encountered. The server, without validating ownership, begins broadcasting the attacker's live stream to the victim's configured YouTube or Twitch destination using the victim's private stream key, immediately displacing the victim's broadcast. No public exploit code is confirmed, but the attack requires only standard HTTP tooling and knowledge of the endpoint.