CVE-2026-33688: WWBN AVideo Information Disclosure Flaw

CVE-2026-33688 Overview

WWBN AVideo is an open source video platform. In versions up to and including 26.0, a user enumeration vulnerability exists in the password recovery endpoint at objects/userRecoverPass.php. The endpoint performs user existence and account status checks before validating the captcha, allowing an unauthenticated attacker to enumerate valid usernames and determine whether accounts are active, inactive, or banned — at scale and without solving any captcha — by observing three distinct JSON error responses.

Critical Impact

Attackers can enumerate valid usernames and account statuses without authentication, enabling targeted credential attacks, social engineering campaigns, and reconnaissance for further exploitation of the AVideo platform.

Affected Products

• WWBN AVideo versions up to and including 26.0
• AVideo installations with exposed password recovery functionality
• Self-hosted AVideo instances accessible via network

Discovery Timeline

• 2026-03-23 - CVE CVE-2026-33688 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-33688

Vulnerability Analysis

This vulnerability is classified as CWE-204 (Observable Response Discrepancy), a form of information disclosure that occurs when an application returns distinguishable responses that reveal sensitive information about user accounts. The flaw allows attackers to differentiate between valid and invalid usernames, as well as determine the status of valid accounts (active, inactive, or banned) through variations in the server's JSON error messages.

The vulnerability presents a significant reconnaissance risk because it bypasses the intended captcha protection mechanism. The captcha validation occurs after the user existence and status checks, creating a timing and logic flaw that attackers can exploit programmatically at scale.

Root Cause

The root cause lies in the improper sequencing of security controls within the objects/userRecoverPass.php endpoint. The application validates user existence and checks account status before enforcing the captcha requirement. This design flaw means the captcha protection — intended to prevent automated abuse — is ineffective against enumeration attacks because attackers receive informative error responses before the captcha is ever validated.

A secure implementation would validate the captcha first, before performing any database lookups or returning any information about user accounts. The fix in commit e42f54123b460fd1b2ee01f2ce3d4a386e88d157 addresses this by reordering the validation logic.

Attack Vector

The attack can be executed remotely over the network without any authentication. An attacker sends requests to the password recovery endpoint with various usernames and analyzes the JSON responses. The three distinct error messages allow attackers to build a database of valid usernames and their account statuses. This information can then be used for:

• Credential stuffing attacks using the enumerated valid usernames
• Targeted phishing campaigns against known active users
• Identification of high-value accounts (administrators, moderators)
• Understanding account lockout or ban patterns for timing attacks

The vulnerability mechanism works by sending POST requests to the objects/userRecoverPass.php endpoint with different username values. The server returns different JSON error messages depending on whether the username exists, and if it does, what the account status is. Since no captcha is required for these checks, an attacker can automate this process to test thousands of potential usernames rapidly. For technical details, see the GitHub Security Advisory GHSA-m99f-mmvg-3xmx.

Detection Methods for CVE-2026-33688

Indicators of Compromise

• High volume of requests to objects/userRecoverPass.php from single IP addresses or IP ranges
• Sequential or patterned username attempts in password recovery requests
• Requests to the password recovery endpoint without subsequent captcha submissions
• Unusual traffic patterns indicating automated enumeration scripts
• Failed password recovery attempts followed by targeted login attempts using enumerated usernames

Detection Strategies

• Implement rate limiting detection on the password recovery endpoint to flag excessive requests
• Configure web application firewall (WAF) rules to detect enumeration patterns
• Monitor HTTP response codes and response body patterns for the password recovery endpoint
• Deploy anomaly detection for authentication-related endpoints to identify automated scanning
• Correlate password recovery attempts with subsequent credential stuffing attacks

Monitoring Recommendations

• Enable detailed logging for all requests to objects/userRecoverPass.php including request parameters
• Set up alerts for request rates exceeding normal user behavior thresholds
• Monitor for requests originating from known malicious IP ranges or Tor exit nodes
• Track and alert on response time anomalies that may indicate enumeration scanning
• Implement user behavior analytics to detect reconnaissance activities

How to Mitigate CVE-2026-33688

Immediate Actions Required

• Apply the security patch by updating to a version containing commit e42f54123b460fd1b2ee01f2ce3d4a386e88d157
• Implement rate limiting on the password recovery endpoint as an interim measure
• Configure WAF rules to block automated enumeration attempts
• Review access logs for signs of prior exploitation
• Consider temporarily restricting access to the password recovery functionality if immediate patching is not possible

Patch Information

WWBN has released a patch in commit e42f54123b460fd1b2ee01f2ce3d4a386e88d157 that addresses this vulnerability by reordering the validation logic to enforce captcha verification before performing user existence checks. Administrators should update their AVideo installations to the latest version that includes this commit. The patch is available via the GitHub commit.

Workarounds

• Implement server-level rate limiting on the objects/userRecoverPass.php endpoint (e.g., 5 requests per minute per IP)
• Configure a reverse proxy or WAF to return identical error messages for all password recovery failures
• Restrict access to the password recovery endpoint by IP whitelist if feasible for your deployment
• Add additional CAPTCHA or challenge-response mechanisms at the web server level before requests reach the application
• Consider disabling the password recovery feature temporarily and using alternative account recovery methods

# Example nginx rate limiting configuration for password recovery endpoint
limit_req_zone $binary_remote_addr zone=passrecovery:10m rate=5r/m;

location /objects/userRecoverPass.php {
    limit_req zone=passrecovery burst=2 nodelay;
    limit_req_status 429;
    # Forward to PHP-FPM or application server
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php/php-fpm.sock;
}