Ruby on Rails heeft een kritieke kwetsbaarheid gepubliceerd die aanvallers kan misbruiken om willekeurige bestanden op de server te schrijven. De aanval werkt via uploads, maar alleen wanneer je app de uploadverwerking koppelt aan ImageMagick via Active Storage. Rails beschouwt dit als zeer ernstig (CVSS 9.8) en geeft concrete fix-versies door.
In dit artikel lees je wat er precies misgaat, of jouw setup geraakt kan worden, en welke stappen je vandaag nog kunt nemen om risico’s te beperken.
Wat is de Rails kwetsbaarheid ImageMagick precies?
Het probleem zit in Active Storage, het Rails-onderdeel dat bestandsuploads behandelt. Wanneer je app afbeeldingen of andere media uploadt en Active Storage ze doorstuurt naar ImageMagick, kiest ImageMagick op basis van de inhoud een formatter/handler (“coder”). Sommige coders kunnen niet alleen met de afbeelding zelf omgaan, maar ook met bestanden die als naam in de afbeelding worden meegegeven.
Rails legt uit dat Active Storage geen extra beperkingen oplegt aan welke coders gebruikt mogen worden. In de praktijk is dan het beleid (policy) van ImageMagick zelf de enige echte rem. Als dat beleid niet strak genoeg is, kan een kwaadwillende upload voldoende zijn om de kwetsbare route te triggeren.
Waarom is dit zo gevaarlijk?
Rails benadrukt dat een aanvaller met deze methode niet alleen bestanden kan schrijven. In apps waar uploads via Disk-achtige opslag op schijf terechtkomen, kan zo’n keten ook uitkomen op het lezen van bestanden die de applicatie zelf kan lezen. Denk daarbij aan gevoelige data zoals:
- secret_key_base
- referenties/credentials naar andere systemen
Als een aanvaller die geheimen bemachtigt, kan dat op zijn beurt verder gaan richting remote code execution of laterale beweging in je omgeving. Rails meldt dat een aanvalsketen bij hen is gerapporteerd, maar geeft niet aan of er al daadwerkelijk exploitatie in het wild plaatsvindt.
Wanneer is jouw app mogelijk geraakt?
Volgens Rails is een app alleen beïnvloed als aan alle onderstaande voorwaarden is voldaan.
1) Je gebruikt ImageMagick voor Active Storage
Dit hangt samen met de instelling voor de variant processor. Een veelvoorkomende aanwijzing is:
config.active_storage.variant_processor = :mini_magick
Dat is volgens Rails een default bij apps met oudere load_defaults-waarden (met andere defaults afhankelijk van de versie).
2) Je ImageMagick policy blokkeert de relevante coders niet
Rails geeft aan dat beleid dat Debian en Ubuntu standaard leveren de benodigde codering niet altijd blokkeert. Met andere woorden: je kunt kwetsbaar zijn, ook als je zelf weinig aan ImageMagick “geconfigureerd” hebt.
3) Je accepteert uploads van niet-vertrouwde gebruikers
Als alleen interne gebruikers uploaden, daalt het directe misbruikscenario. Maar in veel normale webapplicaties is uploaden juist publiek of semi-publiek.
Welke Rails versies moet je updaten?
Rails heeft fixes uitgebracht in deze versies:
- Rails 8.1.4.1 of nieuwer
- Rails 8.0.5.2 of nieuwer
Rails zegt ook dat release-series ouder dan 8.0 niet meer ondersteund worden, en dat er voor die oudere lijnen geen fixed versies worden vrijgegeven.
Waarom is alleen “uploaden” genoeg?
Een belangrijk detail: de analyse in Active Storage wordt doorlopen op het moment dat een bestand wordt attached. Je applicatie hoeft geen varianten (transformaties), previews of aanvullende bewerkingen te maken. Daarmee kan de kwetsbare route al bereikt worden zodra de server de upload accepteert en verwerkt.
Wat moet je nu doen? (actiegericht)
Rails beveelt een snelle upgrade aan. Omdat er in totaal meerdere beveiligingsproblemen met deze releases worden opgelost, is dit niet alleen “nice to have”, maar een directe risicoreductie.
1) Upgrade naar de vaste Rails releases
Ga naar 8.1.4.1 of 8.0.5.2. Als je via :mini_magick werkt, moet je volgens Rails ook letten op de mini_magick-versie: die moet mini_magick 5.1 of later zijn om niet bij het opstarten te falen.
Let op de onderhoudsperiode: Rails 8.0 krijgt security fixes alleen tot 7 november 2026.
2) Controleer of het nieuwe beleid daadwerkelijk actief is
Rails schrijft voor om te bevestigen dat het policy van de fix ook echt geladen wordt. Een voorbeeld van de controle is:
bin/rails runner ‘puts MiniMagick.identify { |i| i.list “policy” }’
Als je eigen code of tooling MiniMagick anders configureert (bijvoorbeeld door cli_env of cli_prefix aan te passen, of door eigen Shell-implementaties te gebruiken), kan de shipped policy mogelijk niet landen zoals verwacht.
3) Kijk naar je server-policy én naar overrides
De policy die Rails meestuurt “voegt toe” in plaats van te vervangen. Dat betekent dat regels in je eigen ImageMagick-serverpolicy de shipped blokkade kunnen overrulen—bijvoorbeeld via een wildcard-regel.
Controleer daarom:
- de regels in policy.xml op de server
- of coders zoals de MSL-route, Ghostscript-gerelateerde coders en de gsdelegate geblokkeerd zijn
- of er geen
pattern-achtige uitzonderingen bestaan die de block ongedaan maken
4) Heb je PDF of PostScript verwerking? Dan geldt extra oplettendheid
Als je PDF of PostScript laat renderen via ImageMagick, kan je policy onderhoud of herallowing nodig hebben voor de relevante gsdelegate en coders. Doe dat alleen binnen de kaders die nodig zijn.
5) Als je nog niet kunt upgraden: implementeer het policy-workaround
Kun je (nog) niet direct upgraden, dan kun je volgens Rails de regels uit het shipped fix-policy kopiëren naar je ImageMagick system policy. Met name raden ze aan minimaal de MSL-coder, Ghostscript-coders en de gsdelegate te blokkeren.
Bij apps op release series ouder dan 8.0 is de workaround vooral een tussenstap, terwijl Rails ook aangeeft dat upgrades richting 8.0 of hoger het uiteindelijk doel zijn.
6) Beperk impact met secrets-hygiëne (zeker bij Disk-opslag)
Als jouw app uploads opslaat op schijf (Disk service) en dus gevoelig kan zijn voor het uitlezen van bestanden, is het verstandig om secret_key_base en alle overige geheimen die de app kan benaderen te vervangen. Denk aan:
- master key
- alles in
config/credentials.yml.enc - storage- en database-credentials
- tokens voor derde partijen
Rails waarschuwt om geen “blootgestelde” secret als fallback te laten bestaan.
Wat betekent dit voor je upload-architectuur?
Deze kwetsbaarheid laat vooral zien hoe belangrijk het is om uploadverwerking niet blind te vertrouwen. Wanneer je media laat analyseren door een externe tool als ImageMagick, moet je ervan uitgaan dat policy-controle echt bedoeld is voor bescherming—en niet slechts als “extra instelling”.
Wil je breder leren van soortgelijke upload- en ketenrisico’s? Lees dan ook hoe beveiligingsteams omgaan met exposure en bewijsvoering in een incidentcontext: Exposure prioritization: 4 elementen met bewijs.
Vergelijkbaar risico: andere Active Storage issues
Rails verwijst daarnaast naar een eerder kritieke Active Storage kwetsbaarheid die een ander pad betrof (via libvips in plaats van ImageMagick). Apps die ImageMagick gebruiken waren niet blootgesteld via die specifieke chain, maar kunnen wél geraakt zijn door deze nieuwe route. Dat onderstreept dat je niet alleen “het ene probleem” moet oplossen, maar actief moet zorgen dat je upload-keten consistent veilig is.
Bekijk ter illustratie ook hoe teams in de praktijk reageren op Active Storage-achtige kwesties en vervolgmaatregelen via de site: WordPress core kwetsbaarheid: actief misbruik. Hoewel dat om een ander platform gaat, gebruiken veel organisaties dezelfde aanpak: patchen, controleren en misbruikscenario’s verifiëren.
Conclusie
De Rails kwetsbaarheid ImageMagick is een serieuze security bug met een CVSS-score van 9.8. Een aanvaller met een geschikte gecreëerde upload kan, onder voorwaarden, via Active Storage bestanden op je server laten schrijven en in sommige scenario’s zelfs gevoelige informatie bereiken.
Neem daarom nu actie: upgrade naar 8.1.4.1 of 8.0.5.2, verifieer dat de policy correct is ingeladen en controleer je ImageMagick system policy op overrides. Als je nog niet kunt upgraden, implementeer het policy-workaround en vervang daarna bovendien relevante secrets waar nodig.
Bron: https://thehackernews.com/2026/11/critical-rails-flaw-lets-attackers.html
