CVE-2026-86723 is a high severity authentication bypass in the AVideo LoginControl plugin through commit c3edcc27. Its PGP second factor check uses loose comparison against an unset session value, so a caller who knows only the password can finish the second step. The advisory listed no patched version.
What's affected
Affected: WWBN AVideo up to and including commit c3edcc274c389816d434acadac07ee78eaf330c1 (master, 2026-08-21 per the advisory). The code is LoginControl::verifyChallenge() in the LoginControl plugin. The GitHub advisory lists patched versions as "None".
Severity differs: the record gives CVSS 3.1 at 8.1 (High) and VulnCheck gives 8.6 on CVSS 4.0, also High. The attacker needs the account password, so this defeats the second factor rather than the first. Nothing I read reports exploitation, and the CVE is not in CISA KEV.
How to check if you're exposed
AVideo is usually installed from the project's Git repository, so the commit you run is the version. From the install directory:
git log -1 --format="%H %cd" --date=short
Compare the date and hash with the affected commit, c3edcc274c389816d434acadac07ee78eaf330c1 (master, 2026-08-23 per the GitHub advisory). Anything at or before that commit is in range. If you run a tagged release, note that the advisory names a master commit, so read the project's security advisories page for the first release or commit that fixes the issue.
Then check whether the plugin named in the advisory is present and enabled in your install (the plugin directory lists them), since an unused plugin is not exposed in the same way, although the files may still be on disk and reachable by URL.
What to do now
- Check your AVideo commit or release against the affected range above.
- Read the AVideo security advisories page for the first fixed commit or release, and update to it as soon as one is listed. At the time of writing the GitHub advisory showed patched versions as "None".
- Where you can, put administrator logins behind a network restriction or a second authentication layer in front of the application, such as a VPN or an identity aware proxy.
- Review web server and application logs for unusual requests to the endpoint named in this post.
- Treat the instance as sensitive: keep admin sessions short and avoid browsing other sites while logged in as an administrator.
Why it matters
The record classes this as improper authentication (CWE-287). In PHP, the loose comparison operator treats some different values as equal. When the session never held a challenge and the request supplies no response, both sides of the comparison are empty, the check passes, and the code marks the second factor complete. The advisory adds that the path to that endpoint skips the code that would normally create the challenge.
This is a textbook reason to use strict comparison for security decisions, and to fail closed when an expected value is missing. A second factor that can be skipped by sending nothing offers little protection against password reuse and phishing, which are the cases it exists for.
Because passwords are the most common thing attackers have, the exposure is real for any account that relies on this plugin to protect elevated access.
Quick check
Does this bypass the password too?
No. The record says the attacker needs the password and then skips the PGP second factor.
What should I tell users?
If you rely on the PGP second factor, assume it is not protecting the account until a fix is available, and rotate reused passwords.
Sources
Last reviewed: 18 October 2026.
