CVE-2026-34362
Persistent WebSocket Token Exposure in WWBN AVideo Plugin
Publication date: 2026-03-27
Last updated on: 2026-03-31
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| wwbn | avideo | to 26.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-613 | According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization." |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows WebSocket tokens to never expire, enabling attackers or unauthorized users to maintain indefinite access to real-time connection data, including sensitive personal information such as IP addresses, browser details, device IDs, usernames, and page locations.
Such persistent unauthorized access and real-time surveillance capabilities can lead to violations of data protection regulations like GDPR and HIPAA, which require strict controls on access to personal data, timely revocation of access rights, and protection against unauthorized data disclosure.
Specifically, the indefinite validity of tokens bypasses account lifecycle controls (e.g., user deletion, banning, or demotion), undermining compliance requirements for access management and session expiration.
Therefore, this vulnerability poses a risk to compliance with standards mandating secure session management, user data confidentiality, and timely revocation of access privileges.
Can you explain this vulnerability to me?
CVE-2026-34362 is a vulnerability in the WWBN AVideo open source video platform (versions up to 26.0) where the WebSocket token expiration check is disabled. Specifically, the function verifyTokenSocket() in plugin/YPTSocket/functions.php has its token timeout validation code commented out, causing WebSocket tokens to never expire despite being generated with a 12-hour timeout.
This means that tokens, once obtained legitimately or captured by an attacker, can be used indefinitely to access WebSocket connections. Even if user accounts are deleted, banned, or demoted, their tokens remain valid.
If the token belongs to an admin user, it grants access to sensitive real-time data about all online users, including IP addresses, browser information, device IDs, usernames, and page locations. The vulnerability allows attackers to impersonate users, maintain persistent access, and surveil user activity in real time.
How can this vulnerability impact me? :
This vulnerability can impact you by allowing attackers to gain permanent WebSocket access using stolen or captured tokens that never expire.
- Deleted, banned, or demoted users can still access the system indefinitely via their tokens.
- Attackers with admin tokens can access detailed real-time information about all connected users, including sensitive data such as IP addresses, browser details, and page locations.
- The extended attack window means stolen tokens can be reused indefinitely, increasing the risk of identity hijacking and unauthorized surveillance.
- The vulnerability undermines session management and access control, allowing persistent unauthorized access without user interaction.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves WebSocket tokens that never expire due to disabled timeout validation in the verifyTokenSocket() function. Detection can focus on identifying WebSocket connections using tokens that are older than the intended 12-hour expiration.
To detect this on your network or system, you can monitor WebSocket connection requests for the presence of the webSocketToken parameter and analyze token timestamps to check if expired tokens are still being accepted.
Suggested commands or approaches include:
- Capture WebSocket traffic using tools like Wireshark or tcpdump filtering on the WebSocket port (usually 80 or 443) and inspect the query parameters for webSocketToken.
- Use grep or similar tools on server logs to find WebSocket connection attempts containing the webSocketToken parameter.
- Analyze token payloads (if decryptable) to check token creation and expiration times, verifying if tokens older than 12 hours are still accepted.
- Monitor for persistent WebSocket connections from users who should no longer have access, such as deleted or banned accounts.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include applying the fix that enforces token expiration in the verifyTokenSocket() function by uncommenting the timeout validation code to reject expired tokens.
Additional recommended actions are:
- Update the WWBN AVideo installation to a version including the patch from commit 5d5237121bf82c24e9e0fdd5bc1699f1157783c5.
- Restrict access to the getClientsList handler to admin users only to limit exposure of real-time user data.
- Implement periodic re-validation of the isAdmin claim against the database rather than trusting the token for the entire connection lifetime.
- Disable automatic WebSocket reconnections that reuse stale tokens and ensure fresh tokens are fetched before reconnecting.