Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Using Database#createaggregate, #createaggregatehandler, or Database#defineaggregator to define an aggregate function that takes two or more arguments, and then evaluating it over TEXT or BLOB column values, can free the Ruby objects holding those arguments while a later argument is still being converted, during ordinary garbage collection. The aggregate's step method then receives an incorrect object, or the process crashes with a segmentation fault. Mitigation Upgrade to sqlite3 gem v2.9.6 or later. There is no reliable workaround. If you cannot upgrade, avoid defining aggregate functions that take two or more arguments. Restricting column value sizes is not a mitigation: smaller values make the defect fire less often but do not prevent it. Severity The sqlite3-ruby maintainers assess this as Medium severity (CVSS 4.0 score 6.3). It is reached through ordinary garbage collection without any unusual code structuring: an application is exposed whenever it evaluates a…
Recommended action: Upgrade to 2.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Using Database#createaggregate, #createaggregatehandler, or Database#defineaggregator to define an aggregate function, and then using an open statement calling that function after the database has been explicitly closed will result in an invalid memory read and a segmentation fault. Mitigation Upgrade to sqlite3 gem v2.9.5 or later. As a workaround, avoid using an aggregate function after closing the database. Severity The sqlite3-ruby maintainers assess this as Low severity. It is reliably triggered after GC when code is structured in a particular way. There is no known general exploit that could be used as a denial of service attack.
Recommended action: Upgrade to 2.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Using Database#createfunction or Database#definefunction to define the same function name more than once with different numbers of arguments ("arity") or text encodings will result in a invalid memory read and a segmentation fault. Mitigation Upgrade to sqlite3 gem v2.9.5 or later. As a workaround, avoid defining multiple custom functions with the same name (varying numbers of arguments or encoding). Severity The sqlite3-ruby maintainers assess this as Low severity. It is reliably triggered after GC when code is structured in a particular way. There is no known general exploit that could be used as a denial of service attack.
Recommended action: Upgrade to 2.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The rubygem sqlite3 v1.5.1 upgrades the packaged version of libsqlite from v3.39.3 to v3.39.4. libsqlite v3.39.4 addresses a vulnerability described as follows in the release notification: Version 3.39.4 is a minimal patch against the prior release that addresses issues found since the prior release. In particular, a potential vulnerability in the FTS3 extension has been fixed, so this should be considered a security update. In order to exploit the vulnerability, an attacker must have full SQL access and must be able to construct a corrupt database with over 2GB of FTS3 content. The problem arises from a 32-bit signed integer overflow. This vulnerability has not been assigned a CVE and does not have a severity declared. Please note that this advisory only applies to the sqlite3 gem v1.5.0, and only if the packaged libsqlite is being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention…
Recommended action: Upgrade to 1.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.