Kritisk hull i Rails Active Storage lot opplastede filer lese hemmeligheter

Ruby on Rails publiserte 29. juli 2026 en rettelse for en kritisk sårbarhet i Active Storage, komponenten som håndterer filopplasting og bildebehandling i Rails-applikasjoner. Varselet GHSA-xr9x-r78c-5hrm er tildelt CVE-2026-66066 og satt til CVSS-verdi 9,5. En angriper uten pålogging kan laste opp en spesiallaget fil og få lest filer fra tjeneren, blant dem programnøkkelen secret_key_base, passord til databasen og legitimasjon til skytjenester. Rettelsen ligger i versjonene 7.2.3.2, 8.0.5.1 og 8.1.3.1. Applikasjoner er utsatt når de bruker biblioteket libvips til å behandle bilder og tar imot opplastinger fra brukere virksomheten ikke kontrollerer.

Hva som skjer teknisk

Active Storage lager varianter av opplastede bilder, altså nedskalerte eller beskårne utgaver til visning på nettsiden. Selve bildearbeidet settes bort til et bildebibliotek, og libvips er det biblioteket nyere Rails bruker. libvips har et sett operasjoner som er merket som utrygge for innhold man ikke stoler på, og biblioteket har derfor en egen bryter for å blokkere dem. Varselet beskriver at Active Storage ikke slo av disse operasjonene i standardoppsettet.

Angrepet følger av dette. En fil som er laget for formålet, kan få variantgenereringen til å kalle en av de utrygge operasjonene, og resultatet er lesing av filer som applikasjonsprosessen selv har tilgang til. I en vanlig Rails-applikasjon betyr det konfigurasjon og miljøvariabler, altså secret_key_base, tilkoblingsstrengen til databasen og nøkler til skytjenester. Rails oppgir at det finnes en midlertidig omgåelse for installasjoner med libvips 8.13 eller nyere, i form av miljøvariabelen VIPS_BLOCK_UNTRUSTED eller et kall til Vips.block_untrusted i en oppstartsfil. Eldre utgaver av libvips har ingen omgåelse og må oppgraderes. Varselet er tydelig på et punkt som lett blir glemt i en travel uke. Oppdateringen beskytter ikke hemmeligheter som allerede kan være hentet ut, og de må derfor byttes. Fullstendige tekniske detaljer er varslet offentliggjort innen 28. august 2026.

Hva det betyr for virksomheten

Denne saken angår enhver virksomhet som har en nettbutikk, en portal eller en fagapplikasjon bygget i Rails, og det er flere enn man skulle tro. Funksjonen som utnyttes, er ikke eksotisk. Det er profilbildet, vedlegget i et søknadsskjema eller kvitteringen kunden laster opp i en sak. Det som gjør saken tung, er ikke oppgraderingen, som er triviell, men konsekvensen av at hemmeligheter kan være borte. Bytte av secret_key_base gjør signerte informasjonskapsler og aktive økter ugyldige, og det merkes av alle innloggede brukere samtidig. Slikt må planlegges, ikke improviseres en fredag ettermiddag.

Det andre poenget er hvem som faktisk kan svare på om dere er berørt. Rails-applikasjoner er ofte bygget av et byrå eller en enkeltleverandør, og driften kan ligge et tredje sted. Da er spørsmålet ikke bare hvilken versjon som kjører, men hvem som eier nøkkelbyttet og hvem som bekrefter at det er gjort. For virksomheter under NIS2 er dette leverandørkjeden i artikkel 21, i sin mest håndfaste form. Datoen for fullstendige detaljer setter dessuten en klokke i gang, siden utnyttelseskode gjerne følger kort tid etter at detaljene er ute.

Berigo anbefaler

• Kartlegg hvilke Rails-applikasjoner virksomheten har, både egenutviklede og leverte, og hvilke versjoner de kjører.
• Oppgrader Active Storage til 7.2.3.2, 8.0.5.1 eller 8.1.3.1, og libvips til 8.13 eller nyere.
• Bytt secret_key_base, hovednøkler og all legitimasjon som er lesbar fra tjeneren, og regn med at brukerne må logge på igjen.
• Bruk den midlertidige blokkeringen av utrygge operasjoner der oppgradering må vente, forutsatt at libvips er ny nok.
• Be leverandøren bekrefte skriftlig at både oppdatering og nøkkelbytte er gjennomført, med dato.