CVE-2024-27281

What it actually does

RDoc versions 6.3.3 through 6.6.2, as shipped with Ruby 3.x through 3.3.0, unsafely deserialize YAML when reading .rdoc_options and, in some scenarios, when loading crafted RDoc documentation cache data. Because deserialization is not restricted to safe primitive types, a malicious YAML payload can instantiate arbitrary Ruby classes and trigger gadget chains that execute code in the context of the user or process running RDoc. The practical impact is local or workflow-mediated code execution during documentation generation or cache loading, with potential confidentiality, integrity, and availability impact limited to the privileges of the RDoc execution context.

Why it matters to the business

The main operational risk is compromise of developer workstations, CI/CD runners, build systems, or application maintenance jobs that generate Ruby documentation from untrusted or attacker-influenced source trees. Although the CVSS score is moderate, EPSS is low, the issue is not in CISA KEV, and no mature public exploitation is indicated, the vulnerability has been public for a long period and affects a common Ruby documentation component that may be transitively present in larger products such as GitLab. Successful exploitation could allow theft of source code or credentials available to build jobs, tampering with generated artifacts, lateral movement from CI infrastructure, or disruption of build and release processes.

How an attack unfolds

An attacker first needs a path to place or influence RDoc input that will later be processed by a victim or automated system. Common routes include submitting a malicious repository, dependency, package, merge request, source archive, or documentation bundle containing a crafted .rdoc_options file, or causing a crafted RDoc cache to be loaded. When RDoc runs, it parses the YAML content using unsafe object restoration. The payload abuses Ruby object deserialization behavior and available gadget classes to execute attacker-controlled code. The resulting commands run with the privileges and environment of the RDoc process, which may include developer credentials, CI job tokens, repository access, signing material, or network reachability. Exploitation is constrained by the need for RDoc execution against attacker-controlled content and suitable Ruby gadget availability, which is consistent with the local, high-complexity, user-interaction characteristics and the absence of known widespread exploitation.

How to fix it

Upgrade RDoc to a fixed version and ensure bundled Ruby installations and product dependencies no longer include vulnerable RDoc releases. The primary fixed RDoc version is 6.6.3.1. For Ruby 3.0 environments, use rdoc 6.3.4.1 or later; for Ruby 3.1, use rdoc 6.4.1.1 or later; for Ruby 3.2, use rdoc 6.5.1.1 or later; for Ruby 3.3-era installations, use rdoc 6.6.3.1 or later. For gitlab-org/gitlab source usage, update to a revision containing fix commit 9ec5f337f9fecb932051eca4d24744475f25870e or a vendor release that includes that commit. If immediate upgrade is not possible, avoid running RDoc on untrusted repositories or archives, disable automatic documentation generation for untrusted contributions, remove or ignore untrusted .rdoc_options files before execution, isolate documentation generation in sandboxed containers with no secrets and minimal network access, and clear/rebuild documentation caches from trusted input only.

How to confirm the fix worked

Confirm exposure by inventorying Ruby and RDoc versions across developer images, CI runners, build containers, application containers, release workers, and packaged products. Use commands such as `ruby -v`, `rdoc --version`, `gem list rdoc`, `bundle info rdoc`, and lockfile review to verify that RDoc is at or above the applicable fixed version. For GitLab source deployments or forks, verify the deployed code includes commit 9ec5f337f9fecb932051eca4d24744475f25870e or an equivalent upstream release. Validate mitigation by running documentation generation in a test environment against a benign .rdoc_options file and confirming that unsafe Ruby object deserialization is rejected or no longer results in object restoration. Also scan source trees, build workspaces, caches, and artifacts for unexpected .rdoc_options files or RDoc cache content containing Ruby object YAML tags.

Typical attack path

1. Identify an organization or workflow that runs RDoc against externally supplied, forked, vendored, or otherwise untrusted Ruby source content.
2. Prepare a malicious .rdoc_options YAML file or crafted RDoc cache that uses Ruby object tags intended to trigger unsafe deserialization behavior.
3. Deliver the payload through a repository, package, archive, merge request, dependency update, or other source/documentation ingestion path.
4. Wait for a developer workstation, documentation generation task, CI runner, release process, or maintenance job to invoke RDoc on the malicious content.
5. RDoc deserializes the crafted YAML and restores attacker-controlled Ruby objects without class restrictions.
6. The deserialization gadget chain executes code as the account running RDoc.
7. The attacker uses that execution context to access files, environment variables, source repositories, CI tokens, network services, or to alter build/documentation outputs.

How to detect it

Investigate whether RDoc processed attacker-controlled content before patching. Useful sources include CI job logs, build runner logs, shell command history, process execution telemetry, EDR events, container runtime logs, repository audit logs, merge request or package ingestion logs, file integrity monitoring, and network egress logs from build systems. Hunt for RDoc invocations in directories containing newly added or modified .rdoc_options files, especially files with YAML Ruby object tags such as `!ruby/object`, `!ruby/hash`, or `!ruby/struct`. Review documentation cache directories and generated artifacts for unexpected YAML object serialization, recently modified cache files, or content not attributable to normal builds. Correlate RDoc execution with suspicious child processes such as shells, interpreters, download utilities, credential access commands, or outbound connections from CI/build hosts. Because no specific public exploit pattern is established for this CVE, detection should focus on unsafe deserialization artifacts and anomalous post-RDoc behavior rather than a single fixed signature.

• .rdoc_options
• !ruby/object
• !ruby/hash
• !ruby/struct
• rdoc --op
• rdoc --main
• rake rdoc
• /usr/bin/rdoc
• /usr/local/bin/rdoc
• /usr/bin/ruby
• rdoc 6.3.3
• rdoc 6.4.0
• rdoc 6.4.1
• rdoc 6.5.0
• rdoc 6.5.1
• rdoc 6.6.0
• rdoc 6.6.1
• rdoc 6.6.2
• .rdoc_cache
• doc/.rdoc
• Gem::Installer
• Gem::SpecFetcher
• Gem::Requirement
• Kernel.system
• Open3.popen3

What your security team should do

• Prioritize upgrading RDoc in Ruby developer, CI, build, and release environments to the appropriate fixed version, even though current exploitation likelihood is low, because the issue is long public and affects supply-chain-adjacent workflows.
• Find all automated jobs that run `rdoc`, `yard` integrations invoking RDoc, `rake rdoc`, or documentation generation against untrusted or contributor-controlled source and restrict them until patched.
• Treat documentation generation as untrusted code execution: run it in ephemeral, least-privileged containers without production secrets, cloud credentials, signing keys, or broad network access.
• Add repository and CI guardrails to flag unexpected .rdoc_options files and YAML documents containing Ruby object tags in externally submitted code.
• Review recent build and documentation jobs for anomalous commands, outbound network connections, secret access, or source artifact changes around RDoc execution.
• Regenerate RDoc caches and documentation artifacts from trusted, patched tooling after upgrade.
• For GitLab source consumers or forks, update to a version or commit that includes 9ec5f337f9fecb932051eca4d24744475f25870e and verify downstream images/packages were rebuilt.