GHSA-5X2W-37XF-7962: Unauthenticated PGP Decryption and Resource Exhaustion in AVideo

The AVideo open-source video streaming platform contains a critical access control flaw within its cryptographic utility endpoints. The specific vulnerability resides in the LoginControl plugin, which exposes a server-side PGP decryption routine to unauthenticated external actors. This flaw is formally classified under CWE-306 (Missing Authentication for Critical Function) and CWE-287 (Improper Authentication).

The application exposes the PHP script at the URI path plugin/LoginControl/pgp/decryptMessage.json.php. This endpoint is designed to accept user-controlled JSON payloads and process them through the underlying cryptographic libraries. Because the script does not validate the existence of a valid user session prior to execution, any network request reaching the web server will trigger the internal PHP logic.

The immediate impacts of this missing authorization check are twofold. First, it permits resource exhaustion, as an attacker can force the server to execute computationally expensive decryption algorithms repeatedly. Second, it creates an information disclosure vector, as the private keys and passphrases transmitted in the request payload may be captured by reverse proxies, web application firewalls, or standard error logging mechanisms.

The root cause of this vulnerability is the complete omission of session validation and authorization guardrails within the target PHP script. In a properly secured application architecture, API endpoints that perform sensitive or resource-intensive operations must mandate user authentication. The AVideo platform typically utilizes a specific method, such as User::isLogged(), to enforce these access controls.

The vulnerable script accepts an HTTP POST request with a JSON body containing three specific keys: privateKeyToDecryptMsg, textToDecrypt, and keyPassword. The application parses this JSON stream and assigns the values directly to an internal object. The script then calls the decryptMessage() function, passing these untrusted values directly as arguments.

Because the PHP execution model processes scripts linearly, the absence of an early termination condition allows execution to proceed directly to the cryptographic subroutine. There is no middleware intercepting the request, nor is there any authorization check validating whether the requesting client possesses the permissions required to utilize the cryptographic utility.

This structural oversight transforms the server into an unauthenticated decryption oracle. The application logic trusts the inbound payload unconditionally, failing to verify the origin or intent of the request before allocating CPU time and memory to handle the PGP block processing.

The fundamental flaw exists within the execution flow of decryptMessage.json.php. The script expects a JSON payload and processes it without enforcing authentication constraints. The relevant vulnerable sequence demonstrates the direct ingestion of POST data into the decryption logic.

// Vulnerable Code Path (Conceptual representation based on analysis)
header('Content-Type: application/json');
$obj = new stdClass();
 
// Input is retrieved from php://input
$postData = file_get_contents("php://input");
$requestObj = json_decode($postData);
 
// Direct execution of cryptographic function without authentication
$textDecrypted = decryptMessage(
    $requestObj->textToDecrypt, 
    $requestObj->privateKeyToDecryptMsg, 
    $requestObj->keyPassword
);
 
echo json_encode(array("decrypted" => $textDecrypted));

As of March 2026, the WWBN/AVideo repository remains unpatched for this specific issue. To remediate this flaw, developers must introduce an explicit authentication verification block at the beginning of the script. This block must terminate the script execution if the requester does not hold a valid session.

// Required Patch Pattern
header('Content-Type: application/json');
 
// Enforce authentication check immediately
if (!User::isLogged()) {
    http_response_code(403);
    die(json_encode(array("error" => "Access denied. Authentication required.")));
}
 
$postData = file_get_contents("php://input");
$requestObj = json_decode($postData);
 
$textDecrypted = decryptMessage(
    $requestObj->textToDecrypt, 
    $requestObj->privateKeyToDecryptMsg, 
    $requestObj->keyPassword
);

This proposed fix ensures that the runtime environment evaluates the user's authentication state before parsing the JSON body or allocating resources. If the User::isLogged() condition returns false, the script halts immediately, completely mitigating both the resource exhaustion vector and the localized logging exposure.

Exploitation of this vulnerability requires minimal technical sophistication and no specialized network positioning. An attacker must simply identify an AVideo instance exposing the /plugin/LoginControl/pgp/decryptMessage.json.php endpoint. The attack relies solely on standard HTTP requests.

The attacker crafts a custom HTTP POST payload containing valid, base64-encoded PGP material. The payload structure must conform to the JSON schema expected by the script. This includes a valid private key, a ciphertext block encrypted for that specific key, and the corresponding passphrase.

curl -s -X POST \
  "https://target.example.com/plugin/LoginControl/pgp/decryptMessage.json.php" \
  -H "Content-Type: application/json" \
  -d '{
    "textToDecrypt": "-----BEGIN PGP MESSAGE-----\n<base64_ciphertext>\n-----END PGP MESSAGE-----",
    "privateKeyToDecryptMsg": "-----BEGIN PGP PRIVATE KEY BLOCK-----\n<base64_private_key>\n-----END PGP PRIVATE KEY BLOCK-----",
    "keyPassword": "passphrase"
  }'

Upon receiving the request, the AVideo server processes the payload and returns the decrypted plaintext in the HTTP response. A threat actor can script this exploitation phase, submitting highly complex cryptographic tasks in rapid succession to deliberately saturate the CPU capabilities of the hosting environment.

The concrete security impact of GHSA-5X2W-37XF-7962 focuses on application availability and secondary information disclosure. The vulnerability holds a CVSS v4.0 score of 4.8 (Medium), represented by the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N. This score reflects the immediate lack of system-level compromise, contrasted with the localized disruption capabilities.

The primary concern is the potential for Application-layer Denial of Service (T1499.003). Asymmetric cryptographic operations, particularly PGP decryption, demand significant CPU overhead. By orchestrating a flood of valid decryption requests, an unauthenticated attacker can effectively monopolize the application's PHP worker pool. This resource starvation renders the AVideo platform unresponsive to legitimate user traffic.

A secondary risk involves CWE-312 (Cleartext Storage of Sensitive Information). The attack requires the submission of raw PGP private keys and their plaintext passphrases in the HTTP request body. Web application environments frequently feature extensive diagnostic logging, error tracing, or WAF inspection mechanisms that serialize and store incoming POST bodies. This behavior inadvertently records sensitive key material in persistent, unencrypted system logs.

Finally, the vulnerability provides attackers with an anonymous cryptographic processing oracle. Threat actors can abuse this exposed infrastructure to perform their own unrelated PGP decryption tasks, obfuscating their operational infrastructure while shifting the computational burden and power costs onto the victim organization.

As of the initial disclosure in March 2026, the WWBN/AVideo upstream repository has not released an official patch specifically resolving GHSA-5X2W-37XF-7962. Consequently, system administrators and security engineering teams must rely on localized mitigation strategies to secure vulnerable instances. The most effective immediate mitigation requires web server-level restrictions.

Administrators should implement access control rules within their web server configuration (Nginx or Apache) to deny public access to the plugin/LoginControl/pgp/ directory entirely. If the application configuration permits, restricting this directory to internal IP ranges or requiring HTTP Basic Authentication will prevent anonymous exploitation attempts. In Nginx, this involves creating a specific location block that returns a 403 Forbidden status for the targeted URI.

For teams capable of modifying the application source code directly, inserting the User::isLogged() check at the absolute beginning of decryptMessage.json.php serves as a permanent hotfix. This code-level remediation correctly aligns the script's execution requirements with the platform's overarching authorization architecture.

Furthermore, organizations must review their observability and logging pipelines. It is essential to configure web application firewalls, load balancers, and PHP error handlers to sanitize or drop POST request bodies directed at cryptographic endpoints. This operational safeguard prevents the incidental persistence of sensitive private keys and passphrases in system logs.