GHSA-JFWG-RXF3-P7R9: CQL/N1QL Injection in Authorizer via String Interpolation

Authorizer provides authentication and authorization infrastructure for web applications. It supports multiple database backends for storage and session management. The Cassandra and Couchbase storage adapters in versions prior to 2.0.1 contain a critical injection vulnerability. The flaw exists because the software uses unsafe string interpolation to construct database queries.

The vulnerability maps to CWE-943 (Improper Neutralization of Special Elements in Data Query Logic). The application dynamically interpolates unvalidated user input directly into query strings using Go's fmt.Sprintf function. This allows attackers to manipulate the logic of Cassandra Query Language (CQL) and Couchbase N1QL queries.

The impact spans authentication bypass, unauthorized data modification, and sensitive information disclosure. Attackers can leverage this vulnerability to gain administrative access or extract underlying credential data. The vulnerability resides exclusively in the Cassandra and Couchbase backends; instances utilizing other storage mechanisms remain unaffected by this specific implementation flaw.

The root cause of GHSA-JFWG-RXF3-P7R9 is the reliance on manual string formatting for query construction rather than parameterized database operations. In Go applications, fmt.Sprintf performs simple string substitution without contextual awareness of the target data format. The Authorizer codebase applied this pattern extensively across its internal/storage/db/cassandradb/ package.

Analysis of the affected repository indicates over 66 distinct queries within the Cassandra backend and 3 queries within the Couchbase backend utilized this vulnerable pattern. Variables representing user-controlled data, such as email addresses, user identifiers, authentication tokens, and session keys, were passed directly to fmt.Sprintf format specifiers (%s). The resulting string was subsequently executed by the database driver.

Cassandra (CQL) and Couchbase (N1QL) utilize syntax structures similar to traditional SQL. When a query string encapsulates user input within single quotes, an attacker supplying a malicious payload containing a single quote character can prematurely terminate the string literal. The remaining payload is then parsed as executable query syntax by the respective database engine, fundamentally altering the intended execution logic.

The absence of input sanitization compounds the vulnerability. The application did not attempt to escape single quotes or validate the structural integrity of the parameters before execution. Consequently, the query engines executed the structurally modified queries under the application's assigned privilege level.

The pre-patch implementation within the GetAuthenticatorDetailsByUserId function demonstrates the structural flaw. The code dynamically constructed a SELECT statement by concatenating the keyspace, collection name, and user-provided variables.

// Vulnerable snippet from GetAuthenticatorDetailsByUserId
query := fmt.Sprintf("SELECT id, user_id, method, secret, recovery_codes, verified_at, created_at, updated_at FROM %s WHERE user_id = '%s' AND method = '%s' LIMIT 1 ALLOW FILTERING", KeySpace+"."+schemas.Collections.Authenticators, userId, authenticatorType)
err := p.db.Query(query).Consistency(gocql.One).Scan(...)

The mitigation implemented in Pull Request #500 (Commit 73679fa) replaces string interpolation with parameterized queries. For the Cassandra backend, the gocql library processes ? placeholders. The variables are passed as explicit arguments to the Query() method, delegating the escaping and type safety responsibilities to the database driver.

// Patched snippet from GetAuthenticatorDetailsByUserId
query := fmt.Sprintf("SELECT id, user_id, method, secret, recovery_codes, verified_at, created_at, updated_at FROM %s WHERE user_id = ? AND method = ? LIMIT 1 ALLOW FILTERING", KeySpace+"."+schemas.Collections.Authenticators)
err := p.db.Query(query, userId, authenticatorType).Consistency(gocql.One).Scan(...)

The Couchbase backend required a similar refactoring strategy utilizing named parameters. The developers updated the query execution logic to bind values securely. Additionally, the patch introduced a convertMapValues helper function to process json.Number types produced by the Go JSON decoder. This ensures compatibility with Cassandra's bigint and double column definitions during parameterized binding operations.

Exploitation requires the attacker to send a maliciously crafted HTTP request targeting endpoints that process user identifiers, authentication tokens, or webhook configurations. The objective is to manipulate the syntax of the underlying CQL or N1QL query. The attacker identifies a vulnerable parameter and injects a payload containing a single quote followed by conditional operators.

A standard injection payload for the userId parameter takes the form test' OR '1'='1. When processed by the vulnerable fmt.Sprintf implementation, the generated query becomes SELECT ... WHERE user_id = 'test' OR '1'='1' AND method = '...'. The database evaluates the injected logical OR condition as true for all records, overriding the intended filtering criteria.

In the context of the Cassandra backend, the ALLOW FILTERING directive appended to many queries facilitates the execution of these modified statements. While Cassandra strictly enforces indexing rules on queries, ALLOW FILTERING permits the database to scan the entire table and filter the results post-retrieval. This configuration inadvertently ensures the attacker's payload executes without triggering index-related syntax errors.

Depending on the targeted query structure, the execution yields distinct security failures. For authentication checks, the query returns the first user record encountered, effectively logging the attacker into an arbitrary account. For data retrieval operations, the attacker extracts session keys or recovery codes by forcing the application to dump the collection contents.

The primary consequence of this vulnerability is the complete subversion of the authentication mechanism. Attackers can bypass credential verification phases by forcing the storage layer to return valid user objects regardless of the provided password or token. This grants unauthenticated adversaries administrative or user-level access to the protected application.

Secondary impacts involve unauthorized data access and modification. The Couchbase update query vulnerabilities allow attackers to overwrite arbitrary fields within the target documents. By manipulating the WHERE _id='%s' clause, an attacker forces the application to alter configuration settings, webhook destinations, or security policies stored within the database.

The vulnerability also introduces an information disclosure vector mapped to CWE-209 (Generation of Error Message Containing Sensitive Information). Malformed injection attempts that trigger syntax errors within the database layer cause the application to return verbose error messages. These messages expose internal database schemas, column definitions, and structural metadata to the external attacker.

The operational impact extends beyond the authentication layer. Centralized identity providers control access to downstream services. Compromising the Authorizer instance breaks the security boundaries of all dependent applications relying on the provider for OAuth/OIDC validation.

The authoritative remediation strategy requires upgrading the Authorizer deployment to version 2.0.1 or later. This release incorporates the comprehensive migration to parameterized queries across both the Cassandra and Couchbase storage interfaces. Administrators must verify the version deployment across all environment tiers.

For environments utilizing the Cassandra backend where immediate patching is strictly impossible, operators must implement intermediate mitigation strategies. Deploying a Web Application Firewall (WAF) configured to inspect and drop payloads containing single quotes or SQL-like logical operators within JSON request bodies provides a temporary defense mechanism. This approach is brittle and susceptible to evasion techniques, but reduces the immediate attack surface.

Organizations must rotate sensitive cryptographic material if they detect prior exploitation. Reviewing database query logs for anomalous OR clauses or syntax errors originating from the application tier aids in identifying historical compromise. All session keys, recovery codes, and integration tokens stored within the vulnerable database clusters must be considered potentially compromised.

Code auditing teams responsible for reviewing custom extensions or forks of the Authorizer project should proactively grep the codebase for fmt.Sprintf usages adjacent to database query execution methods. This identifies incomplete merges or divergent code paths that reintroduce the vulnerability.