High, CVSS 8.1RubyGemsPublished
ERB has an @_init deserialization guard bypass via def_module / def_method / def_class
CVE-2026-41316 · GHSA-q339-8rmv-2mhv
- Affected
- RubyGems erb < 4.0.3.1; >= 4.0.4, <= 4.0.4; >= 5.0.0, < 6.0.1.1; >= 6.0.2, < 6.0.4
- Fixed in
- 4.0.3.16.0.1.14.0.4.16.0.4· Vendor fix available
- Issue
- Ruby 2.7.0 (before ERB 2.2.0 was published on rubygems.org) introduced an @init instance variable guard in ERB#result and ERB#run to prevent code execution when an ERB object is reconstructed via Marshal.load (deserialization). However, three other public methods that also evaluate @src via eval() were not given the same guard: - ERB#defmethod - ERB#defmodule - ERB#defclass An attacker who can trigger Marshal.load on untrusted data in a Ruby application that has erb loaded can use ERB#defmodule (zero-arg, default parameters) as a code execution sink, bypassing the @init protection entirely. <details The @init Guard In ERB#initialize, the guard is set: In ERB#result and ERB#run, the guard is checked before eval(@src): When an ERB object is reconstructed via Marshal.load, @init is either nil (not set during marshal reconstruction) or an attacker-controlled value. Since ERB.singletonclass cannot be marshaled, the attacker cannot set @init to the correct value, and result/run…
Recommended action: Upgrade to 6.0.4, 6.0.1.1, 4.0.4.1 or 4.0.3.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.