Rails Active Storage: an uploaded image can read your server's secrets and run code
Identifiers: CVE-2026-66066 · GHSA-xr9x-r78c-5hrm · CVSS 4.0 9.5 (scored by GitHub)
What it is
Active Storage did not turn off libvips' unsafe operations. Anyone who can upload an image can craft one that makes the server read its own files, including the environment variables that hold secret_key_base and cloud keys, and can reach remote code execution. It applies when the app uses the vips variant processor (the default since load_defaults 7.0) and accepts image uploads from people you do not trust.
Who is affected
Versions inside these ranges are affected. The fixed versions are the ones to move to.
| Registry | Package | Affected | Move to |
|---|---|---|---|
| RubyGems | activestorage | < 7.2.3.2 >= 8.0.0.beta1, < 8.0.5.1 >= 8.1.0.beta1, < 8.1.3.1 | 7.2.3.2, 8.0.5.1, 8.1.3.1 |
How to check
Run one of these in your project's folder; the first two download the CLI and check its SHA-256 first:
d="$(mktemp -d)" && a="xsec-$(uname -m | sed s/arm64/aarch64/)-unknown-linux-musl.tar.gz" && curl -fsSL -o "$d/$a" "https://github.com/xtruct-col/xsec-action/releases/latest/download/$a" && curl -fsSL -o "$d/checksums.txt" "https://github.com/xtruct-col/xsec-action/releases/latest/download/checksums.txt" && (cd "$d" && grep " $a$" checksums.txt | sha256sum -c -) && tar -xzf "$d/$a" -C "$d" xsec && "$d/xsec" depsdocker run --rm -v "$PWD:/src" -w /src alpine:3.20 sh -c 'apk add -q curl && d="$(mktemp -d)" && a="xsec-$(uname -m | sed s/arm64/aarch64/)-unknown-linux-musl.tar.gz" && curl -fsSL -o "$d/$a" "https://github.com/xtruct-col/xsec-action/releases/latest/download/$a" && curl -fsSL -o "$d/checksums.txt" "https://github.com/xtruct-col/xsec-action/releases/latest/download/checksums.txt" && (cd "$d" && grep " $a$" checksums.txt | sha256sum -c -) && tar -xzf "$d/$a" -C "$d" xsec && "$d/xsec" deps'xsec depsOr look up activestorage in your lockfile and compare the version with the ranges above.
How to fix it
Upgrade activestorage (with Rails) to 7.2.3.2, 8.0.5.1 or 8.1.3.1; the fix needs libvips 8.13 or later. Then rotate secret_key_base, the master key and your storage, database and API credentials. Workaround with libvips 8.13+: set VIPS_BLOCK_UNTRUSTED, or call Vips.block_untrusted(true) with ruby-vips 2.2.1+.
Sources
This list is curated by hand and kept short on purpose: it is not every known vulnerability, and a clean xsec deps does not mean no dependency has a flaw. Use your package manager's audit (npm audit, pip-audit, bundle audit) or Dependabot for the rest.