CVE-2026-41316: Ruby ERB Templating RCE Vulnerability

CVE-2026-41316 Overview

CVE-2026-41316 is an insecure deserialization vulnerability in the ERB (Embedded Ruby) templating system for Ruby. The vulnerability allows remote code execution when an attacker can trigger Marshal.load on untrusted data in a Ruby application that has the erb library loaded. While Ruby 2.7.0 introduced an @_init instance variable guard in ERB#result and ERB#run methods to prevent code execution when an ERB object is reconstructed via deserialization, three additional public methods that evaluate @src via eval() were left unprotected: ERB#def_method, ERB#def_module, and ERB#def_class.

Critical Impact

Attackers who can control data passed to Marshal.load in applications using ERB can achieve remote code execution by exploiting unprotected methods, completely bypassing the existing @_init security guard.

Affected Products

• Ruby ERB versions prior to 4.0.3.1
• Ruby ERB versions 4.0.4.x prior to 4.0.4.1
• Ruby ERB versions 6.0.x prior to 6.0.1.1 and 6.0.4

Discovery Timeline

• 2026-04-24 - CVE-2026-41316 published to NVD
• 2026-04-29 - Last updated in NVD database

Technical Details for CVE-2026-41316

Vulnerability Analysis

This vulnerability falls under the category of Insecure Deserialization (CWE-693: Protection Mechanism Failure). The core issue stems from an incomplete security mitigation implemented in Ruby 2.7.0. When the Ruby security team introduced the @_init guard to protect against deserialization attacks targeting ERB objects, they only applied this protection to the ERB#result and ERB#run methods.

However, the ERB class exposes three additional public methods—ERB#def_method, ERB#def_module, and ERB#def_class—that also evaluate the @src instance variable using Ruby's eval() function. These methods were not given the same @_init guard protection.

The ERB#def_module method is particularly dangerous as it accepts zero arguments with default parameters, making it trivial to exploit. An attacker can craft a malicious serialized ERB object with arbitrary code in the @src variable, and when the application deserializes this object and any of the unprotected methods are called, the malicious code executes in the context of the application.

Root Cause

The root cause is a Protection Mechanism Failure where security controls were applied inconsistently across methods that share the same dangerous behavior—evaluating user-controllable data via eval(). The @_init guard was only applied to ERB#result and ERB#run, while ERB#def_method, ERB#def_module, and ERB#def_class remained unprotected, creating an exploitable bypass path.

Attack Vector

The attack requires network access and targets applications that deserialize untrusted data using Marshal.load while having the erb library loaded. The attack flow involves:

1. An attacker crafts a malicious serialized Ruby object containing an ERB instance with arbitrary code in the @src instance variable
2. The attacker delivers this serialized payload to a vulnerable application endpoint that processes untrusted data with Marshal.load
3. Upon deserialization, the attacker triggers one of the unprotected methods (typically ERB#def_module due to its zero-argument signature)
4. The eval() call executes the attacker-controlled code, achieving remote code execution

The vulnerability mechanism exploits the inconsistent application of the @_init security guard. When a malicious ERB object is deserialized via Marshal.load, the @_init variable is not set, but since ERB#def_module and related methods do not check this guard, they proceed to evaluate the malicious @src content regardless. For detailed technical information, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-41316

Indicators of Compromise

• Unexpected calls to Marshal.load with external or untrusted data sources in Ruby applications
• Application logs showing ERB instantiation without corresponding template rendering activity
• Suspicious process spawning or network connections originating from Ruby application contexts
• Error messages or exceptions related to ERB method invocations in unexpected code paths

Detection Strategies

• Monitor for calls to Marshal.load, Marshal.restore, or similar deserialization functions with untrusted input sources
• Implement application-level logging to track ERB object instantiation and method calls, particularly def_method, def_module, and def_class
• Deploy runtime application self-protection (RASP) solutions capable of detecting deserialization attacks in Ruby environments
• Use static analysis tools to identify code paths where user-controlled data may reach deserialization functions

Monitoring Recommendations

• Enable verbose logging for Ruby applications processing external data to capture potential exploitation attempts
• Configure alerting on anomalous ERB-related method invocations, especially in contexts not involving template rendering
• Monitor system calls and process activity from Ruby application processes for signs of post-exploitation behavior
• Implement network egress monitoring to detect potential data exfiltration or command-and-control communication

How to Mitigate CVE-2026-41316

Immediate Actions Required

• Upgrade ERB to patched versions: 4.0.3.1, 4.0.4.1, 6.0.1.1, or 6.0.4 immediately
• Audit application code for any use of Marshal.load with untrusted or external data sources
• Implement input validation and restrict deserialization to trusted data sources only
• Consider using safer serialization formats like JSON where object reconstruction capabilities are not required

Patch Information

The Ruby ERB maintainers have released patched versions that extend the @_init guard protection to all methods that evaluate @src via eval(). The following versions contain the fix:

• ERB 4.0.3.1
• ERB 4.0.4.1
• ERB 6.0.1.1
• ERB 6.0.4

Review the GitHub Security Advisory for complete details on the patch and affected versions.

Workarounds

• Avoid using Marshal.load with untrusted data; use JSON.parse or other safe alternatives for external data
• Implement allow-listing of permitted classes for deserialization using Marshal.load(data, permitted_classes: [...])
• Add application-level guards to prevent ERB instantiation from deserialized objects in sensitive code paths
• Isolate components that must process untrusted serialized data in sandboxed environments with limited privileges

If upgrading is not immediately possible, organizations should implement strict input validation and consider wrapping Marshal.load calls with additional security checks. The safest approach is to avoid deserializing untrusted data entirely and migrate to safer serialization formats.