CVE-2026-66066: 
Ruby 취약성 분석 및 완화

CVE-2026-66066 is a critical arbitrary file read and potential remote code execution vulnerability in Ruby on Rails' Active Storage component, dubbed KindaRails2Shell. In its default configuration, Rails applications using libvips for image variant processing do not disable libvips operations marked "unfuzzed" (unsafe for untrusted content), allowing a crafted file upload to invoke such operations and read arbitrary files accessible to the Rails process — including environment variables and application secrets. Affected versions are activestorage < 7.2.3.2, >= 8.0.0.beta1 < 8.0.5.1, and >= 8.1.0.beta1 < 8.1.3.1. The vulnerability was responsibly disclosed by researchers from Ethiack and GMO Flatt Security, with the advisory published on July 29–30, 2026. It carries a CVSS v3.1 score of 8.9 (High) and a CVSS v4.0 score of 9.5 (Critical) (GitHub Advisory, Feedly).

The root cause is an insecure default initialization (CWE-1188) combined with unrestricted upload of dangerous file types (CWE-434). libvips categorizes certain image loaders and savers as "unfuzzed" — meaning they are only safe for trusted content — and exposes them to arbitrary file formats including HDF5/MATLAB .mat files. Active Storage failed to call Vips.block_untrusted(true) at boot, leaving these operations accessible to untrusted uploads. A known attack chain involves uploading a crafted MATLAB HDF5 file (.mat) that, when processed by libvips during variant generation, triggers an unfuzzed loader capable of reading arbitrary filesystem paths and exfiltrating their contents. The fix introduces a new activestorage/vips.rb initializer that calls Vips.block_untrusted(true) at boot and requires libvips >= 8.13 and ruby-vips >= 2.2.1 to enforce this restriction (GitHub Advisory, Rails Commit).

A successful exploit allows an unauthenticated remote attacker to read arbitrary files accessible to the Rails process, including /proc/self/environ, config/master.key, config/credentials.yml.enc, and any environment variables containing secrets such as secret_key_base, database credentials, S3/GCS/Azure keys, and third-party API tokens. Exposure of secret_key_base enables forging of signed cookies and session tokens, potentially escalating to remote code execution. Lateral movement to connected external services (databases, cloud storage, third-party APIs) is also a realistic consequence. Ethiack estimated over 500,000 websites were potentially exposed (GitHub Advisory, Cybersecurity Insiders).

1. Reconnaissance: Identify Rails applications using libvips for Active Storage image processing (configured via config.active_storage.variant_processor = :vips, the default since Rails 7.0) that accept file uploads from unauthenticated users. Tools like Shodan, Censys, or web crawlers can identify candidate targets.
2. Craft malicious payload: Construct a specially crafted file (e.g., an HDF5/MATLAB .mat file) that, when processed by an unfuzzed libvips loader, causes libvips to read an arbitrary file path on the server (e.g., /proc/self/environ or config/master.key).
3. Upload the crafted file: Submit the malicious file to the target application's file upload endpoint (e.g., a profile picture, attachment, or any Active Storage-backed upload field) as an unauthenticated or low-privilege user.
4. Trigger variant generation: Request a variant (resized/transformed version) of the uploaded file, causing Active Storage to invoke libvips processing on the crafted payload. This can be done by accessing a URL that triggers variant generation.
5. Exfiltrate secrets: The unfuzzed libvips operation reads the targeted file and its contents are returned or observable via an out-of-band channel (OAST/DNS callback), revealing environment variables, secret_key_base, or other credentials.
6. Escalate to RCE or lateral movement: Use the exfiltrated secret_key_base to forge signed cookies or session tokens for privilege escalation, or use exposed cloud/database credentials for lateral movement to connected systems (GitHub Advisory, PoC Repo, Ethiack Research).

• Network: Unusual file uploads (non-standard MIME types such as application/x-hdf, application/octet-stream for .mat files) to Active Storage upload endpoints; unexpected outbound DNS or HTTP requests from the Rails server process to external hosts (OAST callbacks) following image upload events.
• File System: Presence of crafted .mat, HDF5, or other non-image files in Active Storage blob storage directories; unexpected files in storage/ or cloud storage buckets with non-image content types.
• Logs: Rails application logs showing variant generation requests for non-standard file types (BMP, ICO, PSD, HDF5, MATLAB); Vips::Error exceptions in logs on patched systems indicating attempted exploitation; Active Storage blob records with suspicious content types in the database.
• Process: Unexpected child processes spawned by the Rails/Puma process; unusual outbound network connections from the web server process to external IPs or DNS resolvers shortly after file upload events.
• Application: Sudden session invalidation or cookie forgery attempts following a period of file uploads; unauthorized access to connected cloud storage, databases, or third-party APIs using credentials that should only be known to the application (GitHub Advisory, Rails Forensics Toolkit).

Primary remediation: Upgrade activestorage to patched versions 7.2.3.2, 8.0.5.1, or 8.1.3.1, and ensure libvips >= 8.13 and ruby-vips >= 2.2.1 are installed. The fix calls Vips.block_untrusted(true) at boot, disabling all unfuzzed loaders and savers (Rails v7.2.3.2 Release).

Workarounds (if immediate upgrade is not possible):

• Set the VIPS_BLOCK_UNTRUSTED=1 environment variable, which libvips reads at initialization (requires libvips >= 8.13).
• Call Vips.block_untrusted(true) from a Rails initializer if ruby-vips >= 2.2.1 is present.
• Remove ruby-vips from the Gemfile entirely if libvips is not required for variant processing.
• Restrict image upload functionality to authenticated and trusted users only.

Post-exploitation: If compromise is suspected, treat all secrets readable by the Rails process as exposed and rotate them immediately, including secret_key_base, RAILS_MASTER_KEY, database credentials, and all third-party API tokens (GitHub Advisory).

The vulnerability received significant attention from the security community upon disclosure. Rapid7 published an emergency threat response (ETR) blog post titled "KindaRails2Shell" covering the arbitrary file read and RCE potential (Rapid7 ETR). Akamai published a dedicated security research post on the Rails Active Storage RCE (Akamai Blog). Ethiack, one of the discovering teams, published a detailed technical write-up titled "KindaRails2Shell" explaining how a MATLAB file reads secrets and pops a shell (Ethiack Research). The Hacker News, BleepingComputer, SecurityWeek, and Heise all covered the vulnerability prominently. The Rails team published attack details and forensic investigation guidance on the Ruby on Rails discussion forum, and the Canadian Centre for Cyber Security issued advisory AV26-767. Community discussion was active on Hacker News, Reddit's r/netsec, and Mastodon/Bluesky infosec communities, with widespread calls for immediate patching (The Hacker News, BleepingComputer).