Action Pack is a framework for handling and responding to web requests.

CVE-2026-66066, dubbed KindaRails2Shell by its discoverers at Ethiack, is a pre-authentication arbitrary file read chained to remote code execution in Ruby on Rails Active Storage. The flaw lives in how Active Storage hands untrusted uploads to libvips without disabling its "unfuzzed" format loaders — handlers for formats like MATLAB/HDF5 that were never security-hardened. An attacker uploads a crafted file to any endpoint that triggers variant generation (thumbnails, avatars, previews), and the unfuzzed loader reads arbitrary files as the Rails worker process. The primary targets are SECRET_KEY_BASE, config/master.key, database credentials, and cloud storage tokens. With SECRET_KEY_BASE in hand, the attacker forges a signed Ruby Marshal deserialization payload to achieve full remote code execution. Affected versions: activestorage < 7.2.3.2, 8.0.0–8.0.5.0, 8.1.0–8.1.3.0, and Rails 6.x only where variant_processor = :vips was explicitly enabled. The vips processor has been the default since Rails 7.0, meaning the vast majority of modern Rails apps running Active Storage are in scope.

GitHub (as CNA) scored this 9.5 on CVSS v4.0. That score is justified. This is a zero-click, unauthenticated, network-accessible chain that ends in full RCE on the web server, requires only that the app accept image uploads (the entire purpose of Active Storage), and runs in the default configuration. The Ethiack team estimates 500,000+ sites are potentially exposed because the vips processor is default in official Rails Docker images and Debian/Ubuntu packages. The only friction is that the app must actually generate variants from uploads — but thumbnail/avatar generation is the canonical Active Storage use case. noisgate independently assesses this as CRITICAL at 9.3.

Why this verdict

• Pre-auth, zero-click, network-accessible: The attack requires no authentication, no user interaction, and targets a network-facing upload endpoint. There is no friction from access control — anyone who can reach the upload form can exploit this.
• Default configuration is vulnerable: Rails 7.0+ ships with variant_processor = :vips as the default. Debian/Ubuntu libvips packages include the vulnerable loaders. The attacker does not need a misconfiguration — they need the *default* configuration.
• Full RCE chain with public PoC: The file read alone would be HIGH; the chain to SECRET_KEY_BASE extraction → signed Marshal deserialization → RCE elevates this to CRITICAL. The PoC (rails_vips_oast_poc.py) was published within hours of disclosure.
• Massive reachable population: Ethiack estimates 500,000+ potentially vulnerable sites. Rails is one of the most widely deployed web frameworks, and Active Storage with image uploads is a bread-and-butter feature.
• Role multiplier: Rails is the *typical* web application tier (line-of-business apps, SaaS products, e-commerce). Some high-value deployments include GitLab (CI/CD + supply chain), Discourse (community platforms), Shopify storefronts, and internal admin tools. While GitLab uses CarrierWave (not Active Storage), many internal Rails tools and SaaS products *do* use Active Storage for file handling. On a typical Rails web server, the blast radius is full server compromise + database access + cloud credential theft. For internal admin tools, the chain can pivot to internal network access. The affected component is a web application framework, where ≥80% of installs are internet-facing application servers — this is a canonical high-value-role component for web-tier attacks. Verdict floor: CRITICAL.

Why not higher?

A 9.3 rather than 9.5+ reflects two minor mitigants: (1) the chain requires the application to actually *generate variants* from uploads, not just store them — apps using has_one_attached without ever calling .variant() are not exploitable, and (2) the RCE step via Marshal deserialization has some deployment-specific variability (apps using non-cookie session stores or with custom Marshal restrictions face a slightly higher bar). These narrow the universality slightly below a perfect 10.

Why not lower?

Downgrading below CRITICAL would require evidence that the reachable population is small or that meaningful friction exists in the chain. Neither is true: the vips processor is the *default*, image uploads with thumbnailing is the *canonical* Active Storage use case, the attack is *unauthenticated*, and a *public PoC* exists. The only prerequisite — that the app accepts and processes image uploads — is satisfied by the overwhelming majority of Active Storage deployments. No modern security tool (WAF, EDR) reliably stops this chain at the upload stage because the malicious file is structurally valid.

1. Set VIPS_BLOCK_UNTRUSTED=true environment variable immediately — This tells libvips ≥ 8.13 to refuse loading via unfuzzed/untrusted format handlers, neutralizing the file-read vector entirely. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL. Verify libvips ≥ 8.13 is installed first — older versions ignore this variable silently.
2. Add Vips.block_untrusted(true) to a Rails initializer — Alternative to the env var approach. Create config/initializers/vips_security.rb with require 'vips'; Vips.block_untrusted(true). Requires ruby-vips ≥ 2.2.1. This is the code-level equivalent and survives env var misconfiguration.
3. Rotate all application secrets after patching — Even if you patch before exploitation, assume secrets *may* have been read. Rotate SECRET_KEY_BASE, RAILS_MASTER_KEY, database credentials, S3/GCS/Azure storage keys, and all third-party API tokens. Changing SECRET_KEY_BASE invalidates all active sessions — plan for user re-authentication.
4. Disable variant generation for untrusted uploads as a stopgap — If patching or setting the env var is not immediately possible, remove .variant() calls on user-uploaded attachments. This breaks thumbnails/previews but eliminates the trigger. Only viable as a <3 day bridge.
5. Upgrade libvips to ≥ 8.13 — The patched Rails versions require libvips ≥ 8.13 to call block_untrusted. On Debian/Ubuntu, check vips --version. If running older libvips, the Rails patch will raise a boot exception. Upgrade the system package or use a custom build.

Run this script on each Rails application host (or in each container) to check the Active Storage version and libvips configuration. Execute as the deploy user or any user with read access to the Gemfile.lock: bash check_cve_2026_66066.sh /path/to/rails/app. No special privileges required.

#!/usr/bin/env bash
# check_cve_2026_66066.sh — Detect CVE-2026-66066 exposure
# Usage: bash check_cve_2026_66066.sh /path/to/rails/app
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

APP_DIR="${1:-}"
if [ -z "$APP_DIR" ] || [ ! -d "$APP_DIR" ]; then
  echo "Usage: $0 /path/to/rails/app"
  exit 2
fi

GEMFILE_LOCK="$APP_DIR/Gemfile.lock"
if [ ! -f "$GEMFILE_LOCK" ]; then
  echo "UNKNOWN — Gemfile.lock not found at $GEMFILE_LOCK"
  exit 2
fi

# Extract activestorage version
AS_VERSION=$(grep -A1 '^ *activestorage ' "$GEMFILE_LOCK" | grep -oP '\(\K[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?' | head -1)
if [ -z "$AS_VERSION" ]; then
  echo "UNKNOWN — activestorage gem not found in Gemfile.lock (may not use Active Storage)"
  exit 2
fi

echo "Detected activestorage version: $AS_VERSION"

# Version comparison helper
version_gte() {
  printf '%s\n%s' "$2" "$1" | sort -V -C
}

VULNERABLE=false

# Check version ranges
if version_gte "$AS_VERSION" "8.1.0"; then
  if ! version_gte "$AS_VERSION" "8.1.3.1"; then
    VULNERABLE=true
    FIX="8.1.3.1"
  fi
elif version_gte "$AS_VERSION" "8.0.0"; then
  if ! version_gte "$AS_VERSION" "8.0.5.1"; then
    VULNERABLE=true
    FIX="8.0.5.1"
  fi
elif version_gte "$AS_VERSION" "7.2.0"; then
  if ! version_gte "$AS_VERSION" "7.2.3.2"; then
    VULNERABLE=true
    FIX="7.2.3.2"
  fi
elif version_gte "$AS_VERSION" "7.0.0"; then
  VULNERABLE=true
  FIX="7.2.3.2 (requires Rails upgrade — 7.0/7.1 are EOL)"
elif version_gte "$AS_VERSION" "6.0.0"; then
  echo "NOTE — Rails 6.x only vulnerable if variant_processor was manually set to :vips"
  VULNERABLE=true
  FIX="7.2.3.2 (requires Rails upgrade — 6.x is EOL)"
fi

# Check for VIPS_BLOCK_UNTRUSTED mitigation
MITIGATED=false
if [ "${VIPS_BLOCK_UNTRUSTED:-}" = "true" ]; then
  MITIGATED=true
  echo "MITIGATION DETECTED: VIPS_BLOCK_UNTRUSTED=true is set in environment"
fi

# Check libvips version
if command -v vips &>/dev/null; then
  VIPS_VER=$(vips --version | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  echo "Detected libvips version: $VIPS_VER"
  if ! version_gte "$VIPS_VER" "8.13.0"; then
    echo "WARNING: libvips < 8.13 — VIPS_BLOCK_UNTRUSTED env var will be IGNORED"
    MITIGATED=false
  fi
else
  echo "WARNING: vips CLI not found — cannot verify libvips version"
fi

# Final verdict
if [ "$VULNERABLE" = true ]; then
  if [ "$MITIGATED" = true ]; then
    echo "PATCHED (via mitigation) — activestorage $AS_VERSION is in the vulnerable range but VIPS_BLOCK_UNTRUSTED=true is active with libvips >= 8.13"
    exit 0
  else
    echo "VULNERABLE — activestorage $AS_VERSION is affected by CVE-2026-66066. Upgrade to $FIX or set VIPS_BLOCK_UNTRUSTED=true (requires libvips >= 8.13)"
    exit 1
  fi
else
  echo "PATCHED — activestorage $AS_VERSION is not in the vulnerable range"
  exit 0
fi

Sources

1. GitHub Security Advisory (GHSA-xr9x-r78c-5hrm)
2. Rails Official Patch Announcement
3. Ethiack KindaRails2Shell Research
4. HeroDevs Technical Analysis
5. The Hacker News Coverage
6. SOCPrime Advisory
7. NVD Entry
8. Rails Discussion Forum Advisory