CVE-2026-66066: Activestorage Remote Code Execution Vulnerability

CRITICAL
Advisory Identifier: GHSA-xr9x-r78c-5hrm
CWE-1188
Published
Advisory Summary

CVE-2026-66066 is a CRITICAL remote code execution vulnerability (CWE-1188: Initialization of a Resource with an Insecure Default) affecting Activestorage libraries in the RubyGems ecosystem. The issue involves active storage has possible arbitrary file read and remote code execution in active storage variant processing. Remediation is available by upgrading affected packages to version 7.2.3.2, 8.0.5.1, 8.1.3.1.

CVE-2026-66066 at a Glance

CVE Identifier CVE-2026-66066
GHSA Identifier GHSA-xr9x-r78c-5hrm
Severity CRITICAL
CVSS v3.1 Base Score N/A
CWE Classification CWE-1188: Initialization of a Resource with an Insecure Default
Affected Product Activestorage
Package Ecosystem RubyGems
Published Date
Last Updated

How to Fix CVE-2026-66066

To remediate this vulnerability, upgrade all affected Activestorage dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

activestorage fixed: 7.2.3.2
Upgrade activestorage to 7.2.3.2
activestorage fixed: 8.0.5.1
Upgrade activestorage to 8.0.5.1
activestorage fixed: 8.1.3.1
Upgrade activestorage to 8.1.3.1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for activestorage

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-66066, inspect your project dependencies for Activestorage:

inspect dependencies for activestorage

Analyze the terminal output to locate any version of Activestorage in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 7.2.3.2), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-1188: Initialization of a Resource with an Insecure Default, where the product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure. In Activestorage, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Impact In its default configuration, a Rails application that displays image variants may allow an unauthenticated attacker to read arbitrary files from the server, including the process environment. That environment typically holds `secret_key_base` and often credentials for external systems, which may in turn allow escalation to remote code execution or lateral movement to those systems. ### Details libvips reads and writes file formats through "loaders" and "savers" (or more generally "operations"), many of which are backed by third-party libraries. It marks some of these operations as "unfuzzed", meaning they are unsafe for untrusted content, and several handle formats unrelated to web images. Active Storage did not disable the unfuzzed operations, so an attacker who can upload a crafted file and cause a variant to be generated from it may be able to invoke one. We are aware of a mechanism by which an attacker, by uploading a crafted file, is able to cause disclosure of the contents of arbitrary files accessible on the filesystem of the targeted application. One specific attack chain has been reported to us (see "Disclosure" below), but we do not assume it is the only one that exists. ### Affected applications An application is affected if it meets all of these requirements: - Uses libvips for Active Storage image processing. This is `config.active_storage.variant_processor = :vips`, which `load_defaults 7.0` set and no later default has changed. - Allows image uploads from untrusted users. Generating variants is not a separate requirement. ### Mitigation - Upgrade to a fixed version of `activestorage`. - The minimum version of libvips must be upgraded to `>= 8.13`. - Change `secret_key_base` and change any secrets accessible in the application environment (see "Expire and change secrets" below) Earlier versions of libvips (`< 8.13`) cannot disable unfuzzed operations at all, and Active Storage will raise an exception during boot in such an unsecurable environment. ### Expire and change secrets Upgrading closes the vulnerability but does not undo an exfiltrated secret if that already occurred. An affected application should treat every secret readable by the application process as potentially exposed and change it, including: - `secret_key_base` - The master key, whether stored in `config/master.key` or supplied as `RAILS_MASTER_KEY`, along with everything in `config/credentials.yml.enc` that it decrypts - Credentials for the Active Storage service, such as S3, GCS, or Azure keys - Database credentials - Tokens and keys for any third-party service the application calls Changing `secret_key_base` expires active sessions and requires users to log in again. Encrypted cookies, signed cookies, signed global IDs, and Active Storage URLs are also affected. Rotation should only be used as an intermediate step if necessary. Do not retain an exposed secret as a fallback. ### Workarounds If libvips `< 8.13` is being used, there are no workarounds available other than removing the dependency on libvips from the application. Some applications may have `ruby-vips` declared as a dependency only for image analysis, and those applications may be able to simply remove `ruby-vips` from the Gemfile to remove libvips from the application. Applications that do not use Active Storage can remove `ruby-vips` from the Gemfile to avoid the boot-time checks. If libvips `>= 8.13` is present on the system, applications can disable the unfuzzed operations without upgrading Rails by setting the `VIPS_BLOCK_UNTRUSTED` environment variable, which libvips reads while initializing. Applications also running ruby-vips `>= 2.2.1` or later can instead call `Vips.block_untrusted(true)` from an initializer. ### Releases The fixed releases are available at the normal locations. ### Versions affected - activestorage < 7.2.3.2 - activestorage >= 8.0, < 8.0.5.1 - activestorage >= 8.1, < 8.1.3.1 ### Disclosure Technical details of the attack chain are intentionally omitted from this advisory. They would add nothing to an administrator's decision to upgrade, while making it substantially easier to attack applications that have not yet done so. Details will be disclosed no later than 2026-08-28, via the [Rails Security Announcements](https://discuss.rubyonrails.org/c/security-announcements/9) forum. ### Credit This issue was responsibly reported by [0xacb](https://x.com/0xacb), [s3np41k1r1t0](https://x.com/s3np41k1r1t0) and [castilho](https://x.com/castilho101) from [Ethiack](https://ethiack.com), and [RyotaK](https://ryotak.net) from [GMO Flatt Security Inc.](https://flatt.tech/en/). ### References - libvips 8.13 release notes, [blocking of unfuzzed loaders](https://www.libvips.org/2022/05/28/What's-new-in-8.13.html#blocking-of-unfuzzed-loaders) - W.A. Arbaugh, W.L. Fithen, and J. McHugh, ["Windows of Vulnerability: A Case Study Analysis"](https://doi.org/10.1109/2.889093), IEEE Computer 33(12), December 2000 - https://ethiack.com/info-hub/research/kindarails2shell-rails-rce-cve - https://blog.flatt.tech/entry/kindarails2shell_rails

CVE-2026-66066 Affected Activestorage Versions

3 component(s)
Fixed Versions:
7.2.3.28.0.5.18.1.3.1
Product / Package Ecosystem Affected Versions Fixed Version
activestorage
RubyGems
< 7.2.3.2
7.2.3.2
activestorage
RubyGems
≥ 8.0.0.beta1
< 8.0.5.1
8.0.5.1
activestorage
RubyGems
≥ 8.1.0.beta1
< 8.1.3.1
8.1.3.1

References

Frequently Asked Questions

What is CVE-2026-66066?
CVE-2026-66066 is a security vulnerability in Activestorage involving Active Storage has possible arbitrary file read and remote code execution in Active Storage variant processing under CWE-1188: Initialization of a Resource with an Insecure Default.
Which Activestorage versions are affected?
Affected versions include releases prior to 7.2.3.2, 8.0.5.1, 8.1.3.1 across affected packages: activestorage.
What version fixes CVE-2026-66066?
Upgrading to 7.2.3.2, 8.0.5.1, 8.1.3.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is activestorage affected?
Yes, activestorage is affected in releases prior to 7.2.3.2, 8.0.5.1, 8.1.3.1. Upgrade your dependency to 7.2.3.2, 8.0.5.1, 8.1.3.1 or later.
What CWE is associated with CVE-2026-66066?
CVE-2026-66066 is classified under CWE-1188: Initialization of a Resource with an Insecure Default (The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.).
How can I check RubyGems dependencies for CVE-2026-66066?
Run the dependency tree command: 'inspect dependencies for activestorage'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-xr9x-r78c-5hrm",
  "modified" : "2026-07-30T18:23:33Z",
  "published" : "2026-07-30T18:23:33Z",
  "aliases" : [ "CVE-2026-66066" ],
  "summary" : "Active Storage has possible arbitrary file read and remote code execution in Active Storage variant processing",
  "details" : "### Impact\nIn its default configuration, a Rails application that displays image variants may allow an\nunauthenticated attacker to read arbitrary files from the server, including the process environment.\nThat environment typically holds `secret_key_base` and often credentials for external systems, which\nmay in turn allow escalation to remote code execution or lateral movement to those systems.\n\n### Details\nlibvips reads and writes file formats through \"loaders\" and \"savers\" (or more generally\n\"operations\"), many of which are backed by third-party libraries. It marks some of these operations\nas \"unfuzzed\", meaning they are unsafe for untrusted content, and several handle formats unrelated\nto web images. Active Storage did not disable the unfuzzed operations, so an attacker who can upload\na crafted file and cause a variant to be generated from it may be able to invoke one.\n\nWe are aware of a mechanism by which an attacker, by uploading a crafted file, is able to cause\ndisclosure of the contents of arbitrary files accessible on the filesystem of the targeted\napplication. One specific attack chain has been reported to us (see \"Disclosure\" below), but we do\nnot assume it is the only one that exists.\n\n### Affected applications\nAn application is affected if it meets all of these requirements:\n- Uses libvips for Active Storage image processing. This is `config.active_storage.variant_processor = :vips`,\n  which `load_defaults 7.0` set and no later default has changed.\n- Allows image uploads from untrusted users.\n\nGenerating variants is not a separate requirement.\n\n### Mitigation\n- Upgrade to a fixed version of `activestorage`.\n- The minimum version of libvips must be upgraded to `>= 8.13`.\n- Change `secret_key_base` and change any secrets accessible in the application environment (see \"Expire and change secrets\" below)\n\nEarlier versions of libvips (`< 8.13`) cannot disable unfuzzed operations at all, and Active Storage\nwill raise an exception during boot in such an unsecurable environment.\n\n### Expire and change secrets\n\nUpgrading closes the vulnerability but does not undo an exfiltrated secret if that already\noccurred. An affected application should treat every secret readable by the application process as\npotentially exposed and change it, including:\n\n- `secret_key_base`\n- The master key, whether stored in `config/master.key` or supplied as `RAILS_MASTER_KEY`, along\n  with everything in `config/credentials.yml.enc` that it decrypts\n- Credentials for the Active Storage service, such as S3, GCS, or Azure keys\n- Database credentials\n- Tokens and keys for any third-party service the application calls\n\nChanging `secret_key_base` expires active sessions and requires users to log in again. Encrypted\ncookies, signed cookies, signed global IDs, and Active Storage URLs are also affected.\n\nRotation should only be used as an intermediate step if necessary. Do not retain an exposed secret\nas a fallback.\n\n### Workarounds\nIf libvips `< 8.13` is being used, there are no workarounds available other than removing the\ndependency on libvips from the application. Some applications may have `ruby-vips` declared as a\ndependency only for image analysis, and those applications may be able to simply remove `ruby-vips`\nfrom the Gemfile to remove libvips from the application. Applications that do not use Active Storage\ncan remove `ruby-vips` from the Gemfile to avoid the boot-time checks.\n\nIf libvips `>= 8.13` is present on the system, applications can disable the unfuzzed operations\nwithout upgrading Rails by setting the `VIPS_BLOCK_UNTRUSTED` environment variable, which libvips\nreads while initializing.\n\nApplications also running ruby-vips `>= 2.2.1` or later can instead call\n`Vips.block_untrusted(true)` from an initializer.\n\n### Releases\nThe fixed releases are available at the normal locations.\n\n### Versions affected\n\n- activestorage < 7.2.3.2\n- activestorage >= 8.0, < 8.0.5.1\n- activestorage >= 8.1, < 8.1.3.1\n\n### Disclosure\nTechnical details of the attack chain are intentionally omitted from this advisory. They would add\nnothing to an administrator's decision to upgrade, while making it substantially easier to attack\napplications that have not yet done so.\n\nDetails will be disclosed no later than 2026-08-28, via the [Rails Security\nAnnouncements](https://discuss.rubyonrails.org/c/security-announcements/9) forum.\n\n### Credit\nThis issue was responsibly reported by [0xacb](https://x.com/0xacb), [s3np41k1r1t0](https://x.com/s3np41k1r1t0) and [castilho](https://x.com/castilho101) from [Ethiack](https://ethiack.com), and [RyotaK](https://ryotak.net) from [GMO Flatt Security Inc.](https://flatt.tech/en/).\n\n### References\n- libvips 8.13 release notes, [blocking of unfuzzed loaders](https://www.libvips.org/2022/05/28/What's-new-in-8.13.html#blocking-of-unfuzzed-loaders)\n- W.A. Arbaugh, W.L. Fithen, and J. McHugh, [\"Windows of Vulnerability: A Case Study\n  Analysis\"](https://doi.org/10.1109/2.889093), IEEE Computer 33(12), December 2000\n- https://ethiack.com/info-hub/research/kindarails2shell-rails-rce-cve\n- https://blog.flatt.tech/entry/kindarails2shell_rails",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "RubyGems",
      "name" : "activestorage"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "7.2.3.2"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "RubyGems",
      "name" : "activestorage"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "8.0.0.beta1"
      }, {
        "fixed" : "8.0.5.1"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "RubyGems",
      "name" : "activestorage"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "8.1.0.beta1"
      }, {
        "fixed" : "8.1.3.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/rails/rails/security/advisories/GHSA-xr9x-r78c-5hrm"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rails/rails/commit/1c01bb587206ee6eb0e1179c2cef96a6a47acb1e"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rails/rails/commit/349e7a5d5b4b715af1e416db824f3c078a7d59e5"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rails/rails/commit/d79b7f4aa17dec8ce4960fef05733c8c0c7ef49a"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/rails/rails"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rails/rails/releases/tag/v7.2.3.2"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rails/rails/releases/tag/v8.0.5.1"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rails/rails/releases/tag/v8.1.3.1"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/activestorage/CVE-2026-66066.yml"
  }, {
    "type" : "WEB",
    "url" : "https://thehackernews.com/2026/07/critical-rails-flaw-could-let.html"
  }, {
    "type" : "WEB",
    "url" : "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-66066"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-1188" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-30T18:23:33Z",
    "nvd_published_at" : null
  }
}