CVE-2026-81097: 
Ruby vulnerability analysis and mitigation

CVE-2026-81097 is an OS command injection vulnerability (CWE-78) in the execute_ruby tool of the rails-mcp-server Ruby gem by maquina-app. The tool was documented as a read-only Ruby sandbox enforced by a pattern denylist and Kernel method replacements, but the pseudo-terminal (PTY) library's spawn entry points were neither blocked nor replaced, allowing any caller to start an arbitrary shell process running as the server account. Affected versions are 1.4.0 through 1.6.0 (the denylist was introduced in 1.4.0 and never covered PTY entry points). It was disclosed on August 27, 2026, with patches released the same day. The CVSS v4 base score is 8.6 (High) and the CVSS v3.1 base score is 8.4 (High) (Github Advisory, Feedly).

The root cause is an incomplete security denylist (CWE-78) in the execute_ruby tool's sandbox implementation. The sandbox relied on a regex-based denylist and monkey-patching of Kernel process-spawning methods, but require "pty" was permitted (only unquoted requires were rejected), and the PTY module was entirely unguarded. An attacker could call PTY.spawn or PTY.getpty via a normal execute_ruby tool invocation to spawn a child process outside the guarded methods, achieving arbitrary OS command execution. Additionally, dynamic dispatch patterns such as const_get("Open3").capture2 and Process.send(:spawn, ...) were only gated behind a confirm_risky flag rather than hard-blocked, providing further bypass vectors. The PR fixing this issue also identified a ReDoS vulnerability (CodeQL alert) in the regex matchers themselves, where an ambiguous \s*\(?\s* construct caused polynomial backtracking on adversarial whitespace input (GitHub PR #59, Github Advisory).

Successful exploitation allows any local user or process with access to the MCP server to bypass the read-only sandbox and execute arbitrary shell commands with the full privileges of the account running the rails-mcp-server process. This results in high confidentiality, integrity, and availability impact on the vulnerable system — an attacker can read sensitive files, modify data, install backdoors, or disrupt service. The primary practical risk identified by the maintainer is prompt injection: a malicious coding agent (steered by a hostile issue, README, or dependency file) could invoke execute_ruby with a crafted payload, running attacker-controlled commands with operator-level privileges (GitHub PR #59, Github Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The vulnerability was responsibly disclosed by Pluto Security to the maintainer. The EPSS score is approximately 0.172% (7th percentile), indicating a low near-term exploitation probability. The attack vector is local (AV:L), meaning the attacker must have local access to invoke the execute_ruby tool — either directly or via a prompt-injected AI coding agent. The NVD SSVC assessment classifies exploitation as "none" and automatable as "no" (Github Advisory). The CVE is not listed in the CISA KEV catalog.

1. Access the MCP server: Obtain local access to a system running rails-mcp-server versions 1.4.0–1.6.0, either directly or by influencing an AI coding agent (e.g., via prompt injection in a repository file such as a README, issue, or dependency manifest).
2. Invoke the execute_ruby tool: Send a valid MCP tool call to execute_ruby with a crafted Ruby code snippet as the payload.
3. Require the PTY library: Include require "pty" in the payload — this was permitted by the denylist since only unquoted requires were rejected.
4. Spawn a shell via PTY: Call PTY.spawn("<command>") or PTY.getpty("<command>") in the payload. Because the PTY module was not in the denylist and its methods were not monkey-patched, the call executes outside the guarded sandbox.
5. Execute arbitrary commands: The spawned child process runs as the server account with full OS privileges, enabling data exfiltration, persistence, or further lateral movement (GitHub PR #59, Github Advisory).

• Logs: MCP server logs showing execute_ruby tool calls containing require "pty", PTY.spawn, PTY.getpty, const_get("Open3"), or Process.send(:spawn, ...) in the submitted Ruby code payload.
• Process: Unexpected child processes spawned by the rails-mcp-server Ruby process (e.g., /bin/sh, /bin/bash, curl, wget, nc) visible in process trees.
• File System: New or modified files in the Rails project directory or system directories created by the server account outside of normal operation; unexpected cron jobs or startup scripts added under the server account.
• Network: Outbound connections from the server host to unexpected external IPs or domains initiated by the server process or its children, particularly shortly after execute_ruby tool invocations.

Upgrade rails-mcp-server to version 1.6.1 or later immediately. Version 1.6.1 restricts require to a small allowlist of pure-data libraries (csv, tzinfo, date, time), hard-blocks dynamic dispatch to execution sinks (send/public_send/const_get targeting system, exec, spawn, fork, eval, popen, Open3, Process, PTY, etc.), and adds PTY/Fiddle/FFI to the forbidden-pattern scan. Version 2.0.0 removes the execute_ruby tool entirely, eliminating the entire vulnerability class. If immediate patching is not possible, restrict local access to the server account and avoid exposing the MCP server to untrusted AI agents or inputs. Running the server against a read-only database user and/or inside OS-level isolation is recommended as a defense-in-depth measure (GitHub Releases, Github Advisory).

The vulnerability was responsibly disclosed by Pluto Security, credited in the 2.0.0 release notes by the maintainer (GitHub Releases). The maintainer (mariochavez) was transparent in the PR discussion, explicitly framing the fix as "Tier 1" hardening and acknowledging that in-process Ruby execution cannot be made truly safe without OS-level isolation. The maintainer also corrected misleading "read-only sandbox" documentation across README, SECURITY.md, and agent guides as part of the remediation. Community coverage was limited to automated security feeds and aggregators such as RedPacketSecurity on Mastodon and rubysec.com (Feedly).