CVE-2026-82645 in AVideo
Summary
by MITRE • 08/30/2026
AVideo (current commit e01e41ecc and earlier) exposes stream credentials through the plugin/Live/view/Live_restreams/getLiveKey.json.php endpoint. Supplying a 'token' request parameter waives both the Live::canRestream() access gate and the restream ownership check, causing the endpoint to return any restream's stream_key and stream_url (credentials for external platforms such as YouTube, Facebook, and Twitch) without authentication. The token is merely encryptString() of an integer id with no user binding, expiry, or authentication tag. Because encryption uses AES-256-CBC with a deterministic IV and no MAC, and because intval() accepts any string beginning with a digit, an unauthenticated attacker can forge valid tokens using the public encryption oracle in view/url2Embed.json.php, disclosing arbitrary users' stream credentials.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified in AVideo versions up to commit e01e41ecc represents a critical authentication bypass and cryptographic failure that allows unauthenticated attackers to exfiltrate sensitive streaming credentials for external platforms such as YouTube, Facebook, and Twitch. The core of the issue resides within the Live_restreams/getLiveKey.json.php endpoint, which is designed to retrieve stream keys and URLs required for restreaming services. Under normal operational conditions, this endpoint should enforce strict access controls via the Live::canRestream() method and verify that the requesting user owns the specific restream configuration being accessed. However, a flaw in the token validation logic allows these security gates to be completely bypassed when a 'token' parameter is supplied with a specifically crafted value.
The mechanism enabling this exploitation relies on a fundamental misunderstanding of secure token generation within the application's codebase. The system generates tokens by applying an encryptString() function to an integer identifier, presumably representing a restream ID or user ID. This process fails to bind the token to any specific session, user identity, or timestamp, and critically lacks any message authentication code (MAC) to ensure integrity. Furthermore, the encryption implementation utilizes AES-256-CBC with a deterministic initialization vector rather than a random one. In cryptographic terms, using a static IV in CBC mode means that identical plaintexts always produce identical ciphertexts, creating a predictable pattern that can be exploited by an attacker who has access to an encryption oracle.
An encryption oracle is present within the application at the view/url2Embed.json.php endpoint, which allows unauthenticated users to encrypt arbitrary data of their choosing. By leveraging this public oracle, an attacker can construct valid tokens for any target restream ID without possessing prior knowledge of the secret key or having legitimate access rights. The intval() function used later in the validation process further exacerbates the issue by accepting strings that begin with a digit and ignoring subsequent non-numeric characters. This permissive parsing allows attackers to inject crafted payloads into the token field, effectively forging authentication credentials that the server accepts as valid for any arbitrary restream configuration.
The operational impact of this vulnerability is severe, resulting in the complete disclosure of sensitive stream credentials across all user accounts on the affected platform. Since these tokens grant access to high-value external services like Twitch and YouTube, their exposure can lead to unauthorized broadcasting, content theft, or the use of compromised channels for malicious activities such as distributing malware or engaging in fraud. This aligns with CWE-287 Improper Authentication, where the system fails to correctly verify identity before granting access, and CWE-327 Use of a Broken or Risky Cryptographic Algorithm, specifically regarding the misuse of CBC mode without integrity checks like HMAC. From an ATT&CK perspective, this vulnerability facilitates Credential Access through techniques such as Valid Accounts exploitation and potentially Information Discovery via unauthorized API enumeration.
Mitigation strategies must address both the architectural flaws in token generation and the underlying cryptographic weaknesses. The immediate remediation involves removing or restricting access to the view/url2Embed.json.php endpoint if it is not strictly necessary for public functionality, thereby eliminating the encryption oracle that enables token forgery. More fundamentally, the application should implement stateless authentication tokens using industry-standard practices such as JSON Web Tokens (JWT) with strong signatures like HMAC-SHA256 or RSA-based signing to ensure integrity and authenticity. If custom token generation is required, it must utilize a random initialization vector for each encryption operation and include a MAC to prevent tampering. Additionally, the intval() parsing logic should be replaced with strict type checking that rejects any input not consisting solely of numeric digits, ensuring that only properly formatted identifiers are processed by backend validation routines.