Summary
AVideo contains an unauthenticated SQL injection flaw in the streamer login and account-creation flow, where attacker-controlled input can reach a MariaDB query without reliable parameterization.
Under deployment conditions that allow the affected request path and response-controlled account flags, an attacker may read sensitive encoder database records, including streamer credentials and queue data.
AVideo contains an unauthenticated SQL injection flaw in the streamer login and account-creation flow, where attacker-controlled input can reach a MariaDB query without reliable parameterization.
Under deployment conditions that allow the affected request path and response-controlled account flags, an attacker may read sensitive encoder database records, including streamer credentials and queue data.
Affected context
The vulnerability affects AVideo deployments using the streamer login functionality before the security fix. Risk is present when:
- The unauthenticated login endpoint is reachable
- User input is incorporated into streamer lookups
- Input filtering can be bypassed through entity decoding
- The site URL allowlist is empty or otherwise permits the relevant request
- The login response can satisfy conditions that invoke streamer creation logic
The demonstrated impact is primarily unauthorized database reading rather than server-side file modification.
The vulnerability affects AVideo deployments using the streamer login functionality before the security fix. Risk is present when:
- The unauthenticated login endpoint is reachable
- User input is incorporated into streamer lookups
- Input filtering can be bypassed through entity decoding
- The site URL allowlist is empty or otherwise permits the relevant request
- The login response can satisfy conditions that invoke streamer creation logic
The demonstrated impact is primarily unauthorized database reading rather than server-side file modification.
Exploit preconditions
- Attack surface: Publicly reachable streamer login and account-management endpoints
- Required access: No valid AVideo or encoder credentials are required; the attacker must be able to send requests and influence the relevant login input and response conditions
- Trigger point: Streamer lookup and creation logic invoked during login processing
- Why exploitation is possible: User-controlled data is interpolated into a SQL statement, while filtering occurs before entity decoding and therefore does not reliably remove quote characters
- Deployment dependency: The streamer site allowlist must accept the supplied site URL, which may occur by default when the allowlist is empty
- Attack surface: Publicly reachable streamer login and account-management endpoints
- Required access: No valid AVideo or encoder credentials are required; the attacker must be able to send requests and influence the relevant login input and response conditions
- Trigger point: Streamer lookup and creation logic invoked during login processing
- Why exploitation is possible: User-controlled data is interpolated into a SQL statement, while filtering occurs before entity decoding and therefore does not reliably remove quote characters
- Deployment dependency: The streamer site allowlist must accept the supplied site URL, which may occur by default when the allowlist is empty
Why this happens
The underlying flaw is an SQL injection caused by constructing a MariaDB query through string interpolation rather than binding user-controlled values as parameters. A filtering step attempts to remove literal quote characters, but later HTML entity decoding restores equivalent characters before the query executes.
This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'). The vulnerable pattern combines incomplete input canonicalization with dynamic SQL construction, allowing data intended as a value to influence query structure.
The underlying flaw is an SQL injection caused by constructing a MariaDB query through string interpolation rather than binding user-controlled values as parameters. A filtering step attempts to remove literal quote characters, but later HTML entity decoding restores equivalent characters before the query executes.
This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'). The vulnerable pattern combines incomplete input canonicalization with dynamic SQL construction, allowing data intended as a value to influence query structure.
Potential impact
- An attacker may read arbitrary records from the encoder database
- Stored upstream streamer credentials could be disclosed
- Allowlist settings and queue records may be exposed
- Stolen credentials could enable continued upstream access until rotated
- Database errors and rendered query information may reveal additional implementation details
- Confidentiality of video-processing and streaming operations could be reduced
- An attacker may read arbitrary records from the encoder database
- Stored upstream streamer credentials could be disclosed
- Allowlist settings and queue records may be exposed
- Stolen credentials could enable continued upstream access until rotated
- Database errors and rendered query information may reveal additional implementation details
- Confidentiality of video-processing and streaming operations could be reduced
General mitigation guidance
Mitigation generally focuses on removing dynamic SQL construction and reducing trust in request-derived values.
Common defensive patterns include:
- Use parameterized queries or prepared statements for every user-influenced database value
- Apply canonicalization before validation and avoid treating output encoding as a substitute for query safety
- Enforce strict server-side validation for streamer identifiers, URLs, and account-state fields
- Use deny-by-default allowlists for trusted sites and require explicit configuration
- Return generic database errors rather than query text or backend diagnostics
- Apply least-privilege permissions to the database account and limit access to only required tables and operations
- Rotate exposed streamer credentials and review records that may have been accessed
Mitigation generally focuses on removing dynamic SQL construction and reducing trust in request-derived values.
Common defensive patterns include:
- Use parameterized queries or prepared statements for every user-influenced database value
- Apply canonicalization before validation and avoid treating output encoding as a substitute for query safety
- Enforce strict server-side validation for streamer identifiers, URLs, and account-state fields
- Use deny-by-default allowlists for trusted sites and require explicit configuration
- Return generic database errors rather than query text or backend diagnostics
- Apply least-privilege permissions to the database account and limit access to only required tables and operations
- Rotate exposed streamer credentials and review records that may have been accessed
How teams detect issues like this
Detection can combine code analysis, runtime monitoring, and configuration review:
- Use static analysis rules to identify SQL statements built through string concatenation, interpolation, or formatting
- Review request paths that decode, normalize, or transform input after security filtering
- Inspect code for database calls that accept raw request parameters instead of bound parameters
- Monitor web and database logs for unusual streamer login requests, repeated errors, UNION-like query behavior, or unexpected record enumeration
- Alert on database errors or responses that expose rendered queries and backend diagnostics
- Enforce CI policies requiring parameterized database access and deny-by-default allowlist configuration
- Automated code review and application security testing tools may help identify injection-prone query construction
Detection can combine code analysis, runtime monitoring, and configuration review:
- Use static analysis rules to identify SQL statements built through string concatenation, interpolation, or formatting
- Review request paths that decode, normalize, or transform input after security filtering
- Inspect code for database calls that accept raw request parameters instead of bound parameters
- Monitor web and database logs for unusual streamer login requests, repeated errors, UNION-like query behavior, or unexpected record enumeration
- Alert on database errors or responses that expose rendered queries and backend diagnostics
- Enforce CI policies requiring parameterized database access and deny-by-default allowlist configuration
- Automated code review and application security testing tools may help identify injection-prone query construction
