CVE-2023-22794

What it actually does

CVE-2023-22794 is a SQL injection flaw in Ruby on Rails Active Record query annotation/comment handling. When attacker-controlled input is passed into APIs that add SQL comments to generated queries, insufficient sanitization can allow comment termination and injection of additional SQL fragments. Impact depends on database permissions and application query patterns, but can include unauthorized data reads, modification, deletion, authentication bypass through query manipulation, or database error disclosure. The issue is not in every Rails route by default; exploitation requires an application to pass untrusted input into the vulnerable Active Record comment/annotation path.

Why it matters to the business

A vulnerable Rails application may expose sensitive business data or allow unauthorized changes to data if user input reaches the affected Active Record SQL comment functionality. Because Rails is widely used for web applications and public exploit information is available, affected internet-facing applications should be prioritized even though this issue is not currently in CISA KEV and has a relatively low EPSS score. Successful exploitation can lead to data breach response costs, regulatory exposure, service disruption from corrupted records, and loss of customer trust.

How an attack unfolds

An attacker first identifies a Rails endpoint or feature where a request parameter is incorporated into Active Record query annotations or SQL comments. They submit crafted input containing SQL comment-breakout sequences and database-specific SQL syntax so that the application-generated query is altered when sent to the database. If the database accepts the modified query, the attacker iterates payloads to enumerate schema details, extract records, change application data, or trigger error messages that reveal useful information. Exploitation is constrained by whether the vulnerable API is reachable with attacker-controlled data, the database adapter in use, SQL permissions granted to the application user, and whether application or WAF controls block suspicious payloads. The supplied threat-actor field appears to reference an unrelated HTTP/2 Rapid Reset issue rather than a named actor known to exploit this Rails flaw.

How to fix it

Upgrade Rails to a version containing the upstream fix. For the Git-sourced rails/rails package, apply or upgrade past commit 28bb76d3efc39b2ef663dfe2346f7c2621343cd6. For packaged Rails deployments, use vendor-supported releases that include the fix, commonly Rails 6.1.7.1 or 7.0.4.1 or later, and verify against the official Rails advisory for the maintained branch in use. Rebuild and redeploy applications after updating dependencies, refresh lockfiles, and restart application processes. As an interim mitigation, ensure no untrusted request data is passed to Active Record query annotation/comment APIs such as annotate or optimizer hint/comment-like helpers; replace dynamic annotations with static strings, strict allowlists, or remove them entirely. Keep database accounts least-privileged so application credentials cannot perform unnecessary DDL, administrative operations, or broad writes.

How to confirm the fix worked

Confirm dependency resolution shows Rails/Active Record at a fixed release or, for Git-based installs, at or after commit 28bb76d3efc39b2ef663dfe2346f7c2621343cd6. Review Gemfile.lock, bundler-audit, Dependabot, osv-scanner, Snyk, or similar SCA results to ensure CVE-2023-22794 is no longer reported. Search application code for Active Record annotation/comment usage and verify attacker-controlled values are not passed into those APIs. In a non-production test environment, send safe validation strings containing SQL comment delimiters such as */ and confirm they are escaped, rejected, or do not alter generated SQL. Enable SQL logging during testing and inspect generated queries to ensure annotation content remains inside comments and cannot terminate the comment block.

Typical attack path

1. Reconnoiter the Rails application for endpoints whose parameters affect query metadata, annotations, reporting, search, filtering, debugging, or administrative query labels.
2. Send benign probes containing SQL comment delimiters and metacharacters to observe database errors, response changes, timing differences, or log artifacts.
3. Craft a payload that terminates the intended SQL comment and appends attacker-controlled SQL syntax compatible with the backend database.
4. Use iterative SQL injection techniques to confirm control over the query, enumerate database structure, and identify high-value tables or records.
5. Extract, modify, or delete data within the privileges of the application database account, or use database functions to support further compromise if permissions allow.
6. Cover tracks by minimizing noisy errors, using time-based or boolean techniques, and blending payloads into normal web traffic.

How to detect it

To determine whether exploitation already occurred, correlate web access logs, application logs, Rails exception logs, WAF alerts, and database query/error logs. Focus on endpoints that accept parameters later used in query annotations, comments, reporting labels, search filters, exports, or admin/debug features. Look for SQL comment-breakout sequences such as */ followed by SQL keywords, URL-encoded variants, unexpected database syntax errors, and bursts of 4xx/5xx responses during probing. Database logs may show malformed comments, stacked-query attempts, UNION/select probes, sleep/time-delay functions, or unusually broad SELECT/UPDATE/DELETE activity by the application database user. Rails logs may contain ActiveRecord::StatementInvalid, adapter-specific SQL errors, or request parameters with encoded comment delimiters. If suspicious activity is found, preserve relevant request bodies, query logs, database audit records, and application deployments for forensic review, then assess whether sensitive records were accessed or modified.

• */
• %2A%2F
• %2a%2f
• */--
• %2A%2F--
• */#
• */;
• ActiveRecord::StatementInvalid
• PG::SyntaxError
• PG::Error
• Mysql2::Error
• SQLite3::SQLException
• You have an error in your SQL syntax
• unterminated /* comment
• unterminated comment
• syntax error at or near
• UNION SELECT
• union select
• SLEEP(
• pg_sleep(
• benchmark(
• information_schema
• sqlite_master
• 28bb76d3efc39b2ef663dfe2346f7c2621343cd6

What your security team should do

• Inventory Rails applications and identify those using affected Rails/Active Record versions, prioritizing internet-facing and data-sensitive applications.
• Patch or upgrade to a fixed Rails version, or apply the upstream Git commit 28bb76d3efc39b2ef663dfe2346f7c2621343cd6 where source-based dependency management is used.
• Review code for dynamic use of Active Record query annotations/comments and remove or strictly sanitize any user-controlled values.
• Run SCA tooling in CI/CD and fail builds that resolve to vulnerable Rails versions.
• Harden database permissions for application accounts to reduce blast radius from SQL injection.
• Increase logging around web requests, application exceptions, and database errors while patching is underway.
• Hunt historical logs for SQL comment-breakout payloads, unusual database errors, and suspicious requests targeting endpoints that influence query annotations.
• Add WAF or reverse-proxy detection for SQL comment termination and stacked-query patterns as compensating control, while avoiding reliance on WAF rules as the primary fix.