Rails released 8.0.5.2 and 8.1.4.1 on November 4 to address 21 security issues. Mike Dalessio’s release announcement recommends upgrading promptly. Two Active Storage advisories also tell exposed applications to change secrets; installing repaired code cannot invalidate credentials already copied.

Evidence status: maintainer-disclosed vulnerabilities with fixed releases. The announcement and advisories reviewed here report no exploitation in the wild. Exposure depends on which Rails components and external media tools an application actually uses.

An attachment can trigger image analysis immediately

The ImageMagick advisory describes arbitrary file writes and, with Active Storage’s Disk service, reads of files accessible to the application. A stolen application secret or external-service credential can enable further compromise.

An application meets the documented exposure conditions when it:

  • Accepts uploads from untrusted users.
  • Uses ImageMagick through :mini_magick for Active Storage image processing.
  • Runs an ImageMagick policy that permits the dangerous processing features involved.

The maintainers say Debian and Ubuntu’s packaged policies do not already block the relevant features. Applications retaining load_defaults 6.1 or earlier default to MiniMagick. A framework upgrade alone therefore does not establish which image processor the application uses.

Attaching the file is enough to start the analyzer. The application does not need to request a resized variant or preview first.

The fixed Active Storage releases add an ImageMagick security policy through MiniMagick’s environment. Applications using this processor also need mini_magick >= 5.1; older versions cause a boot exception with the new policy integration.

Review compatibility before deployment. Applications that replace MiniMagick’s environment or shell integration can bypass the shipped policy and must carry its rules in the system policy. GraphicsMagick does not read ImageMagick policies. The new restrictions also affect PDF and PostScript processing; review the advisory before selectively restoring required features.

For exposed applications using the Disk service, the maintainers instruct operators to change secret_key_base and every secret readable by the application process. That includes the credentials master key, decrypted application credentials, database and storage credentials, and third-party tokens. Do not keep an exposed secret as a rotation fallback.

Uploaded filenames also influence external decoders

A second Active Storage advisory covers temporary files retaining attacker-chosen filename extensions. External tools could select a decoder based on that extension even when the file’s content did not identify its format.

Its exposure conditions include untrusted uploads plus audio/video analysis, video previews or ImageMagick processing. The specific file-read and code-execution path through AviSynth additionally requires an FFmpeg build with AviSynth enabled and the AviSynthPlus runtime installed.

The maintainers say common Linux-distribution and Homebrew FFmpeg packages do not enable AviSynth. That limits this particular path, while other extension-selected decoders remain relevant.

The fixes keep an uploaded extension only when it matches the recorded content type. Applications meeting the AviSynth prerequisites should also treat application-readable secrets as potentially exposed and change them. Changing secret_key_base invalidates active sessions, signed and encrypted cookies, signed global IDs and Active Storage URLs.

Both Active Storage advisories list affected versions below 8.0.5.2, and 8.1 through versions below 8.1.4.1. The corresponding fixed versions are 8.0.5.2 and 8.1.4.1. They had no assigned CVE identifiers on the reviewed pages; their GHSA identifiers preserve the exact advisory identity.

Check deployed dependencies and session caching

Update the deployed dependency set, rebuild application images and confirm the running versions. Test uploads, previews and affected document-processing workflows before considering the rollout complete.

The release also fixes a session-cookie leak in Active Storage proxy mode. It requires cookie rotation or hybrid serializer migration, plus a shared cache that stores Set-Cookie on public responses. The advisory’s workaround is to prevent caching such responses or finish and remove the migration configuration.

The full release list includes other component-specific fixes, so the upload issues are not a complete application checklist. Rails also says 8.0 security support ends November 7, 2026. Treat its emergency patch as immediate repair alongside a supported-release migration plan.

Caveat: these are the maintainers’ own disclosures; neither the advisory count nor the highest severity establishes that every Rails application exposes every flaw.