Mitigate CVE-2026-66066 with VIPS_BLOCK_UNTRUSTED on Windows

What the CVE-2026-66066 workaround Worklet does

This Automox Worklet™ sets the VIPS_BLOCK_UNTRUSTED system environment variable on Windows hosts that run Ruby on Rails with libvips. CVE-2026-66066 is a critical arbitrary file read, with possible remote code execution, in Rails Active Storage when libvips processes untrusted uploads. The Rails advisory GHSA-xr9x-r78c-5hrm publishes VIPS_BLOCK_UNTRUSTED as a temporary workaround, and this Worklet applies that workaround only.

Before it writes anything, the Worklet finds libvips. It reads RUBY_DLL_PATH and PATH for hint directories, then scans a fixed set of roots four levels deep for libvips DLL files: C:\Program Files, C:\Program Files (x86), C:\tools, C:\inetpub, C:\hostedtoolcache, and any matching C:\msys, C:\vips, or C:\Ruby directories. Version detection reads include\vips\version.h, lib\pkgconfig\vips.pc, or versions.json, falling back to the DLL version resource and then the install path.

The variable is written as a REG_SZ value of 1 under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment through the 64-bit registry view, and the prior state is saved to a backup file so a rollback run can restore it. Where every located libvips is older than 8.13, the Worklet refuses to write the variable and reports the endpoint as needing an upgrade, rather than recording a mitigation that does not exist.

Why apply the VIPS_BLOCK_UNTRUSTED workaround now

An arbitrary file read in an upload path is a credential problem. An attacker who reaches an Active Storage endpoint can read files the Rails process can read, which on a typical deployment includes config/master.key, environment files, API tokens, and cloud credentials. Rapid7 documents possible remote code execution built on the same primitive, so the practical blast radius is the application host and whatever those credentials unlock.

Upgrading activestorage to 7.2.3.2, 8.0.5.1, or 8.1.3.1 is the actual fix, and production Rails upgrades need a change window, dependency review, and testing. Setting VIPS_BLOCK_UNTRUSTED tells libvips 8.13 and later to refuse unfuzzed operations, which closes the exploit path while the upgrade moves through your process.

Doing that by hand across a fleet is slow and easy to get wrong, because the workaround is inert on libvips below 8.13. This Worklet checks applicability per endpoint and claims a mitigation only where the variable takes effect, so your vulnerability reporting reflects what is actually protected. Endpoints that cannot be mitigated are called out as upgrade work instead.

How the VIPS_BLOCK_UNTRUSTED mitigation works

1. Evaluation phase: Locates every libvips install through RUBY_DLL_PATH, PATH, and the fixed scan roots, then resolves the highest version it can read. An endpoint with no libvips is out of scope and reported compliant. An endpoint where every install is older than 8.13 is reported compliant with a not-mitigable note, since the variable cannot take effect there. Otherwise the check reads the system environment key and flags the endpoint when VIPS_BLOCK_UNTRUSTED is missing or empty.

2. Remediation phase: Repeats the discovery, then refuses to write when every located libvips is below 8.13. On an applicable endpoint it backs up the current value to disk, writes VIPS_BLOCK_UNTRUSTED with a value of 1 as a REG_SZ under the Session Manager Environment key in the 64-bit registry view, and re-reads the value to confirm the write. Running with the rollback switch restores the previous value, or deletes the value when none existed before.

CVE-2026-66066 mitigation requirements

• Windows 10 or Windows 11 x64, or Windows Server 2016 and later, with PowerShell 5.1 or newer

• The Automox agent running as SYSTEM, since the Worklet writes to HKLM and reads across Program Files and Ruby install roots

• libvips 8.13 or later on the endpoint: earlier versions cannot disable unfuzzed operations, so they must be upgraded or removed instead

• A restart of the Ruby on Rails processes, or of the endpoint, so newly started processes inherit the system environment variable

• A plan for the permanent fix: activestorage 7.2.3.2, 8.0.5.1, or 8.1.3.1 paired with libvips 8.13 or later

• An optional rollback path: setting the rollback switch in the remediation script restores the previous value from the backup file

Expected endpoint state after the mitigation

On an applicable endpoint, VIPS_BLOCK_UNTRUSTED is present in the system environment with a value of 1, and the Activity Log records each libvips install found, its version, the backup written, and the confirmed registry write. Only processes started after the write inherit the variable, so restart the Rails application processes before you treat the host as mitigated. Long-running workers keep the old environment until they are recycled.

Endpoints with no libvips, or with only pre-8.13 installs, report compliant with an explanation in the log. Those hosts are not protected by the variable and belong on your upgrade list. Re-running evaluation after a successful write returns compliant, and the same run keeps reminding you that this is a workaround: upgrading activestorage with libvips 8.13 or later is what actually resolves CVE-2026-66066.