A Ruby on Rails kiadta a javításokat egy kritikus Active Storage sebezhetőségre, amely lehetővé teszi, hogy hitelesítetlen támadók gondosan összeállított képfeltöltésekkel tetszőleges fájlokat olvassanak az alkalmazásszervereken.

A CVE-2026-66066 azonosítón (CVSS pontszám: 9,5) követett hiba hozzáférést adhat a Rails folyamat környezeti változóihoz és olyan titkokhoz, mint a secret_key_base, a Rails master key, az adatbázis-jelszavak, a felhőtárhely-hozzáférések és az API tokenek. Ezek a titkok távoli kódfuttatást (RCE) vagy oldalirányú mozgást tehetnek lehetővé a kapcsolódó rendszerekben.

Az érintett alkalmazások libvips-t használnak Active Storage képfeldolgozáshoz, és elfogadnak képfeltöltéseket nem megbízható felhasználóktól. Rails alatt a load_defaults 7.0 beállításnál a Vips az alapértelmezett, és a későbbi alapértelmezett beállítások is ezt tartják meg.

Az Ethiack és a GMO Flatt Security szerint az érintett verziók: Rails 7.0.0–7.2.3.1, Rails 8.0.0–8.0.5 és Rails 8.1.0–8.1.3. A Rails 6.0.0–6.1.7.10 kiadások csak akkor érintettek, ha az Active Storage-t Vips használatára konfigurálták, mivel a Rails 6-ban nem ez volt az alapértelmezett processzor.

Az Ethiack a The Hacker Newsnak elmondta, hogy a kutatásában említett Debian, Ubuntu és a Rails által generált Docker környezetek alapértelmezés szerint tartalmazzák a szükséges könyvtárakat, ezért érintettek a sebezhetőségben. Más disztribúciók és base image-ek lehet, hogy nem kihasználhatók.

A Rails Security Team a The Hacker Newsnak megerősítette, hogy a kutatók által megadott érintett verziótartomány pontos. Közölték, hogy a nyilvános figyelmeztetés a biztonsági támogatás alatt álló Rails kiadásokra vonatkozik, vagyis a Rails 7.2, 8.0 és 8.1 verziókra, miközben a Rails 6.x is érintett, ha engedélyezték a Vips használatát, ami akkoriban nem volt alapértelmezett. A MiniMagick-et használó alkalmazások ezen a konkrét támadási útvonalon keresztül nem érintettek. A Rails 7.1 és korábbi verziói már életciklusuk végén járnak, nem kapnak visszaportolt javítást, ezért az érintett alkalmazásokat Rails 7.2.3.2 vagy újabb verzióra kell frissíteni.

Az üzemeltetőknek Rails 7.2.3.2, 8.0.5.1 vagy 8.1.3.1 verzióra kell verziófrissítést végezniük, és minden olyan titkot rotálniuk kell, amelyet az alkalmazásfolyamat olvasni tud. A javított telepítésekhez libvips 8.13 vagy újabb, valamint – ha telepítve van a ruby-vips – ruby-vips 2.2.1 vagy újabb verzió szükséges.

2026. július 29-én 17:30 UTC-ig egyik kutatócsoport sem tett közzé proof-of-conceptet (PoC). Egy harmadik fél által publikált GitHub repository, amely a fenti időpont után jelent meg, azt állítja, hogy teljes egészében reprodukálja a tetszőleges fájlolvasástól az RCE-ig tartó láncot egy csak loopbacken elérhető Docker laborban, Rails 8.1.3 használatával, Rails 8.1.3.1-gyel mint javított kontrollal. A kód egy speciálisan összeállított MATLAB/HDF5 feltöltést használ a Rails folyamat környezetének kiolvasására, a SECRET_KEY_BASE visszanyerésére, egy beágyazott Marshal payload aláírására, majd egy out-of-band curl callback kiváltására.

A The Hacker News önállóan nem ellenőrizte a PoC-t. Az Ethiack időközben közzétette a saját láncát, amely ugyanazt a MATLAB/HDF5 fájlolvasási primitívet használja, de az RCE-t a CVE-2025-24293 sebezhetőségen keresztül éri el, nem pedig a harmadik fél repository-jában használt Marshal payloaddal.

Az Ethiack egy új technikai elemzésben azt írja, hogy a fájlolvasási primitív egy speciálisan összeállított MAT v7.3 fájlt használ, vagyis egy HDF5 konténert, amely egy külső datasetet mutat a támadó által választott fájlútvonalra. A payload a libvips által elvárt, szó szerinti MATLAB 5.0 sztringgel kezdődik, miközben a verziómezője miatt a libmatio HDF5-ként dolgozza fel, és követi a külső hivatkozást.

A direct-upload útvonalon az Active Storage elfogadja a kliens által megadott content_type értéket, így a támadó image/png-ként jelölheti a MAT payloadot. Az Ethiack szerint ezután egy legitim variation key újrajátszható a rosszindulatú blob ellen, ami arra készteti az Active Storage-t, hogy libvips-szel dolgozza fel, és a célfájl bájtjait a generált képpontokon keresztül adja vissza.

A hiba az Active Storage és a libvips közötti bizalmi határon helyezkedik el. A Rails security advisory szerint a libvips különböző loader, saver és egyéb műveleteket támogat, amelyek közül néhány harmadik féltől származó könyvtárakra épül, és „unfuzzed” vagy „untrusted” jelölést kapott, mert nem biztonságos ellenséges bemenet esetén. Az Active Storage nem tiltotta ezeket, így egy gondosan összeállított feltöltés képes volt ilyen műveletet meghívni, és kiolvasni a Rails worker által olvasható fájlokat.

Az érintett alkalmazásnak nem kell külön átméretezési vagy thumbnail funkciót kínálnia. „A variánsok generálása nem külön követelmény” – közölte a Rails. A nyilvános patch azt is megmutatja, hogy a Vips analyzer és a transformer is átadta a nem megbízható csatolmányokat a nem biztonságos műveleteknek.

Egy sikeres kérés tetszőleges fájlolvasási primitívet ad a támadónak. Az Ethiack szerint az RCE-lánc ezt a hozzáférést használja ki arra, hogy visszanyerje a secret_key_base értékét a titkosított credentialökből vagy a folyamat környezetéből, hamisítson egy rosszindulatú variation key-t, majd kihasználja a CVE-2025-24293 sebezhetőséget. A cég szerint a Vips transformer lehetővé tette, hogy a hamisított variáció meghívja az

instance_eval függvényt, és Ruby kódot futtasson. A Rails azt javasolja az üzemeltetőknek, hogy rotálják a secret_key_base-t, a master key-t és a visszafejtett credentialöket, az adatbázis-hozzáféréseket, az Active Storage szolgáltatási kulcsait és a harmadik felektől származó tokeneket.

A patch az Active Storage indulásakor meghívja a Vips.block_untrusted(true) függvényt. Azok az alkalmazások, amelyek nem tudnak azonnal Rails verziófrissítést végezni, beállíthatják a VIPS_BLOCK_UNTRUSTED változót, ha libvips 8.13 vagy újabb verziót futtatnak, vagy meghívhatják a Vips.block_untrusted(true) függvényt ruby-vips 2.2.1 vagy újabb verzióval. A Rails szerint a korábbi libvips verziók nem tudják blokkolni ezeket a műveleteket, ezért az alkalmazásoknak frissíteniük kell a libvips-t, vagy el kell távolítaniuk azt az alkalmazásból. A Rails egy forensic toolkitet is közzétett, amellyel megállapítható az alkalmazás érintettségi időablaka, és átvizsgálható az object storage és az Active Storage rekordok az esetleges kihasználás nyomai után kutatva.

A Rails André Baptistát, Bruno Mendest és Rafael Castilhót ( Ethiack ), valamint RyotaK-t ( GMO Flatt Security ) nevezte meg, mint akik egymástól függetlenül jelentették a problémát. Az Ethiack mostanra közzétette a korábban visszatartott rosszindulatú formátumot, a fájlolvasási módszert és az RCE-láncot.

A Rails Security Team a The Hacker Newsnak azt mondta, hogy nem tud sem sikeres, sem megkísérelt kihasználásról a nyilvánosságra hozatal előtt vagy után. Azt is közölték, hogy a Rails nem gyűjt telemetriát, és nincs megbízható becslése arról, hány alkalmazás használ Active Storage-t Vips-szel, és fogad el nem megbízható képfeltöltéseket. Az Ethiack a The Hacker Newsnak elmondta, hogy július 22-én jelentette először a sebezhetőséget a Railsnek. Az új elemzés szerint a cég július 21-én fejezte be az első működő PoC-t, a Rails pedig július 23-án nyugtázta a bejelentést.

A The Hacker News 2026. július 29-én 17:30 UTC-kor végzett ellenőrzése szerint a CVE-2026-66066 nem szerepelt a CISA Known Exploited Vulnerabilities katalógusának 2026.07.27-es verziójában.

Nem áll rendelkezésre megbízható becslés az érintett alkalmazások számáról vagy konkrét áldozatokról. A 9,5-ös pontszám a CVSS szerinti súlyosságot írja le, nem pedig az érintett telepítések számát: egy telepítés csak akkor sebezhető, ha Vips-t használ, elfogad nem megbízható képfeltöltéseket, és a libvips build tartalmaz egy kihasználható műveletet.