CVE-2026-45610: WWBN AVideo 2FA CSRF Vulnerability – Cross-Site Account Takeover Risk

Technical summary

The vulnerability resides in plugin/LoginControl/set.json.php, which processes POST requests to toggle 2FA status. The endpoint accepts a 'type=set2FA' parameter with 'value=false' to disable 2FA for the authenticated session user. Critical CSRF protections are absent: there is no forbidIfIsUntrustedRequest() validation, no isTokenValid() check, no X-CSRF-Token header enforcement, no SameSite cookie attribute, and no re-authentication requirement. An attacker can craft a cross-origin request (via hidden form or fetch with credentials:"omit") that leverages the victim's active session cookie to invoke LoginControl::setUser2FA(User::getId(), false). The lack of any request-origin verification means the attacker's domain is treated identically to legitimate AVideo UI requests.

Business impact

Successful exploitation directly weakens account security by removing a critical authentication layer. Compromised accounts can be used for unauthorized video uploads, access to private content, credential harvesting from other users, or platform abuse. For organizations using AVideo as an internal or external content platform, widespread 2FA disablement could enable mass account takeovers following a credential breach. Reputational damage and potential compliance violations (depending on data classification) may ensue. The attack requires only that a user be logged into AVideo and visit an attacker-controlled page—a realistic scenario for users who keep dashboard tabs open or use the platform during normal work.

Affected systems

WWBN AVideo version 29.0 and all earlier versions are affected. This includes any deployment where the LoginControl plugin is active and 2FA functionality is available. No version-specific restrictions are documented; the vulnerability is pervasive across the affected release line. Patched versions are not specified in the available advisory data; users should verify the latest stable release and security advisories from the WWBN AVideo project for remediation guidance.

Exploitability

Exploitation is straightforward and requires minimal attacker capability. An attacker needs only to host a malicious web page and trick a user into visiting it while logged into AVideo. No special tools, code execution, or network access is required. The attack is entirely client-side and relies on browser automation of HTTP requests. The CVSS score of 5.7 (MEDIUM) reflects the requirement for user interaction (the victim must visit the attacker's page) and the limitation that only integrity is affected (2FA disabled, not confidentiality or availability). However, this interaction is easily facilitated through social engineering, advertisements, or compromised legitimate websites. No known public exploit code or active in-the-wild attacks have been documented, though the simplicity of CSRF attacks means defensive security posture should not rely on obscurity.

Remediation

Immediate action for administrators: upgrade WWBN AVideo to the latest available version that includes CSRF protections for the 2FA toggle endpoint. Verify that the patch includes implementation of one or more mitigations: CSRF token validation via isTokenValid(), X-CSRF-Token header enforcement, SameSite=Strict cookie attributes, forbidIfIsUntrustedRequest() checks, or re-authentication prompts for sensitive account changes. Until patching is possible, consider supplementary controls such as IP whitelisting for the admin/dashboard, enforcing HTTPS with strict transport security headers, or temporarily disabling the LoginControl plugin if not essential. Users should also audit their account security logs to confirm no unauthorized 2FA disablement has occurred.

Patch guidance

Check the official WWBN AVideo repository and release notes for versions published after 2026-06-17 (the vulnerability's last modification date). Verify that any candidate patch explicitly addresses CSRF protections in the LoginControl plugin. Consult the vendor's changelog or advisory to confirm the fix includes CSRF token validation and removal of the security gap described above. Deploy patches in a staged manner: test in a non-production environment first, then roll out during a maintenance window. After patching, force re-authentication for all active sessions to ensure that any silently disabled 2FA is re-enabled and users are prompted to confirm security settings. Monitor patch adoption across your deployed instances and maintain an inventory of AVideo versions in use.

Detection guidance

Monitor web application firewalls and proxy logs for POST requests to /plugin/LoginControl/set.json.php with 'type=set2FA&value=false' parameters, especially those originating from external domains or unusual user agents. Check AVideo audit logs for unexpected 2FA toggle events, particularly those occurring in rapid succession or outside normal business hours. Cross-reference 2FA disablement events with user login activity; a sudden login from a new location shortly after 2FA is disabled may indicate account compromise. Implement alerting on any 2FA state changes and notify the affected user immediately. Review HTTP Referer headers and Origin headers for requests to sensitive endpoints; legitimate UI requests should originate from your own domain. Enable verbose logging in the LoginControl plugin if available, and correlate 2FA changes with user consent via email or secondary confirmation records.

Why prioritize this

Although rated MEDIUM severity, this vulnerability warrants prompt remediation because it directly enables account compromise by removing a security control. The low barrier to exploitation (social engineering, malvertising) and the prevalence of 2FA as a compliance/best-practice requirement make this a practical threat. Organizations using AVideo for sensitive content distribution or as part of their identity/access infrastructure should prioritize patching. The absence of KEV listing and low public awareness should not create a false sense of security; CSRF vulnerabilities are consistently exploited in the wild.

Risk score, explained

The CVSS 3.1 score of 5.7 (MEDIUM) is justified by: (1) network attack vector—the attacker can strike from any domain; (2) low attack complexity—no special conditions or race conditions required; (3) low privilege requirement—only an authenticated session is needed, but note that 2FA itself is a security layer rather than a primary authentication factor, so the 'L' privilege rating is appropriate; (4) required user interaction—the victim must visit the attacker's page, which is the principal limiting factor; (5) unchanged scope—the attack affects only the targeted user's account; (6) high integrity impact—2FA protection is permanently disabled until re-enabled; (7) no confidentiality or availability impact. The score would be higher (into HIGH) if the vulnerability allowed unauthenticated users to disable 2FA or if it affected multiple users or systems simultaneously.

Frequently asked questions