CVE-2020-8165: Ruby on Rails RCE Vulnerability

CVE-2020-8165 Overview

CVE-2020-8165 is a critical insecure deserialization vulnerability affecting Ruby on Rails applications that use MemCacheStore or RedisCacheStore for caching. The vulnerability allows attackers to unmarshal user-provided objects, potentially resulting in Remote Code Execution (RCE) on vulnerable systems.

This vulnerability exists in Rails versions prior to 5.2.4.3 and 6.0.3.1. When applications store user-controlled data in cache stores that use Ruby's Marshal serialization without proper validation, attackers can craft malicious serialized payloads that execute arbitrary code when deserialized by the application.

Critical Impact

Successful exploitation enables remote attackers to achieve arbitrary code execution on Rails applications using MemCacheStore or RedisCacheStore, potentially leading to complete system compromise.

Affected Products

• Ruby on Rails versions prior to 5.2.4.3
• Ruby on Rails versions prior to 6.0.3.1
• Debian Linux 8.0, 9.0, and 10.0
• openSUSE Leap 15.1 and 15.2

Discovery Timeline

• May 18, 2020 - Ruby on Rails releases security patches (versions 5.2.4.3 and 6.0.3.1)
• June 19, 2020 - CVE-2020-8165 published to NVD
• May 9, 2025 - Last updated in NVD database

Technical Details for CVE-2020-8165

Vulnerability Analysis

The vulnerability stems from Ruby on Rails' handling of cached data in MemCacheStore and RedisCacheStore. These cache stores use Ruby's Marshal.load() method to deserialize cached objects. When applications cache user-controllable data using the raw: true option or when the cached value is directly influenced by user input, attackers can inject malicious serialized Ruby objects.

Ruby's Marshal deserialization is inherently unsafe when processing untrusted data because it can instantiate arbitrary Ruby objects and invoke methods during the deserialization process. Attackers can leverage gadget chains within Ruby and Rails to construct payloads that execute arbitrary commands when unmarshaled.

The vulnerability is particularly dangerous because cache stores are commonly used to store session data, user preferences, and other application state that may be influenced by external input. Applications that don't properly sanitize data before caching or that use raw cache storage are susceptible to this attack.

Root Cause

The root cause is CWE-502: Deserialization of Untrusted Data. Rails' cache stores relied on Ruby's Marshal serialization format, which is capable of serializing and deserializing arbitrary Ruby objects including those with dangerous side effects. The framework did not adequately protect against unmarshaling attacker-controlled data, allowing crafted payloads to execute code during deserialization.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Identifying a Rails application that caches user-controllable data using MemCacheStore or RedisCacheStore
2. Crafting a malicious serialized Ruby object using known gadget chains
3. Submitting the payload through an input vector that results in the data being cached
4. Triggering the cache read operation, which deserializes the malicious object
5. Achieving arbitrary code execution on the server

The vulnerability allows attackers to bypass normal application logic entirely by targeting the serialization layer. This attack is particularly effective because it operates at a lower level than typical input validation mechanisms.

Detection Methods for CVE-2020-8165

Indicators of Compromise

• Unusual cache operations involving serialized Ruby objects with unexpected class hierarchies
• Error logs showing Marshal.load failures or unexpected object instantiation
• Network traffic containing Base64-encoded or binary data patterns consistent with Marshal serialization
• Unexpected process spawning or command execution originating from Rails worker processes
• Memory anomalies or crashes in Rails application processes

Detection Strategies

• Monitor application logs for deserialization errors and unexpected Ruby class instantiation
• Implement runtime application self-protection (RASP) to detect and block suspicious deserialization attempts
• Deploy web application firewalls (WAF) configured to detect serialized Ruby object patterns in HTTP requests
• Use intrusion detection systems (IDS) to monitor for known Ruby deserialization exploit patterns

Monitoring Recommendations

• Enable verbose logging for cache operations in staging and production environments
• Set up alerts for unusual patterns in Memcached or Redis traffic
• Monitor for process execution anomalies on application servers
• Implement file integrity monitoring on critical system directories

How to Mitigate CVE-2020-8165

Immediate Actions Required

• Upgrade Ruby on Rails to version 5.2.4.3 or 6.0.3.1 (or later) immediately
• Audit application code for patterns that cache user-controllable data
• Review cache usage to identify potential exposure points
• Consider temporarily disabling caching functionality if immediate patching is not possible

Patch Information

Ruby on Rails has released patched versions that address this vulnerability. The fix ensures that user-provided data cannot be used to inject malicious serialized objects. Upgrade to the following versions:

• Rails 5.2.x: Upgrade to version 5.2.4.3 or later
• Rails 6.0.x: Upgrade to version 6.0.3.1 or later

For detailed patch information, refer to the Ruby on Rails Release Announcement and the Ruby on Rails Security Alert. The original vulnerability report is documented in HackerOne Report #413388.

Linux distribution users should apply security updates from their package managers:

• Debian users should refer to the Debian Security Advisory DSA-4766
• openSUSE users should apply updates per the openSUSE Security Announcements

Workarounds

• Avoid caching user-controllable data directly in MemCacheStore or RedisCacheStore
• Use safer serialization formats like JSON instead of Marshal for cached data when possible
• Implement strict input validation before any data is cached
• Consider using Rails' encrypted cache stores with authenticated encryption
• Apply network segmentation to isolate cache servers from untrusted networks

# Configuration example
# Gemfile - Update Rails version
gem 'rails', '>= 5.2.4.3'
# or for Rails 6.x
gem 'rails', '>= 6.0.3.1'

# Run bundle update to apply the upgrade
bundle update rails

# Restart application servers after upgrade
systemctl restart puma
# or
systemctl restart passenger