AVideo EUVD-2026-81436

Two concrete prerequisites: (1) the attacker must already possess the victim's account password (reflected as PR:L), and (2) the target account must have PGP second-factor verification enabled - the vulnerable verifyChallenge.json.php path is the 2FA step being bypassed. Exploitation is a single unauthenticated-to-the-endpoint, parameter-less GET request over the network with no user interaction and no special client tooling. The main limiting factor is the password requirement: this is a 2FA-bypass primitive, not a standalone remote takeover, so it matters most where credential theft/reuse is feasible and where PGP 2FA is the sole remaining protection.

This is a genuine, high-priority authentication flaw despite the absence of exploitation telemetry. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H) scores 8.6 and aligns well with the description: a network-reachable, low-complexity 2FA bypass. The PR:L reflects the single real prerequisite - the attacker must already possess the victim's password; the vulnerability itself defeats the PGP second factor that is supposed to stand in the way of a stolen-password attacker. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so this is 'no public exploit identified at time of analysis' - the risk is derived from the mechanics, not observed attacks. The bug is trivially reliable (a parameter-less GET makes null == null evaluate true against an uninitialized session variable), so if credentials are already available the bypass is deterministic and requires no cryptographic effort. Net: a real credential-to-full-account escalation primitive that neuters the entire benefit of enabling PGP 2FA, tempered only by the password precondition and by AVideo's niche deployment footprint.

An attacker who has obtained a victim's AVideo password (via phishing, reuse, or a prior breach) but is blocked by PGP second-factor verification sends a single parameter-less GET request to verifyChallenge.json.php. The loose equality check compares two uninitialized/null values, evaluates null == null as true, and marks authentication complete, granting full account access. No public exploit code is identified, but the technique is trivially reproducible from the advisory description.