Harish Kumar 
A fresh universal exploit chain shows that Ruby’s latest release, version 4.0.6, can still be turned into full command execution from nothing more than one call to Marshal.load. Security firm elttam disclosed the technique on August 14, 2026, and it reportedly works unmodified as far back as Ruby 3.3.
The timing isn’t accidental. On August 5, 2026, OpenAI revealed at Black Hat USA that a group of autonomous AI agents under internal evaluation broke out of their sandbox and seized administrative control of the infrastructure that hosted them, in part by exploiting Ruby deserialization in a JRuby-based package registry cache proxy.
That incident reportedly involved a crafted request that got a malicious Ruby object cached as dependency data, followed by a RubyGems API call that triggered a time-of-check-to-time-of-use flaw during deserialization.
Ruby 4.0 Deserialization Flaw
elttam says that disclosure is exactly what pushed the firm back into Ruby deserialization research, since the last publicly known universal chain, released in November 2024, only worked against a 3.4 release candidate and was patched before Ruby 3.4.0 shipped.
Ruby’s Marshal.load deserialization problem isn’t new. It traces back to a 2013 bug report and Rails exploitation research, through elttam’s own 2018 “universal” chain for Ruby 2.x, past multiple YAML-based variants, and into RubyGems-specific gadgets.
Each time a chain surfaced, Ruby or RubyGems maintainers patched the specific gadgets involved, and each time, new gadgets took their place. Trail of Bits documented this cycle in an August 2025 retrospective, arguing that “the pattern is clear: researchers find new gadget chains, Ruby core patches them, and within months someone discovers a bypass” .
The 2024 chain relied on a Gem::Version#marshal_load gadget and an executable-name gadget tied to Gem::Source::Git.
Ten days after that research was published, RubyGems maintainers shipped two commits: one tightening type checking in marshal_load methods, the other removing stored executable names from instance variables, explicitly citing the writeup as their motivation. Both landed in Ruby 3.4.0.
But a URL-fetching, folder-creating gadget from that same chain was left untouched, because it wasn’t flagged as the dangerous part at the time.
elttam’s new work repurposes that surviving gadget for a different job: downloading attacker-hosted, deflated Ruby source and writing it to a predictable filesystem path via directory traversal, rather than merely creating a folder.
To get the download triggered without a fragile “polyglot” payload, researchers turned to Ruby’s own C-level Time._load implementation, which wraps zone-name validation in rb_rescue and silently discards exceptions a behavior no maintainer can patch away with a five-line diff, since doing so would change how Time deserialization tolerates malformed input.
From there, Gem::URI::Generic#to_s bridges into the download gadget, Gem::StubSpecification‘s hash method (invoked automatically whenever Marshal reconstructs a Hash key) triggers the whole sequence, and Gem::Specification.load finally hands the downloaded file straight to eval, achieving code execution.
Trail of Bits has already argued for deprecating Marshal outright, recommending Marshal.safe_load, runtime warnings, and an eventual phase-out, since “no amount of patching individual gadget chains will ever solve this”.
elttam’s latest research reinforces that conclusion by reaching into core C behavior below Ruby-level gadgets that the language realistically cannot change.
Independent coverage confirms the chain needs no non-default gems, no application code, and no pre-existing files only a reachable HTTPS host and a writable directory.
For teams still calling Marshal.load on anything that touches untrusted input, the advice hasn’t changed in over a decade: stop. Switch to a data-only serialization format like JSON, and treat any remaining Marshal usage as an active remote-code-execution risk on every currently supported Ruby version.
Site: Thecyberdef.com
Follow TheCyberDef on Google News, LinkedIn & X for the latest cybersecurity updates. Stay informed.
About the Author
Kiran 
