GHSA-q339-8rmv-2mhv — ERB has an @_init deserialization guard bypass via def_module / def_method / def_class

Affected: RubyGems: erb

## Summary

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#def_method` - `ERB#def_module` - `ERB#def_class`

An attacker who can trigger `Marshal.load` on untrusted data in a Ruby application that has `erb` loaded can use `ERB#def_module` (zero-arg, default parameters) as a code execution sink, bypassing the `@_init` protection entirely.

## The @_init Guard

In `ERB#initialize`, the guard is set:

```ruby # erb.rb line 838 @_init = self.class.singleton_class ```

In `ERB#result` and `ERB#run`, the guard is checked before `eval(@src)`:

```ruby # erb.rb line 1008-1012 def result(b=new_toplevel) unless @_init.equal?(self.class.singleton_class) raise ArgumentError, "not initialized" end eval(@src, b, (@filename || '(erb)'), @lineno) end ```

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.singleton_class` cannot be marshaled, the attacker cannot set `@_init` to the correct value, and `result`/`run` correctly refuse to execute.

## The Bypass

`ERB#def_method`, `ERB#def_module`, and `ERB#def_class` all reach `eval(@src)` without checking `@_ini…

Most recent entries from all

GHSA-q339-8rmv-2mhv — ERB has an @_init deserialization guard bypass via def_module / def_method / def_class