diff --git a/gems/activestorage/CVE-2026-66066.yml b/gems/activestorage/CVE-2026-66066.yml
new file mode 100644
index 0000000000..1ae34fb69f
--- /dev/null
+++ b/gems/activestorage/CVE-2026-66066.yml
@@ -0,0 +1,73 @@
+---
+gem: activestorage
+framework: rails
+cve: 2026-66066
+ghsa: xr9x-r78c-5hrm
+url: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-66066
+title: Possible arbitrary file read and remote code execution in
+  Active Storage variant processing
+date: 2027-07-29
+description: |
+  ## 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.
+
+  ## 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.
+
+  ## 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.
+
+  ## Credit
+
+  This issue was responsibly reported by 0xacb, s3np41k1r1t0 and castilho
+  from Ethiack, and RyotaK from GMO Flatt Security Inc..
+cvss_v4: 9.5
+patched_versions:
+  - "~> 7.2.3.1"
+  - "~> 8.0.5.1"
+  - ">= 8.1.3.1"
+related:
+  url:
+    - https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-66066
+    - https://rubygems.org/gems/activesupport/versions/8.1.3.1
+      - https://github.com/rails/rails/releases/tag/v8.1.3.1
+    - https://rubygems.org/gems/activesupport/versions/8.0.5.1
+      - https://github.com/rails/rails/releases/tag/v8.0.5.1
+    - https://rubygems.org/gems/activesupport/versions/7.2.3.2
+      - https://github.com/rails/rails/releases/tag/v7.2.3.2
+    - https://blog.flatt.tech/entry/kindarails2shell_rails
+    - https://ethiack.com/info-hub/research/kindarails2shell-rails-rce-cve
+    - https://github.com/rails/rails/security/advisories/GHSA-xr9x-r78c-5hrm
+notes: |
+  - CVE is reserved, but not published.
+  - cvss_v4 from project GHSA
+  - From GHSA: "Details will be disclosed no later than 2026-08-28,
+    via the Rails Security Announcements forum."