GHSA-jfwg-rxf3-p7r9
HIGHAuthorizer: CQL/N1QL Injection in Cassandra and Couchbase Backends via fmt.Sprintf String Interpolation
Blast Radius
github.com/authorizerdev/authorizerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Vulnerability Details
CWE: CWE-943 - Improper Neutralization of Special Elements in Data Query Logic
All 66+ CQL queries in internal/storage/db/cassandradb/ use fmt.Sprintf to interpolate user-controlled values directly into CQL query strings without parameterization.
Unauthenticated endpoints (signup, login, forgot_password, magic_link_login) pass user input directly into CQL query strings.
Note: This advisory covers the Cassandra CQL injection only. The Couchbase N1QL injection is tracked in a separate advisory per CVE rule 4.2.11.
Affected Code Pattern
// Before (VULNERABLE) - e.g. cassandradb/user.go
query := fmt.Sprintf("SELECT ... FROM %s WHERE email = '%s'", table, email)
err := p.db.Query(query).Scan(...)
Steps to Reproduce
- Deploy Authorizer <= 2.0.0 with Cassandra backend
- Send a signup request with a CQL injection payload in the email field:
curl -X POST http://localhost:8080/graphql \
-H 'Content-Type: application/json' \
-d '{"query":"mutation { signup(params: { email: \"test'\" }) { message } }"}'
- The single quote breaks out of the CQL string literal, causing a CQL parse error that leaks internal schema information
- Crafted payloads can manipulate query logic to bypass authentication or extract data
Affected Files (10 Cassandra files)
| Package | File | Queries Fixed |
|---|---|---|
| cassandradb | user.go | 7 |
| cassandradb | otp.go | 4 |
| cassandradb | session_token.go | 19 |
| cassandradb | verification_requests.go | 4 |
| cassandradb | authenticator.go | 3 |
| cassandradb | email_template.go | 5 |
| cassandradb | webhook.go | 5 |
| cassandradb | webhook_log.go | 2 |
| cassandradb | session.go | 1 |
| cassandradb | env.go | 2 |
Impact
An unauthenticated attacker can inject arbitrary CQL operators through the email, phone, or token parameters on public-facing endpoints (signup, login, forgot_password, magic_link_login). This enables authentication bypass and data exfiltration from the Cassandra keyspace.
Proposed Fix
Use parameterized queries:
// After (FIXED)
query := fmt.Sprintf("SELECT ... FROM %s WHERE email = ?", table)
err := p.db.Query(query, email).Scan(...)
Fixed in https://github.com/authorizerdev/authorizer/pull/500 (merged 2026-03-27).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/authorizerdev/authorizer | all versions | 0.0.0-20260327055742-73679faa53cd |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/authorizerdev/authorizer. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/authorizerdev/authorizer to 0.0.0-20260327055742-73679faa53cd or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jfwg-rxf3-p7r9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-jfwg-rxf3-p7r9 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-jfwg-rxf3-p7r9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-jfwg-rxf3-p7r9 in your dependencies?
O3 detects GHSA-jfwg-rxf3-p7r9 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.