CVE-2026-54620: 
Ruby Analyse et atténuation des vulnérabilités

CVE-2026-54620 is a use-after-free vulnerability in the sqlite3 Ruby gem (sparklemotion/sqlite3-ruby) affecting versions 2.1.0 through 2.9.4. The flaw causes aggregate function callbacks to be freed by Ruby's garbage collector while still referenced during aggregation, resulting in an invalid memory read and segmentation fault when a prepared statement is stepped after the database has been explicitly closed. It was disclosed on June 7, 2026, and patched in version 2.9.5. The CVSS v4.0 base score is 2.0 (Low) (GitHub Advisory).

The root cause is CWE-416 (Use After Free): when Database#create_aggregate, #create_aggregate_handler, or #define_aggregator is used to register a custom aggregate function, the internal -aggregators instance variable was cleared (set to nil) upon Database#close or Database#discard. This allowed Ruby's GC to collect the callback objects while a prepared statement still held a reference to them via SQLite's internal structures. If stmt.step is subsequently called on such a statement, SQLite invokes the freed callback, causing an invalid memory read and segmentation fault. The fix (PR #711, commit b24e1e6) stops clearing -aggregators on close/discard, ensuring callbacks are retained for the database object's lifetime (GitHub PR #711, GitHub Advisory).

Successful triggering of this vulnerability results in a segmentation fault, causing the Ruby process to crash and producing a denial-of-service condition for the affected application. The impact is limited to availability; there is no known path to arbitrary code execution, data exfiltration, or privilege escalation from this bug. The maintainers note there is no known general exploit usable as a denial-of-service attack, and exploitation requires a specific code pattern combined with GC timing (GitHub Advisory, Ruby Advisory DB).

1. Identify target: Locate a Ruby application using the sqlite3 gem (versions 2.1.0–2.9.4) that defines custom aggregate functions via Database#create_aggregate, #create_aggregate_handler, or #define_aggregator.
2. Prepare a statement: Ensure the application prepares a SQL statement that invokes the custom aggregate function (e.g., db.prepare("SELECT accumulate(col) FROM table")).
3. Trigger database close: Cause the application to explicitly close the database object (e.g., db.close) while the prepared statement remains open and unreleased.
4. Force garbage collection: Trigger Ruby's GC (e.g., GC.start(full_mark: true, immediate_sweep: true)) to free the now-unreferenced aggregate callback objects.
5. Step the statement: Call stmt.step on the still-open prepared statement, causing SQLite to invoke the freed callback, resulting in an invalid memory read and segmentation fault (process crash) (GitHub Advisory, GitHub PR #711).

• Process: Ruby process terminating unexpectedly with a segmentation fault (SIGSEGV) signal, particularly in applications using SQLite aggregate functions.
• Logs: Application crash logs or core dumps referencing SQLite-related stack frames (e.g., sqlite3_step, aggregate callback invocation) after a database close operation.
• Application Behavior: Unexpected process restarts or crashes in Ruby applications that use sqlite3 gem versions 2.1.0–2.9.4 with custom aggregate functions defined via create_aggregate, create_aggregate_handler, or define_aggregator (GitHub Advisory).

Upgrade the sqlite3 Ruby gem to version 2.9.5 or later, which resolves the issue by retaining aggregate callback references for the full lifetime of the database object (GitHub Release v2.9.5). As a workaround for those unable to upgrade immediately, avoid using any prepared statement that calls an aggregate function after the associated database has been explicitly closed. Ensure that all statements are finalized before closing the database (GitHub Advisory).

The sqlite3-ruby maintainer (flavorjones/Mike Dalessio) assessed the severity as Low and noted there is no known general exploit usable as a denial-of-service attack. The fix was developed and merged promptly on the same day as disclosure (June 7, 2026). No significant broader media coverage or notable external researcher commentary has been identified beyond the official advisory and standard vulnerability database aggregators (GitHub Advisory).