Set the VIPS_BLOCK_UNTRUSTED Environment Variable to Mitigate CVE-2026-66066 on Windows

What the VIPS_BLOCK_UNTRUSTED mitigation Worklet does

This Automox Worklet™ sets the VIPS_BLOCK_UNTRUSTED system environment variable to 1 on Windows endpoints as a temporary workaround for CVE-2026-66066. The flaw sits in Ruby on Rails Active Storage, where libvips processes untrusted image uploads. Rapid7 calls it KindaRails2Shell, a critical arbitrary file read with possible remote code execution.

The Rails security advisory GHSA-xr9x-r78c-5hrm lists VIPS_BLOCK_UNTRUSTED as a workaround for applications that run libvips 8.13 or later. Applications on ruby-vips 2.2.1 or later can call Vips.block_untrusted(true) from an initializer instead. When a Rails process starts with the variable set, libvips refuses untrusted operations during Active Storage image processing.

The Worklet first looks for a Ruby, Rails, or libvips footprint and skips endpoints that have none. Where it finds one, it writes the value to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment through the 64-bit registry view. The Worklet doesn't restart Rails.

Why block untrusted libvips operations on Rails endpoints

Active Storage defaults to the :vips variant processor. In that configuration, an unauthenticated attacker who can upload a crafted file may be able to read any file the Rails process can read. That includes the process environment, which typically holds secret_key_base and other credentials. Those credentials can lead to remote code execution or lateral movement to connected systems.

The permanent fix is upgrading the activestorage gem to 7.2.3.2, 8.0.5.1, or 8.1.3.1 with libvips 8.13 or later. The patched releases raise an exception at boot on older libvips. The workaround touches no application code.

How the VIPS_BLOCK_UNTRUSTED workaround works

1. Evaluation phase: Scans for a Ruby, Rails, or libvips footprint and logs each piece of evidence it finds. The scan resolves ruby.exe, rails.bat, and rails.cmd on the PATH the agent inherits and checks the top level of each PATH directory for libvips*.dll. It also looks for a DisplayName containing Ruby under the HKLM Uninstall registry entries and for install roots at %SystemDrive%\Ruby* or %SystemDrive%\tools\ruby*.

   If the scan finds no footprint, evaluation logs RESULT: NOT APPLICABLE and exits 0. If the scan can't complete, evaluation logs RESULT: NO ACTION and exits 0.

   Only in-scope endpoints reach the registry check. Evaluation reads VIPS_BLOCK_UNTRUSTED from the Session Manager\Environment key through the 64-bit view.

   Evaluation logs RESULT: COMPLIANT and exits 0 when the value is non-empty. For an absent or empty value, it logs RESULT: NON-COMPLIANT and exits 1 so remediation runs. If the Worklet can't read the key, it logs RESULT: NO ACTION with a state-undetermined message and exits 0.

2. Remediation phase: Writes VIPS_BLOCK_UNTRUSTED to the Session Manager\Environment key as a REG_SZ value of 1 through the 64-bit view. When you enable rollback, it runs before the scope check and restores the state recorded in the backup file. If the backup holds <not-set>, rollback deletes VIPS_BLOCK_UNTRUSTED. Without a backup file, it exits 1.

   Without rollback, remediation runs its own footprint scan first. It changes nothing when the scan finds no footprint (NOT APPLICABLE) or can't complete (NO CHANGE). Next, it reads the current value. If VIPS_BLOCK_UNTRUSTED already holds a non-empty value, it logs ALREADY COMPLIANT and exits 0 without writing.

   Before the write, remediation saves <not-set> as the prior value in %ProgramData%\amagent\WorkletCache\a8ee016e-fcc6-5974-ae7d-d3bbb043144d\VIPS_BLOCK_UNTRUSTED.bak, unless a backup already exists. After the write, it re-reads the key with the evaluation's non-empty check. If the initial read, the backup, the write, or the re-read fails, remediation exits 1.

   A verified write produces two log reminders: restart Rails and libvips processes, and validate application image processing. The RESULT: COMPLIANT line that follows names the fixed activestorage versions as the permanent fix. When you set dryrun to $true, the Worklet logs each planned change without modifying state.

   To remove the variable after you upgrade, take the endpoint out of this policy first. Then run a separate copy of the Worklet with rollback enabled through Run Policy, which runs remediation without evaluation.

VIPS_BLOCK_UNTRUSTED mitigation requirements

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

• The Automox agent running as SYSTEM, since the Worklet writes to HKLM

• Ruby on Rails applications that run on the endpoint and use Active Storage

• libvips 8.13 or later on the endpoint, which the Rails advisory requires for this workaround

• A Ruby, Rails, or libvips footprint the Worklet can detect (see the Evaluation phase)

• A maintenance window to reboot endpoints that run Rails as a Windows service, or to restart interactively launched Rails from a new sign-in session

• A test of each application's image processing after the change

• Optional dryrun and rollback switches, set by editing their script-scoped assignments at the top of remediation.ps1 from $false to $true

Expected libvips behavior after the mitigation

After you restart Rails on a remediated endpoint, Active Storage image processing runs with the block in effect. You can confirm the variable from PowerShell with [Environment]::GetEnvironmentVariable('VIPS_BLOCK_UNTRUSTED', 'Machine'). The command returns 1 where the Worklet wrote the value.

On a remediation run, the Activity Log records the prior value, the write, and the post-verify read. It also shows you the footprint evidence that put the endpoint in scope, such as ruby.exe on the PATH or a Ruby install root. The next evaluation on the endpoint reports compliant.