GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Check your stack
GHSA-363v-5rh8-23wgcritical9.1

AVideo has Plaintext Video Password Storage

Impact

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.

Source excerpt · OSV

Affected packages

Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.

wwbn/avideo Packagist
Affected rangeRecorded fix
Earlier releases through 26.0 (inclusive)Ecosystem versionsNot recorded

Version evidence: OSV · GHSA-363v-5rh8-23wg

View original version evidence (17 explicit versions)

Original source description

Summary

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.

Impact

  • 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)

References