CVE-2026-128084: 
Ruby Analyse et atténuation de la vulnérabilité

CVE-2026-128084 is a SQL query truncation vulnerability in the sqlite3-ruby gem (Ruby bindings for SQLite3) caused by an incorrect numeric type conversion. The C extension casts 64-bit Ruby string lengths (long) to 32-bit int before passing SQL strings and bound values to SQLite, causing integer wraparound on 64-bit platforms for strings ≥ 4 GiB. This can result in SQLite processing only a prefix of the string, potentially dropping trailing SQL clauses such as WHERE conditions. All versions prior to 2.10.2 of the sqlite3 RubyGem (vendor: sparklemotion) are affected. The vulnerability was responsibly disclosed by Luke Jahnke from elttam, published on October 26, 2026, and has a CVSS v3.1 base score of 4.8 (Medium) (GitHub Advisory).

The root cause is CWE-681 (Incorrect Conversion between Numeric Types): the C extension in statement.c and database.c used (int)RSTRING_LEN(...) to cast Ruby's native long string length to a 32-bit int before passing it to SQLite APIs. On 64-bit platforms, a string of 4 GiB (2^32 bytes) or larger causes the length to wrap modulo 2^32, so SQLite receives a truncated length and reads only a prefix of the string. The affected code paths include SQL passed to Database#prepare, #execute, and related methods; String and Blob values passed to Statement#bind_param; and String/Blob results returned from Ruby-defined SQL functions and aggregates via Database#create_function and #create_aggregate. The fix replaces all (int)RSTRING_LEN(...) casts with RSTRING_LENINT(...), which raises a RangeError instead of silently truncating (GitHub PR #762, Commit 41059aa).

The primary risk is integrity and confidentiality compromise through SQL query truncation: an attacker who can supply a ≥4 GiB string inlined into a SQL query could cause trailing clauses (e.g., WHERE conditions) to be silently dropped, potentially bypassing authentication checks or access controls. Confidentiality impact is low — an attacker may gain access to data they should not see if a filtering clause is dropped — and integrity impact is low, as unauthorized data modifications could occur if a restricting clause is removed. Availability is not impacted. Exploitation is constrained to scenarios where the application accepts and retains attacker-controlled strings of at least 4 GiB, which most web frameworks and servers reject at the request body level before the application processes them (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for this vulnerability. The EPSS score is 0.0, and it is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to deliver a single string of at least 4 GiB to the application, which must accept, retain, and pass it to sqlite3-ruby without prior size validation — a condition that most production deployments (with request body size limits) would prevent. No threat actor attribution has been identified (GitHub Advisory, Feedly).

1. Identify a target: Find a Ruby application using the sqlite3 gem (versions < 2.10.2) on a 64-bit platform that accepts large, attacker-controlled input and passes it directly or interpolated into SQL queries without enforcing a request body size limit below 4 GiB.
2. Craft an oversized payload: Construct a string of at least 4 GiB (2^32 bytes). For example, a string of NUL bytes can be allocated cheaply with "\0" * (2**32) in Ruby, but the attacker must transmit this to the server.
3. Inject into a SQL-bearing parameter: Submit the oversized string as a parameter that the application interpolates directly into a SQL query (e.g., a search field or user-supplied SQL fragment) rather than as a bound parameter, so the string becomes part of the SQL passed to Database#prepare or #execute.
4. Trigger integer wraparound: The C extension casts the string length from long to int, causing wraparound. SQLite receives a truncated length and processes only the prefix of the SQL string, dropping any trailing clauses (e.g., WHERE user_id = ?).
5. Achieve unauthorized access: With the WHERE clause dropped, the query runs without its intended filter, potentially returning all rows or performing an unfiltered write, bypassing authentication or authorization logic (GitHub Advisory, GitHub PR #762).

• Logs: Application logs showing unusually large request bodies (approaching or exceeding several GiB) submitted to endpoints that interact with the database; SQLite3::RangeError exceptions in application logs (post-patch) indicating attempted exploitation against a patched system.
• Network: Extremely large HTTP request bodies (≥4 GiB) sent to the application server; anomalous upload traffic volume from a single source IP.
• Application Behavior: Unexpected query results returning unfiltered data sets (e.g., all users instead of a single user); authentication bypasses or access control failures not explained by application logic errors.

Upgrade the sqlite3 RubyGem to version 2.10.2 or later, which replaces the unsafe (int)RSTRING_LEN(...) cast with RSTRING_LENINT(...) and raises a RangeError for strings exceeding INT_MAX bytes. As a workaround for deployments that cannot immediately upgrade, enforce request body size limits well below 4 GiB at the web server or application framework level (e.g., via client_max_body_size in Nginx or equivalent), and add explicit application-level validation to reject SQL strings and bound values of 4 GiB or larger before passing them to sqlite3-ruby (GitHub Advisory, Release v2.10.2).

The vulnerability was responsibly reported by Luke Jahnke from security research firm elttam and disclosed by the sqlite3-ruby maintainer (flavorjones/Mike Dalessio) via a GitHub Security Advisory. The maintainers assessed the severity as moderate (CVSS 4.8), noting that practical exploitation is constrained by the requirement to transmit a ≥4 GiB string. No significant broader media coverage or notable community controversy has been identified (GitHub Advisory).