CVE-2026-34374
SQL Injection in WWBN AVideo Live_schedule Stream Key Lookup
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-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows an unauthenticated attacker to perform SQL injection attacks that can extract the entire MySQL database contents, including plaintext or hashed user credentials, email addresses, API tokens, and platform configuration data.
Such unauthorized access to sensitive personal and authentication data can lead to violations of data protection regulations and standards such as GDPR and HIPAA, which require the protection of personal and sensitive information against unauthorized access and breaches.
Therefore, the presence of this vulnerability significantly undermines compliance with these common standards and regulations by exposing confidential data to attackers.
Can you explain this vulnerability to me?
CVE-2026-34374 is a critical SQL injection vulnerability in the WWBN AVideo open source video platform, specifically in the Live_schedule::keyExists() method. This method constructs a SQL query by directly inserting a stream key into the query string without using parameterized queries, which is unsafe.
The vulnerability occurs as a fallback mechanism when the initial secure, parameterized query in LiveTransmition::keyExists() returns no results. The fallback method improperly embeds the cleaned stream key directly into the SQL query without proper escaping or sanitization.
The cleanUpKey() function only removes certain streaming quality suffixes but does not prevent SQL injection characters. Input filtering is insufficient, allowing malicious SQL payloads to be executed during RTMP publish authentication.
An attacker can exploit this by submitting specially crafted stream keys that cause SQL commands to be executed, such as time-based blind SQL injection payloads that delay server responses to confirm the injection.
How can this vulnerability impact me? :
This vulnerability allows an unauthenticated attacker to perform SQL injection attacks on the WWBN AVideo platform, potentially extracting the entire MySQL database contents.
- Access to plaintext or hashed user credentials.
- Exposure of email addresses.
- Disclosure of API tokens.
- Leakage of platform configuration data.
The attack requires no privileges or user interaction and can be executed remotely over the network, making it highly severe with a CVSS score of 9.1.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by testing the RTMP publish authentication endpoint for SQL injection via the 'name' POST parameter (stream key). Specifically, sending payloads that include SQL injection attempts such as time-based blind SQL injection can reveal the issue.
For example, sending a POST request with the 'name' parameter set to a payload like "nonexistent' OR SLEEP(3)--" and observing a delay in the server response indicates the presence of the vulnerability.
A sample command using curl to test this might be:
- curl -X POST -d "name=nonexistent' OR SLEEP(3)--&p=somevalue" http://your-avideo-server/on_publish.php
If the server response is delayed by approximately 3 seconds, it confirms the SQL injection vulnerability.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves modifying the vulnerable method Live_schedule::keyExists() to use parameterized SQL queries instead of directly interpolating the stream key into the query string.
Specifically, update the code from:
- $sql = "SELECT ... WHERE ls.`key` = '$key' AND ..."; $res = sqlDAL::readSql($sql);
to:
- $sql = "SELECT ... WHERE ls.`key` = ? AND ..."; $res = sqlDAL::readSql($sql, 's', [$key]);
This change prevents direct interpolation of user input and mitigates the SQL injection risk.
Since no patched versions are available as of the publication date, applying this code fix manually or implementing input sanitization and strict filtering on the 'name' parameter during RTMP publish authentication are recommended immediate steps.