A crafted image upload lets attackers write files to Ruby on Rails servers

Ruby on Rails, the web framework behind many online stores, SaaS products and startups, has fixed a critical flaw that lets an attacker with no account write arbitrary files to the server just by uploading a crafted image. The bug sits in Active Storage, the Rails component that handles file uploads, and affects apps that process images with ImageMagick. It is rated 9.8 out of 10, according to the Rails security advisory. The fix shipped on 4 November in Rails 8.0.5.2 and 8.1.4.1.

How one upload breaks the server

ImageMagick decides how to read a file from its contents, not from its name. Some of its "coders" do not just decode a picture: they follow instructions inside the file and read or write other files on the disk. Active Storage did not restrict any of them and runs its ImageMagick analyzer the moment a file is attached. "Attaching the upload is sufficient; no variant, preview, or analyze call is required," the advisory says.

If an app keeps uploads on the local disk (the Disk service), the attacker can also read any file the app can read. That usually includes secret_key_base and credentials for databases, cloud storage and third-party services. With those, the advisory warns, an attacker may get to remote code execution or move on to the connected systems. The flaw was reported by the HackerOne researcher ryotak. Rails says one attack chain was reported, "but we do not assume it is the only one that exists".

Which apps are affected

An app is vulnerable if all three conditions hold:

• ImageMagick processes images. That is the :mini_magick variant processor, the default for apps configured with load_defaults 6.1 or earlier. Since Rails 7.0, new apps use libvips instead, so they are exposed only if someone switched them back to ImageMagick.
• ImageMagick runs without a strict policy. The policies shipped by Debian and Ubuntu do not block the coders involved.
• Strangers can upload files: avatars, product photos, attachments to support tickets.

Affected versions are activestorage before 8.0.5.2 and 8.1 before 8.1.4.1. Older branches get no fix: the Rails team says earlier versions are unsupported and recommends moving to at least the 8.0 series, whose security support itself ends on 7 November 2026. The same release closes 20 other security issues, four of them rated high, including a separate bug in video previews that could lead to code execution through FFmpeg.

The advisory says nothing about attacks in the wild. But once a fix is public, attackers can compare the old and new code to work out where the hole was, so every day without the update adds to the risk.

What developers should do

• Update to Rails 8.0.5.2 or 8.1.4.1. If you use mini_magick, you also need mini_magick 5.1 or newer, or the app will fail at boot.
• If you cannot update right away, copy the ImageMagick policy from the fixed release into the system policy.xml. At a minimum, deny the MSL coder, the Ghostscript coders and the gs delegate.
• If uploads were stored with the Disk service, rotate secret_key_base, the master key, everything in credentials.yml.enc, database and storage passwords, and third-party tokens. The advisory says not to keep the old secret as a fallback.
• If your app renders PDF or PostScript through ImageMagick, re-allow only the coders it needs after applying the policy.

Users of Rails sites have nothing to install. The risk for them is that customer data stored by an unpatched shop or service leaks, and that depends on how fast its developers update.