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

CVE-2026-54619 is a use-after-free vulnerability in the sqlite3 Ruby gem (sqlite3-ruby) that occurs when redefining a SQLite custom function with the same name but a different arity or text encoding. Affected versions are 2.1.0 through 2.9.4 (inclusive); versions prior to 2.1.0 are unaffected. The vulnerability was discovered and disclosed on June 7, 2026, with the fix released the same day in version 2.9.5. It carries a CVSS v4.0 base score of 2.0 (Low), assessed as Low severity by the maintainers (GitHub Advisory, Ruby Advisory DB).

The root cause (CWE-416: Use After Free) lies in how the @functions instance variable was managed in ext/sqlite3/database.c and lib/sqlite3/database.rb. Previously, @functions was a Ruby Hash keyed by function name; when Database#create_function or Database#define_function was called a second time with the same name but a different arity, the old Ruby Proc (block) was overwritten in the hash and became eligible for garbage collection, while SQLite's internal state still held a pointer to the freed handler. After a GC cycle, SQLite's subsequent invocation of the freed function handler results in an invalid memory read and a segmentation fault. The fix changes @functions from a Hash to an Array, appending all registered blocks so they remain referenced for the lifetime of the database object, preventing premature GC collection (GitHub Advisory, Fix PR #710, Fix Commit).

Successful triggering of this vulnerability causes an invalid memory read and segmentation fault in the Ruby process hosting the SQLite3 database, resulting in a process crash. The primary impact is on availability (process termination), with low-level confidentiality and integrity impacts possible due to the nature of use-after-free memory corruption. The vulnerability is reliably triggered only after a GC cycle when code is structured in a specific way (redefining a function with a different arity), and the maintainers note there is no known general exploit that could be weaponized as a denial-of-service attack (GitHub Advisory).

1. Precondition: Attacker must have the ability to influence Ruby application code that uses the sqlite3 gem (version ≤ 2.9.4) and calls Database#create_function or Database#define_function.
2. Trigger function redefinition: Call db.define_function("f") { |a| "orig" } to register a custom SQLite function named f with arity 1, storing the Proc in the @functions hash under the key "f".
3. Redefine with different arity: Call db.define_function("f") { |a, b| "new" } to overwrite the hash entry for "f", making the original Proc unreachable from Ruby's object graph.
4. Force garbage collection: Trigger a GC cycle (e.g., GC.start(full_mark: true, immediate_sweep: true)), which frees the memory of the original Proc block while SQLite still holds an internal reference to it.
5. Invoke the freed function: Execute a SQL query that calls the function (e.g., db.execute("select f(1)")), causing SQLite to invoke the freed handler, resulting in an invalid memory read and segmentation fault (Fix PR #710, GitHub Advisory).

• Process: Unexpected segmentation fault (SIGSEGV) or crash of a Ruby process using the sqlite3 gem, particularly after garbage collection cycles in applications that define custom SQLite functions.
• Logs: Ruby crash logs or core dumps referencing sqlite3 native extension code (e.g., ext/sqlite3/database.c) around the define_function_with_flags function.
• Application Behavior: Unexplained process restarts or crashes in Ruby applications (e.g., Rails apps using SQLite) that define custom database functions with the same name but varying argument counts.

Upgrade the sqlite3 Ruby gem to version 2.9.5 or later, which resolves the issue by retaining all registered function blocks for the lifetime of the database object. As a workaround for those unable to upgrade immediately, avoid defining multiple custom SQLite functions with the same name using different numbers of arguments or text encodings. The fix was released on June 7, 2026 (GitHub Release v2.9.5, GitHub Advisory).

The vulnerability was reported by researcher cla7aye15I4nd and addressed promptly by maintainer flavorjones (Mike Dalessio) on the same day as disclosure (June 7, 2026). The sqlite3-ruby maintainers publicly assessed the severity as Low, noting there is no known general exploit usable as a denial-of-service attack. No significant broader media coverage or notable community controversy has been observed (GitHub Advisory).