CVE-2026-33767: Wwbn Avideo SQL Injection Vulnerability

CVE-2026-33767 Overview

WWBN AVideo is an open source video platform that enables users to create and share video content. A SQL injection vulnerability has been identified in versions up to and including 26.0. The vulnerability exists in objects/like.php, where the getLike() method constructs a SQL query using a prepared statement placeholder (?) for users_id but directly concatenates $this->videos_id into the query string without parameterization. An attacker who can control the videos_id value via a crafted request can inject arbitrary SQL, bypassing the partial prepared-statement protection.

Critical Impact

Authenticated attackers can exploit this SQL injection vulnerability to extract sensitive data from the database, including user credentials, video metadata, and potentially administrative information. The vulnerability allows high confidentiality impact with potential for data manipulation.

Affected Products

• WWBN AVideo versions up to and including 26.0
• Self-hosted AVideo platform installations

Discovery Timeline

• 2026-03-27 - CVE CVE-2026-33767 published to NVD
• 2026-03-31 - Last updated in NVD database

Technical Details for CVE-2026-33767

Vulnerability Analysis

This SQL injection vulnerability stems from inconsistent parameterization in the getLike() method within objects/like.php. While the developers implemented prepared statement protection for the users_id parameter, they failed to apply the same protection to the videos_id parameter. This partial implementation creates a false sense of security while leaving a critical attack vector exposed.

The vulnerability is network-exploitable with low attack complexity, requiring only low-level privileges (authenticated user). The attack requires no user interaction, making it suitable for automated exploitation. Successful exploitation can result in unauthorized access to confidential database contents and limited integrity impact through potential data modification.

Root Cause

The root cause is an incomplete implementation of prepared statements in the database query construction. The videos_id value is directly concatenated into the SQL query string rather than being passed as a parameterized value. This violates secure coding practices for SQL query construction, where all user-controllable input should be parameterized regardless of expected data type.

Attack Vector

An authenticated attacker can craft malicious requests that manipulate the videos_id parameter to inject arbitrary SQL commands. Since the application expects an integer but does not enforce type validation before query construction, the attacker can inject SQL syntax that will be executed in the context of the database query. This enables data exfiltration, potential privilege escalation within the application, and database enumeration.

The following patch demonstrates the fix applied in commit 0215d3c4f1ee748b8880254967b51784b8ac4080:

Fix in objects/functions.php - Ensuring integer return type:

     if (preg_match('/^\\.([0-9a-z._-]+)/i', $hash_of_videos_id, $matches)) {
         $hash_of_videos_id = hashToID($matches[1]);
     }
-    return $hash_of_videos_id;
+    // Always return an integer — prevents SQL injection on any caller that
+    // embeds this value directly without a prepared statement placeholder.
+    return intval($hash_of_videos_id);
 }
 
 /**

Source: GitHub AVideo Commit Changes

Fix in objects/like.php - Sanitizing videos_id input:

             header('Content-Type: application/json');
             die('{"error":"'.__ ("Permission denied").'"}');
         }
-        $this->videos_id = $videos_id;
+        $this->videos_id = intval($videos_id);
         $this->users_id = User::getId();
         $this->load();
         // if click again in the same vote, remove the vote

Source: GitHub AVideo Commit Changes

Detection Methods for CVE-2026-33767

Indicators of Compromise

• Unusual SQL error messages in application logs referencing the like.php endpoint
• Anomalous requests to like/unlike video endpoints containing non-numeric videos_id values
• Database query logs showing unexpected SQL syntax in video-related queries
• Evidence of time-based or error-based SQL injection attempts in web server access logs

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect SQL injection patterns in videos_id parameters
• Configure intrusion detection systems to alert on SQL injection signature patterns targeting PHP applications
• Enable database query logging and monitor for anomalous query structures or unauthorized data access patterns
• Deploy application-level monitoring to track parameter manipulation attempts on video-related endpoints

Monitoring Recommendations

• Monitor HTTP request parameters for SQL injection payloads including single quotes, UNION statements, and comment sequences
• Review application logs for increased error rates on the objects/like.php endpoint
• Track database query execution times for potential time-based blind SQL injection attempts
• Implement real-time alerting for suspicious authentication patterns following video interaction requests

How to Mitigate CVE-2026-33767

Immediate Actions Required

• Upgrade WWBN AVideo to a version containing commit 0215d3c4f1ee748b8880254967b51784b8ac4080 or later
• Review and audit all database queries in the application for similar concatenation-based vulnerabilities
• Implement additional input validation at the application perimeter
• Consider temporarily restricting access to authenticated features if immediate patching is not possible

Patch Information

The vulnerability has been addressed in commit 0215d3c4f1ee748b8880254967b51784b8ac4080. The fix implements proper integer casting using intval() on the videos_id parameter before it is used in database queries. This ensures that only integer values can be passed to the SQL query, effectively preventing SQL injection through this parameter. For detailed patch information, refer to the GitHub Security Advisory GHSA-fj74-qxj7-r3vc.

Workarounds

• Deploy a Web Application Firewall with SQL injection protection rules targeting the affected endpoints
• Implement network-level access controls to limit exposure of the AVideo platform to trusted users only
• Add application-level input validation to reject non-numeric videos_id values before processing
• Consider implementing database account privilege restrictions to limit potential damage from SQL injection

# Example WAF rule for ModSecurity to block SQL injection attempts on videos_id
SecRule ARGS:videos_id "!^[0-9]+$" \
    "id:100001,\
    phase:2,\
    deny,\
    status:403,\
    msg:'Potential SQL Injection in videos_id parameter',\
    logdata:'Matched Data: %{MATCHED_VAR}'"