KindaRails2Shell Arbitrary File Read in Rails Active Storage

Repository is a small single-script exploit project centered on kr2s.py, with only LICENSE, README.md, and one substantial Python 3.11+ program. It is not tied to a common exploit framework. The script is an operational research/exploitation driver for CVE-2026-66066 affecting Rails Active Storage when paired with libvips. Its core capability is generating a hybrid MATLAB/HDF5 file that abuses content-type trust in Rails and magic-byte sniffing in libvips so the same uploaded blob is treated differently by different layers. The crafted file embeds an HDF5 External File List reference to an attacker-controlled absolute path, enabling arbitrary file read from the target server. The code includes a payload builder function (craft_mat_external) that validates absolute target paths, enforces size/offset limits, decompresses an embedded MAT template, patches width/height/offset/byte-count metadata, and inserts a padded external filename path. The README and visible CLI definitions show multiple operator-facing modes: check (intrusive confirmation of readable target file), read (recover a fixed-size prefix of an arbitrary file), secrets (recover environment variables and Rails credential files, with optional redaction bypass), rce (recover or accept secret_key_base and then run a command conditionally), probe (test available libvips untrusted loaders), and scan (threaded passive or active multi-target scanning with optional JSON output). The exploit is clearly more than a detector: it performs uploads, reads server files, attempts secret recovery, and can execute commands when the secret_key_base forgery path succeeds. The README explicitly warns that several commands upload persistent blobs and may execute commands on the target. Default high-value file targets visible in the provided content include /proc/self/environ for environment leakage, /self/cwd/config/credentials.yml.enc for Rails credentials, and /etc/hostname as a canary for active verification. Overall, this is a mature standalone offensive PoC/operational tool for exploiting arbitrary file read and conditional RCE against vulnerable Rails Active Storage + libvips deployments.

Repository contains a single substantial exploit implementation, cve_2026_66066.py, plus README, license, and dependency file. The Python script is a standalone operational exploit for CVE-2026-66066 against vulnerable Ruby on Rails Active Storage deployments using libvips. It automates a full pre-auth chain: crafting a dual-identity MATLAB/HDF5 payload, uploading it through Active Storage direct uploads, triggering arbitrary file read via image variant processing, extracting secrets such as SECRET_KEY_BASE, and then forging signed variation data to achieve remote command execution. The script also includes a file-read-only mode, host scanning/mass scan support, threading, request/session handling, and output formatting. The exploit is network/web-based and targets Rails endpoints exposed over HTTP(S), especially /rails/active_storage/direct_uploads. Fingerprintable local target paths include /proc/self/environ, which is explicitly used to recover environment secrets. Overall, this is not just a detector or README; it is a functional exploit with both arbitrary file read and RCE capabilities.

Repository contains a single Python exploit driver (`kr2s.py`) plus a short README. The script is a standalone Python 3.11+ proof-of-concept/operational exploit for CVE-2026-66066, described as a Rails Active Storage/libvips arbitrary-file-read chain with conditional escalation to RCE via forged variation data. The code embeds a compressed MATLAB/HDF5 template and patches fixed offsets to craft a malicious file referencing an attacker-chosen absolute path on the target. This enables arbitrary file read through vulnerable libvips processing. The tool includes multiple CLI subcommands: file-read style operations, secret discovery (`secrets`), conditional command execution (`rce`), loader probing (`probe`), and threaded target scanning (`scan`) with passive and active modes. The active modes upload persistent artifacts and may trigger variant generation on the target. The exploit appears genuine and functional rather than a detector-only script: it contains payload crafting, HTTP client logic, target scanning support, secret extraction workflow, and an RCE path that accepts arbitrary user commands. No hardcoded remote domains or IPs are present in the visible content; targets are supplied by the operator at runtime. Fingerprintable observables are primarily local target file paths used as canaries and secret sources.

This repository is a real exploit PoC and local lab for CVE-2026-66066, targeting vulnerable Rails Active Storage/libvips processing. The main exploit is the single-file Python client kr2s.py, which uses only the Python standard library. Its core capability is arbitrary file read: it crafts a hybrid MATLAB/HDF5 payload whose external dataset points to an attacker-chosen absolute file on the target, uploads it through Rails Active Storage direct uploads while declaring it as image/png, harvests an existing Active Storage variation key from a rendered thumbnail, and triggers the built-in representation route so libvips/matio reads target file bytes and returns them as PNG pixels. The client then decodes the PNG and reconstructs the original bytes. The exploit supports multiple operator workflows: check, read, secrets, scan, probe, and rce. The secrets workflow focuses on environment and Rails credential files, especially /proc/self/environ to recover SECRET_KEY_BASE. If that secret is recovered or supplied manually, the RCE stage derives the Active Storage verifier key and forges a signed variation JSON containing an instance_eval operation, then executes an operator-provided shell command via /bin/sh. Output is written to a random /tmp/.kr2s_* file, read back through the same file-read primitive, and then removed. Repository structure: kr2s.py is the primary exploit entry point; tests/test_kr2s.py validates payload crafting, signing, PNG recovery, target normalization, and scan parsing; research/craft.py generates alternate candidate payloads for loader research using h5py/numpy; lab/ contains a Dockerized vulnerable Rails application and helper scripts. The lab app is intentionally ordinary: a small photo wall that exposes thumbnails, enabling harvest of a signed variation key without adding exploit-specific routes. lab/matrix.sh builds multiple Rails versions and verifies expected vulnerable vs patched behavior. lab/probe/probe.sh evaluates which libvips loaders accept candidate payloads and whether Vips.block_untrusted blocks them. Overall, this is an operational exploit/research repository rather than a mere detector. It includes both exploitation logic and a reproducible local environment for validating arbitrary file read and conditional RCE across affected Rails versions.

This repository is a self-contained lab and exploit PoC for CVE-2026-66066 / GHSA-xr9x-r78c-5hrm affecting Rails Active Storage with libvips. It is not just a detector: the main Python script, rails_vips_oast_poc.py, performs the full exploitation chain. The repository structure is small and purposeful: a Dockerfile builds a minimal vulnerable Rails 8.1.3 application, overlay/ contains only five ordinary Rails files needed to support file upload and image variant rendering, run_lab.sh launches the target container on loopback, and the Python script constructs and drives the exploit. The exploit capability is multi-stage. First, it creates a malicious MATLAB/HDF5 artifact with a 512-byte user block and an HDF5 dataset named environment backed by external storage pointing to /proc/1/environ. This abuses libvips MAT/HDF5 handling to turn process environment bytes into image data. Second, the script embeds a Ruby Marshal 4.8 gadget graph into the artifact. Third, it interacts with the Rails app over normal HTTP flows: fetches the upload form, parses CSRF and representation paths, uploads content, and triggers Active Storage representation generation. Fourth, it extracts SECRET_KEY_BASE from the returned pixel/environment data. Fifth, it forges a signed Rails variation token using the recovered secret and swaps that token into the Active Storage representation path. Finally, it triggers the signed payload, which executes /usr/bin/curl to send a single GET request to the configured OAST URL with a nonce for correlation. The target application itself is intentionally minimal and realistic: UploadsController provides new/create/show actions, Upload has has_one_attached :avatar, the new view accepts a file upload, the show view renders image_tag @upload.avatar.variant(format: :png), and routes expose root, uploads, and the standard Rails health endpoint. There are no exploit-only routes or helper services inside the target image. The Dockerfile pins Rails 8.1.3, installs libvips and sqlite3, generates a stock Rails app, overlays the minimal upload functionality, removes config/master.key, and runs the standard Rails container entrypoint. The shell script publishes the app only on 127.0.0.1 and injects SECRET_KEY_BASE into the container environment. Overall, this is an operational local-lab exploit demonstrating arbitrary environment read leading to signed payload forgery and RCE confirmation via outbound callback. It uses standard web interaction plus crafted file content and an OAST network callback, with the principal fingerprintable targets being the Rails HTTP service, the Active Storage representation route, /proc/1/environ, and the callback URL.