CVE-2026-33867

AVideo allows content owners to password-protect individual videos. The video password is stored in the database in plaintext, no hashing, salting, or encryption is applied. If an attacker gains read access to the database (via SQL injection, a database backup, or misconfigured access controls), they obtain all video passwords in cleartext.

Details

File: objects/video.php

Vulnerable setter:

public function setVideo_password($video_password)
{
    AVideoPlugin::onVideoSetVideo_password($this->id, $this->video_password, $video_password);
    $this->video_password = trim($video_password);
}

Vulnerable getter:

public function getVideo_password()
{
    if (empty($this->video_password)) {
        return '';
    }
    return trim($this->video_password);
}

The value assigned to $this->video_password is only trim()-ed before being persisted to the database column video_password in the videos table. There is no call to any hashing function (e.g., password_hash(), sha256, or similar).

When a visitor enters a password to access a protected video, the comparison is done directly against the stored plaintext:

// Comparison at access check:
if ($video->getVideo_password() === $_POST['password']) { ... }

This means:

1. Any database read (SQL injection, backup leak, hosting panel access) exposes all video passwords as cleartext.
2. Video passwords are often reused by users across other services, making this a credential harvesting risk.
3. The plaintext value is also present in application memory and any query logs.

PoC

1. Set a password on any video via the AVideo admin/creator UI.
2. Query the database: SELECT clean_title, video_password FROM videos WHERE video_password != '';
3. All video passwords are returned in plaintext, no cracking required.

Alternatively, exploit any of the SQL injection vulnerabilities already reported in this repository to extract the video_password column directly.

• Type: Cleartext Storage of Sensitive Information (CWE-312)
• Severity: High
• Authentication required: No, any database read access (including via SQL injection by unauthenticated users) exposes all passwords
• Impact: Full exposure of all video access passwords; credential reuse attacks against users who share passwords across services
• Fix: Hash video passwords on write using password_hash($video_password, PASSWORD_BCRYPT) and verify on read using password_verify($_POST['password'], $stored_hash)

Kodem intelligence

1. What is CVE-2026-33867? CVE-2026-33867 is a critical-severity security vulnerability in wwbn/avideo (composer), affecting versions <= 26.0. No fixed version is listed yet.
2. Which versions of wwbn/avideo are affected by CVE-2026-33867? wwbn/avideo (composer) versions <= 26.0 is affected.
3. Is there a fix for CVE-2026-33867? No fixed version is listed for CVE-2026-33867 yet. Monitor the advisory for updates and apply mitigations in the interim.
4. Is CVE-2026-33867 exploitable, and should I be worried? Whether CVE-2026-33867 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-33867 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.