Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘 Packagist

GHSA-6547-8hrg-c55m

AVideo: IDOR - Any Admin Can Set Another User's Channel Password via setPassword.json.php

Also known asCVE-2026-33297
Published
Mar 19, 2026
Updated
Apr 7, 2026
Affected
1 pkg
Patched
None yet
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk26th percentile+0.29%
0.00%0.28%0.56%0.84%0.0%0.0%0.1%0.3%Apr 26Jun 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

1 pkg affected
🐘wwbn/avideo

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The setPassword.json.php endpoint in the CustomizeUser plugin allows administrators to set a channel password for any user. Due to a logic error in how the submitted password value is processed, any password containing non-numeric characters is silently coerced to the integer zero before being stored. This means that regardless of the intended password, the stored channel password becomes 0, which any visitor can trivially guess to bypass channel-level access control.

Details

The endpoint correctly restricts access to administrators only, but the password value submitted via the ProfilePassword request parameter is processed with intval() before being passed to User::setProfilePassword(). The relevant code is:

$obj->ProfilePassword = intval(@$_REQUEST['ProfilePassword']);
$obj->users_id = $users_id;
$obj->response = User::setProfilePassword($users_id, $obj->ProfilePassword);

The call to intval() on an alphanumeric string such as secretabc123 returns 0. This silently discards the intended password value and stores 0 as the channel password instead. Because the coercion is silent, the administrator receives no error or warning and has no indication that the password they set was not stored correctly. Any visitor to the channel who enters 0 as the password will be granted access, completely defeating the channel password protection feature.

This is not a case where a malicious admin deliberately sets a weak password. The vulnerability causes well-intentioned admins to unknowingly install a trivially guessable password on any channel for which they attempt to configure a non-numeric password.

PoC

curl -s -X POST "https://target.example.com/plugin/CustomizeUser/setPassword.json.php" \
  -b "PHPSESSID=<admin_session_cookie>" \
  -d "users_id=42&ProfilePassword=secretPassword123"
curl -s -X POST "https://target.example.com/channel_password_check_endpoint" \
  -d "users_id=42&password=0"
import requests

base_url = "https://target.example.com"
session = requests.Session()

session.post(f"{base_url}/login", data={"user": "admin", "pass": "adminpass"})

session.post(
    f"{base_url}/plugin/CustomizeUser/setPassword.json.php",
    data={"users_id": "42", "ProfilePassword": "mySuperSecretPassword"}
)

resp = session.post(
    f"{base_url}/plugin/CustomizeUser/setPassword.json.php",
    data={"users_id": "42", "ProfilePassword": "0"}
)

print(resp.text)

Impact

Any administrator who sets a channel password using a non-numeric string unknowingly reduces that password to 0. Any unauthenticated or unprivileged user who simply enters 0 as the channel password can access the content that was intended to be protected. This breaks the confidentiality guarantees of the channel password protection feature across all channels managed by administrators who use alphanumeric passwords. The impact is scoped to channel-level access control and does not enable account takeover or privilege escalation, but it renders the password protection feature entirely ineffective for the common case of non-numeric passwords.

Affected Packages

1 total
EcosystemPackageVulnerable rangeFix
🐘Packagistwwbn/avideoall versionsNo fix

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wwbn/avideo. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Remediation status

    No patched version of wwbn/avideo has shipped for GHSA-6547-8hrg-c55m yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Mitigate without a patch

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-6547-8hrg-c55m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-6547-8hrg-c55m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary The `setPassword.json.php` endpoint in the CustomizeUser plugin allows administrators to set a channel password for any user. Due to a logic error in how the submitted password value is processed, any password containing non-numeric characters is silently coerced to the integer zero before being stored. This means that regardless of the intended password, the stored channel password becomes 0, which any visitor can trivially guess to bypass channel-level access control. ### Details The endpoint correctly restricts access to administrators only, but the password value submitted v
O3 Security · Impact-Aware SCA

Is GHSA-6547-8hrg-c55m in your dependencies?

O3 detects GHSA-6547-8hrg-c55m across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.