GHSA-579w-22j4-4749 CVE-2022-44566

Denial of Service Vulnerability in ActiveRecord's PostgreSQL adapter

High RubyGems

Severity: 7.5 / 10; High · CVSS 3.1
Exploit chance (EPSS): 1.26%; Chance of exploitation in the next 30 days. Higher than 69.73% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-400 Uncontrolled Resource Consumption
Fix: 6.1.7.1; Upgrade activerecord to this version or later

Description

There is a potential denial of service vulnerability present in ActiveRecord's PostgreSQL adapter.

This has been assigned the CVE identifier CVE-2022-44566.

Versions Affected: All. Not affected: None.

Fixed Versions

2.3.18.47 (Rails LTS, which is a paid service and not part of the rubygem)
3.2.22.34 (Rails LTS, which is a paid service and not part of the rubygem)
4.2.11.27 (Rails LTS, which is a paid service and not part of the rubygem)
5.2.8.15 (Rails LTS, which is a paid service and not part of the rubygem)
6.1.7.1
7.0.4.1

Impact

In ActiveRecord < 7.0.4.1 and < 6.1.7.1, when a value outside the range for a 64bit signed integer is provided to the PostgreSQL connection adapter, it will treat the target column type as numeric. Comparing integer values against numeric values can result in a slow sequential scan resulting in potential Denial of Service.

Releases

The fixed releases are available at the normal locations.

Workarounds

Ensure that user supplied input which is provided to ActiveRecord clauses do not contain integers wider than a signed 64bit representation or floats.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for the supported release series in accordance with our maintenance policy 1 regarding security issues. They are in git-am format and consist of a single changeset.

6-1-Added-integer-width-check-to-PostgreSQL-Quoting.patch - Patch for 6.1 series 7-0-Added-integer-width-check-to-PostgreSQL-Quoting.patch - Patch for 7.0 series

Affected versions

RubyGems

Package	Vulnerable	Fixed in
activerecord	`< 6.1.7.1`	`6.1.7.1`
activerecord	`>= 7.0.0, < 7.0.4.1`	`7.0.4.1`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

activerecord RubyGems → `6.1.7.1`

bundler

bundle update activerecord # Gemfile: gem "activerecord", ">= 6.1.7.1"

Severity breakdown

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: None
Integrity: None
Availability: High

Weakness

CWE-400: Uncontrolled Resource Consumption

The product does not properly control the allocation and maintenance of a limited resource.

How to prevent it

Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
Implementation: Ensure that all failures in resource allocation place the system into a safe posture.

References

Advisories

nvd.nist.gov/vuln/detail/CVE-2022-44566

Packages

github.com/rails/rails

Timeline

Jan 18, 2023 Published
Feb 3, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-76r7-hhxj-r776 Active Record logging vulnerable to ANSI escape injection	Medium	Also affects activerecord
GHSA-hq7p-j377-6v63 SQL Injection Vulnerability via ActiveRecord comments	High	Also affects activerecord
GHSA-3hhc-qp5v-9p2j Active Record RCE bug with Serialized Columns	Critical	Also affects activerecord
GHSA-f57c-hx33-hvh8 Active Record component in Ruby on Rails has a data-type injection vulnerability	Critical	Also affects activerecord
GHSA-8hc4-xxm3-5ppp Active Record subject to Regular Expression Denial-of-Service (ReDoS)	High	Also affects activerecord
GHSA-xf96-32q2-9rw2 Rails ActiveRecord gem vulnerable to SQL injection	High	Also affects activerecord
GHSA-jmm9-2p29-vh2w activerecord vulnerable to SQL Injection	High	Also affects activerecord
GHSA-h6w6-xmqv-7q78 activerecord vulnerable to SQL Injection	High	Also affects activerecord

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor