CVE-2021-22880: Ruby on Rails PostgreSQL Adapter DoS Flaw

CVE-2021-22880 Overview

The PostgreSQL adapter in Active Record before versions 6.1.2.1, 6.0.3.5, and 5.2.4.5 contains a Regular Expression Denial of Service (ReDoS) vulnerability. Carefully crafted input can cause the input validation in the money type of the PostgreSQL adapter to spend excessive time in regular expression processing, resulting in the potential for a Denial of Service (DoS) attack. This vulnerability specifically impacts Rails applications using PostgreSQL with money type columns that accept user input.

Critical Impact

Attackers can exploit this ReDoS vulnerability to cause application unavailability by submitting specially crafted input to money type columns, potentially leading to service degradation or complete denial of service for affected Rails applications.

Affected Products

• Ruby on Rails versions before 6.1.2.1
• Ruby on Rails versions before 6.0.3.5
• Ruby on Rails versions before 5.2.4.5
• Fedora 32 and 33

Discovery Timeline

• 2021-02-11 - CVE-2021-22880 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-22880

Vulnerability Analysis

This vulnerability is classified as a Regular Expression Denial of Service (ReDoS) attack, categorized under CWE-400 (Uncontrolled Resource Consumption). The flaw resides within the Active Record component of Ruby on Rails, specifically in the PostgreSQL adapter's handling of money type columns.

When user-supplied input is processed through the money type validation, the underlying regular expression exhibits catastrophic backtracking behavior when encountering maliciously crafted strings. This algorithmic complexity attack exploits the exponential time complexity inherent in poorly constructed regular expressions, causing the application to consume excessive CPU resources during pattern matching operations.

The vulnerability requires network access and can be exploited without authentication or user interaction, making it particularly concerning for publicly accessible Rails applications. The attack exclusively affects availability, as successful exploitation does not result in unauthorized data access or modification.

Root Cause

The root cause of this vulnerability lies in the inefficient regular expression pattern used for validating monetary input values in the PostgreSQL adapter. The regex pattern contains nested quantifiers or overlapping alternations that create exponential backtracking scenarios when processing adversarial input strings.

When the regex engine encounters input that partially matches multiple branches of the pattern, it must exhaustively explore all possible matching combinations before determining a final result. Attackers can craft input strings that maximize this backtracking behavior, effectively creating an algorithmic complexity attack against the validation logic.

Attack Vector

The attack vector for CVE-2021-22880 is network-based, requiring the attacker to submit malicious input to a Rails application endpoint that processes money type columns. The attack flow involves:

1. The attacker identifies a Rails application using PostgreSQL with money type columns that accept user input
2. A specially crafted string is submitted through forms, API endpoints, or other input mechanisms
3. The Active Record PostgreSQL adapter attempts to validate the input using the vulnerable regex pattern
4. The regex engine enters catastrophic backtracking, consuming CPU resources
5. Application threads become blocked, potentially causing service unavailability

The vulnerability mechanism exploits inefficient regular expression processing in the money type validation. When the regex engine encounters a maliciously crafted input string, it enters a catastrophic backtracking state where it exponentially evaluates possible pattern matches. This results in CPU exhaustion as the server spends excessive time attempting to complete the pattern matching operation. For detailed technical analysis, refer to the Rails Discussion on CVE-2021-22880 and the HackerOne Report #1023899.

Detection Methods for CVE-2021-22880

Indicators of Compromise

• Unusual CPU spikes on application servers processing PostgreSQL money type inputs
• Extended request processing times for endpoints handling monetary data
• Application log entries showing timeout errors or thread pool exhaustion
• Abnormally long-running database queries involving money columns

Detection Strategies

• Monitor application performance metrics for sudden increases in request processing time
• Implement request timeout thresholds to terminate long-running input validation operations
• Review application logs for patterns of repeated requests to money-type endpoints
• Use Web Application Firewall (WAF) rules to detect and block potential ReDoS payloads

Monitoring Recommendations

• Configure alerting for CPU utilization exceeding baseline thresholds on Rails application servers
• Implement distributed tracing to identify slow request patterns targeting specific endpoints
• Deploy application performance monitoring (APM) tools to track regex processing times
• Establish baseline metrics for normal money type validation processing times

How to Mitigate CVE-2021-22880

Immediate Actions Required

• Upgrade Ruby on Rails to version 6.1.2.1, 6.0.3.5, or 5.2.4.5 or later
• Audit application code to identify all endpoints accepting money type input
• Implement input length restrictions on money type columns to limit ReDoS impact
• Consider implementing request timeouts as a temporary protective measure

Patch Information

Ruby on Rails has released patched versions addressing this vulnerability. Organizations should upgrade to the following minimum versions:

• Rails 6.1.x: Upgrade to 6.1.2.1 or later
• Rails 6.0.x: Upgrade to 6.0.3.5 or later
• Rails 5.2.x: Upgrade to 5.2.4.5 or later

Additional security advisories have been issued by downstream distributions including Debian Security Advisory DSA-4929, Fedora, and NetApp Security Advisory NTAP-20210805-0009.

Workarounds

• Implement strict input validation before data reaches the Active Record layer
• Set maximum input length limits for money type fields at the application level
• Use input sanitization to strip potentially malicious characters from monetary input
• Configure web server or reverse proxy request timeouts to prevent extended processing

# Configuration example - Nginx request timeout
location /api/payments {
    proxy_read_timeout 5s;
    proxy_connect_timeout 5s;
    proxy_send_timeout 5s;
}