CVE-2026-122006: Rails Active Storage ImageMagick Arbitrary File Read and Write

GitHub marked GHSA-f3w6-w445-fwh9 / CVE-2026-122006 as critical (CVSS 3.0 9.8) on November 12, 2026: a Rails app that lets untrusted users upload attachments and processes images with ImageMagick through Active Storage may allow unauthenticated arbitrary file write, and—with Disk storage—arbitrary file read for paths the Rails process can open. Typical reads include secret_key_base, encrypted credentials, and database passwords, which the advisory ties to remote code execution or lateral movement. Upgrade to activestorage 8.0.5.2 or 8.1.4.1, require mini_magick >= 5.1 when variant_processor is :mini_magick, and rotate every secret the app could read if exposure is plausible.

TL;DR

What GitHub and Rails published

The GitHub-reviewed advisory (first published to the database November 12, 2026, reviewed the same day) describes impact, mechanism, mitigations, and workarounds. CVE-2026-122006 was published to NVD on November 10, 2026. Fixed releases ship as Rails v8.0.5.2 and v8.1.4.1. Credit goes to HackerOne researcher Ry0taK per the advisory.

Impact, in substance from the advisory:

A Rails application that processes attachments with ImageMagick may allow an unauthenticated attacker to write arbitrary files on the server and, when attachments are stored with the Disk service, to read arbitrary files readable by the application process. Those files typically include secret_key_base and credentials for external systems, which may in turn allow escalation to remote code execution or lateral movement.

The RubySec entry is tracked as ruby-advisory-db#1300; the YAML record is GHSA-f3w6-w445-fwh9.yml.

EPSS on the advisory page was 0.741% at fetch time (55th percentile on FIRST's scale)—not proof of exploitation, but enough to prioritize patches on internet-facing apps.

This lands in a year when disclosed CVE volume has stressed agent-driven triage workflows; Rails ImageMagick issues are not new to agent operators who saw Hacktron's Discourse / libheif path through ImageMagick in September 2026, though the mechanism here is Active Storage's default ImageMagick integration, not a forum-specific handoff.

Mechanism: how ImageMagick turns an upload into file I/O

ImageMagick does not treat every upload as opaque pixels. It picks a coder from the file's content, and some coders operate on paths named inside the image rather than on the bitmap alone. Active Storage historically did not constrain which coders MiniMagick could invoke when the ImageMagick analyzer runs on attach.

Step 1: Attacker uploads a crafted file

Any endpoint that accepts Active Storage direct or indirect uploads from untrusted users can supply the malicious blob. The advisory assumes no authentication for the worst case (PR:N).

Step 2: Active Storage attaches and analyzes

When the file is attached, Active Storage runs the ImageMagick analyzer as part of the normal attach path. The advisory is explicit: attaching is sufficient—defenders cannot rely on "we never called variant or preview."

Step 3: ImageMagick invokes a dangerous coder

Without the shipped policy, coders such as MSL scripting, Ghostscript-backed PDF/PS handlers, fetch/delegate behaviors, and @filename indirection remain available. One reported chain exists; Rails states they do not assume it is the only one.

Step 4: Arbitrary write, then read

The write primitive lands anywhere the Unix user running Puma/Unicorn/Sidekiq can create files. With :disk service, reads can pull config/master.key, config/credentials/*.yml.enc decryption material, secret_key_base, and other env-derived secrets sitting on the same VM or container filesystem.

Step 5: Escalation

With secret_key_base or cloud tokens, attackers pivot to signed cookie forgery, decrypted credentials, database access, or webhooks—standard Rails post-compromise paths, not AI-specific magic.

Who is affected

You are in scope only when all of the following are true, per the advisory:

1. ImageMagick for Active Storage — config.active_storage.variant_processor = :mini_magick, which remains the default for apps on config.load_defaults 6.1 or earlier.
2. Permissive ImageMagick policy on the host — packaged Debian/Ubuntu policies do not deny the coders involved; fixed Rails ships activestorage/lib/active_storage/image_magick/policy.xml and prepends its directory to MAGICK_CONFIGURE_PATH via MiniMagick.cli_env.
3. Untrusted uploads — public signup avatars, support tickets, marketplace listings, agent-supervised user content, etc.

You are not covered by the shipped policy if you override MiniMagick.cli_env after boot, clear the environment with MiniMagick.cli_prefix, install a custom MiniMagick::Shell, or use GraphicsMagick (it does not read ImageMagick policies).

Version matrix

:mini_magick apps must use mini_magick >= 5.1; older gems raise at boot when the new policy path is required—treat that exception as a deployment blocker, not noise.

Apps that render PostScript or PDF through ImageMagick must re-allow gs and the coders they need in the host policy.xml after upgrade, or rendering will break by design.

Patch and verify

Upgrade gems

bundle update activestorage
bundle show activestorage
gem list mini_magick

Confirm resolved versions meet 8.0.5.2 or 8.1.4.1 and mini_magick >= 5.1. Commit lockfile changes—agents often bump Gemfile without refreshing Gemfile.lock.

Confirm policy wiring

After boot, every MiniMagick-spawned ImageMagick process should see the shipped policy in addition to the host policy (ImageMagick merges every policy.xml on the search path). If your platform team bind-mounts a custom policy only at /etc/ImageMagick-7/policy.xml, verify the Active Storage prepend still runs—custom shells that bypass MiniMagick.cli_env do not inherit it.

Workaround-only installs

If you cannot upgrade immediately, merge at minimum these denies into the system policy (example path /etc/ImageMagick-7/policy.xml), quoted from the advisory:

<policy domain="coder" rights="none" pattern="MSL" />
<policy domain="delegate" rights="none" pattern="gs" />
<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}" />

Copy the full rules from activestorage/lib/active_storage/image_magick/policy.xml on the branch you target— the three lines above are the advisory's minimum, not the complete shipped file.

If Disk storage might have leaked

Rotate secret_key_base, RAILS_MASTER_KEY, all credentials.yml.enc secrets, database and storage credentials, and third-party API tokens the process user could read. Invalidate sessions after secret_key_base rotation. The advisory warns not to keep a compromised secret as fallback.

Signs of compromise

The disclosure does not document in-the-wild exploitation. Reasonable server-side signals:

• New image uploads followed by unexpected file modifications outside storage/ paths
• Ghostscript or MSL strings inside uploaded "images"
• Sudden credential use from new IPs after public upload endpoints see traffic spikes

Treat these as triage hints, not confirmation.

What this means if you run AI coding agents

Agents increasingly scaffold Rails APIs, add Active Storage for user avatars or document ingestion, and git push to Railway/Heroku/Fly without a human re-reading config/application.rb. CVE-2026-122006 bites that workflow in four places:

1. Generated apps keep :mini_magick defaults — a Claude Code or Codex session that runs rails new on defaults 6.1 inherits the vulnerable processor unless the agent switches to :vips or disables analysis.
2. Staging equals production secrets — developers often copy master.key into preview environments agents deploy to; arbitrary read on staging becomes production credential theft.
3. Lockfile drift — agents edit Gemfile ("add activestorage for uploads") but CI still resolves 8.0.4 until someone runs bundle update. Pair merges with bundle audit or bundle show activestorage in CI the way you would for npm transport packages after React RSC CVEs.
4. Ruby supply chain adjacent risk — the same machines run bundle install next to typosquat gems that target Ruby developers; patch hygiene belongs in one application and supply-chain review habit.

Concrete agent workflow:

• Add bundle show activestorage and gem list mini_magick to post-merge CI when bots touch Gemfile.
• For public demos, prefer :vips where acceptable, or disable untrusted uploads on shared preview URLs.
• After upgrade, re-run integration tests that attach fixtures—boot failures on old mini_magick versions are intentional.

What Beam can and cannot do here

Beam is local-first observability on the workstation: it flags risky shell commands, credential-shaped content, and skill/MCP patterns before you run agents. It does not sit in front of your Rails HTTP upload endpoint, does not patch Gemfile.lock, and does not enforce ImageMagick policies on a remote host.

Where Beam still helps:

• PreToolUse denies (Claude Code, Codex) can stop an agent from running curl exfil tests against production or from rails c one-liners that dump credentials without approval.
• Skill and MCP scans catch some risky install patterns before agents add gems from untrusted instructions—heuristic, not a substitute for bundle audit.
• Event history shows if an agent recently ran bundle update without version pins you expected—useful after you suspect a vulnerable deploy.

Limits: Beam is not a WAF, not a Rails plugin, and not kernel isolation for ImageMagick inside Puma.

Choosing :vips instead of :mini_magick

Not every Rails app must stay on ImageMagick. Active Storage also supports config.active_storage.variant_processor = :vips, which routes variant work through libvips instead of MiniMagick. The CVE scope is the ImageMagick analyzer and variant path, not vips.

Moving processors is a product decision, not a silent security knob:

• Attachment analysis still matters — confirm whether your Rails version runs analyzers that touch ImageMagick on attach when you use only vips for variants; the advisory text targets ImageMagick for Active Storage processing on the :mini_magick path.
• Feature gaps — teams that depend on ImageMagick-specific PDF/PS rendering or exotic format support may need deliberate re-allows in policy.xml even after patch, as the advisory notes for gs and Ghostscript coders.
• Container images — Dockerfile lines that apt install imagemagick for a legacy app should be paired with either patched activestorage or a vips-first pipeline so agents do not regenerate vulnerable stacks on the next docker build.

If an agent proposes "switch to vips for performance," treat it as a security-relevant config change worthy of the same review you would give a dependency bump.

Object storage versus Disk service

Many production Rails apps store blobs on S3-compatible object storage rather than :disk. The advisory still rates integrity and write impact as critical on the app host: arbitrary write can plant webshells, cron payloads, or SSH keys wherever the process user can create files.

Read of secret_key_base and credentials is emphasized when Disk service lets the attacker recover sensitive paths from the host filesystem. On object storage-only deployments, assume write remains in scope for compromise of the VM, and assume any secrets still present on the instance filesystem (environment variables, mounted credentials.yml.enc, .env files agents copy into containers) stay in the blast radius.

Kubernetes teams should check:

• Whether persistent volumes mount storage/ beside application secrets
• Whether init containers generated by agents run ImageMagick as root on the same pod that holds RAILS_MASTER_KEY
• Whether preview environments share node disks with production namespaces

None of that replaces patching; it clarifies who must rotate what after upgrade.

Related reading

• Hacktron / Discourse ImageMagick path — prior ImageMagick hardening lessons on upload pipelines
• React RCE CVE-2026-126187 — parallel "agent scaffolded web app" patching pattern
• AI agent application and supply-chain security — review checklist for secrets, CI, and dependencies
• CVE volume and agent triage
• Monitor Railway-hosted apps if agents deploy Rails there
• Beam landing: how local watching works

Frequently asked questions

What is CVE-2026-122006?

It is a critical flaw in Rails Active Storage when ImageMagick processes uploads. ImageMagick selects coders from file content; some coders act on paths named inside the image. Active Storage did not constrain those coders, so a crafted upload attached through Active Storage can read or write files the app process can access.

Which activestorage versions are affected?

GitHub lists activestorage below 8.0.5.2 and from 8.1.0.beta1 through versions before 8.1.4.1. Patched releases are 8.0.5.2 and 8.1.4.1 per GHSA-f3w6-w445-fwh9 and the Rails release tags.

Do attackers need to call analyze or preview?

No. The advisory states that attaching the upload is sufficient; no variant, preview, or explicit analyze call is required because the ImageMagick analyzer runs when a file is attached.

When does arbitrary file read apply?

Read impact applies when attachments use Active Storage Disk service and the attacker can exfiltrate through a write or another channel. Files readable by the process typically include secret_key_base, credentials, database passwords, and third-party tokens.

What if I cannot upgrade immediately?

Copy the policy rules from activestorage/lib/active_storage/image_magick/policy.xml in fixed Rails into the host ImageMagick policy, at minimum denying MSL, Ghostscript coders, and the gs delegate. Applications that render PDF or PostScript through ImageMagick must re-allow only what they need in the host policy.

Should I rotate secrets after patching?

If you used Disk storage and allowed untrusted uploads while ImageMagick was unconstrained, rotate secret_key_base, master key, everything in credentials.yml.enc, storage and database credentials, and third-party tokens. The advisory says not to keep an exposed secret as a fallback.

Version numbers, EPSS, and advisory text reflect GitHub and NVD as of November 13, 2026.