rails-forensics-CVE-2026-66066

Tooling and method for answering two questions about a Rails application and CVE-2026-66066, the Active Storage and libvips arbitrary file read known as KindaRails2Shell:

1. Was I vulnerable, and for how long?
2. Was I exploited, and if so, what left the building?

The advisory explains the vulnerability and names the patched versions. It does not tell you how to find out whether anyone used it against you. That question decides whether secret_key_base and everything it signs have to be rotated, and it is harder than it looks. The evidence is spread across your object store and three Active Storage tables, application logs expire long before the exposure window does, and a scheduled purge of unattached blobs destroys precisely the records the answer depends on.

If you are going to ask, ask soon. Every one of those is a clock that is already running.

This is a documentation and skill repository rather than a library. Nothing here is installed into your application. An agent reads it and works against your application checked out somewhere else, and the one script that runs in production is a single self-contained file you copy into a container.

The vulnerability in one paragraph

Rails decides a blob may be image-processed by reading a content_type column that a direct upload lets the client set without the bytes ever being examined. libvips then decides what the file actually is by sniffing magic bytes. A file whose first ten bytes claim MATLAB 5.0 is routed to libvips' MATLAB loader, which hands it to libmatio, which dispatches on a different byte range and finds MAT 7.3, which is HDF5. HDF5's External File List lets a dataset's bytes live in another file named by path and offset, so rendering the "image" reads an attacker-chosen file off the server and returns its contents as pixels. The same confusion, twice, at two layers that cannot see each other's fields.

reference/the-attack.md traces the whole call chain, from the inbound request to the point where libmatio opens the target file, with the four load-bearing junctions marked. reference/the-investigation.md then explains why the attack is investigable at all: it leaves three artifacts of increasing strength, and the strongest of them is the rendered variant, which holds the stolen bytes as pixel values in your own object store.

Start