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 deg som har en Rails-applikasjon

Har du en nettbutikk, en portal eller en fagapplikasjon bygget i Rails, gjelder denne saken deg. Slike applikasjoner finnes det flere av enn du kanskje tror. Funksjonen som utnyttes, er ikke eksotisk. Det er profilbildet, vedlegget i et søknadsskjema eller kvitteringen kunden laster opp i en sak. Berigos vurdering er at det tunge her ikke er oppgraderingen, som er triviell, men konsekvensen av at hemmeligheter kan være borte. Bytter du secret_key_base, blir signerte informasjonskapsler og aktive økter ugyldige, og det merkes av alle innloggede brukere samtidig. Det må du planlegge, ikke improvisere en fredag ettermiddag.

Det andre spørsmålet er hvem som faktisk kan svare på om du er berørt. Rails-applikasjoner er ofte bygget av et byrå eller en enkeltleverandør, og driften kan ligge et tredje sted. Da holder det ikke å vite hvilken versjon som kjører. Du må også vite hvem som eier nøkkelbyttet, og hvem som bekrefter at det er gjort. Er virksomheten din omfattet av NIS2, er dette leverandørkjeden i artikkel 21 i sin mest håndfaste form. Vi vil også minne om at datoen for fullstendige detaljer setter 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.