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

bash

# 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;
}