Share 
## https://sploitus.com/exploit?id=613D0AE3-CF24-5933-818F-51E9730DCC20
# rails-activestorage-vips-audit

An [Agent Skill](https://agentskills.io/specification) that audits Ruby on Rails repositories for exposure to **CVE-2026-66066** (_KindaRails2Shell_) β€” the Active Storage libvips variant-processing vulnerability that allows arbitrary file read and, in a Rails application, remote code execution.

The skill is a configuration auditor and remediation aid. It contains no exploit code and does not describe the attack chain.

## The vulnerability

|          |                                                                                               |
| :------- | :-------------------------------------------------------------------------------------------- |
| CVE      | CVE-2026-66066                                                                                |
| Severity | Critical, CVSS 9.5                                                                            |
| Package  | `activestorage` (RubyGems)                                                                    |
| Affected | `= 8.0 = 8.1 ...   # read-only audit, one verdict per repository
fix ...      # applies remediation on a branch; never commits or pushes unprompted
```

`report` is the default. `fix` requires a `report` verdict for the same repository first, because the correct remediation depends on it β€” Rails 6.x, 7.0.x, and 7.1.x have no same-series patch, so there `fix` applies the interim mitigation and reports that a framework upgrade is required rather than attempting one.

Evidence collection can also be run on its own:

```sh
skills/rails-activestorage-vips-audit/scripts/collect-evidence.sh path/to/app another/app
```

The script gathers facts and deliberately contains no verdict logic.

## What it will not tell you

- **The runtime libvips version.** It is not knowable from a repository, and it matters: below libvips 8.13 the unsafe operations cannot be disabled at all, so upgrading `activestorage` alone leaves the application exposed. Verify with `vips --version` where the application runs. Because of this, a clean verdict on an application that uses `:vips` is always reported as conditional rather than as safe.
- **Whether a mitigation is live.** `VIPS_BLOCK_UNTRUSTED` in a Dockerfile does not prove the deployed environment sets it. The skill caps such findings at "interim mitigation present, upgrade still required" and never lets one produce a clean verdict.

## Remediation summary

Upgrade to `7.2.3.2`, `8.0.5.1`, or `8.1.3.1`, matching your series, and confirm runtime libvips is `>= 8.13`.

Interim mitigations, neither of which is a substitute for the upgrade:

- Set the `VIPS_BLOCK_UNTRUSTED` environment variable (libvips `>= 8.13`)
- Call `Vips.block_untrusted(true)` from an initializer (`ruby-vips >= 2.2.1`)

If an application was exposed, treat every secret readable by the application process as compromised and rotate it: `secret_key_base`, the master key, Active Storage service credentials, database credentials, and third-party tokens.

A WAF is not a mitigation here. Whether it can see the payload depends on the storage service and upload method, so its effectiveness is too configuration-dependent to rely on.

## Disclaimer

- Use this skill only on repositories you own or are explicitly authorized to audit.
- Verdicts are best-effort static analysis. A NOT AFFECTED verdict is not proof of non-exposure: evidence outside the repository (runtime libvips, deployed environment variables, code in other services) is invisible to a repository audit, which is why clean verdicts on `:vips` applications are always reported as conditional.
- The skill contains no exploit code and will not reconstruct the attack chain, regardless of how a request is framed.
- Provided under the [MIT License](LICENSE), without warranty of any kind. Acting on a report β€” upgrades, mitigations, secret rotation β€” remains the operator's responsibility.

## Sources

- [Rails security advisory GHSA-xr9x-r78c-5hrm](https://github.com/rails/rails/security/advisories/GHSA-xr9x-r78c-5hrm)
- [Ethiack β€” KindaRails2Shell: Rails RCE (CVE-2026-66066)](https://ethiack.com/info-hub/research/kindarails2shell-rails-rce-cve-2026-66066)
- [Rails guides β€” Configuring Rails Applications](https://guides.rubyonrails.org/configuring.html)

The vulnerability was found and reported independently by [RyotaK](https://x.com/ryotkak) of GMO Flatt Security and by a team from Ethiack consisting of AndrΓ© Baptista, Bruno Mendes, and Castilho, then disclosed in coordination with the Rails maintainers.