Un 9,5 a Rails: la fallada no és a la teva aplicació, és a la biblioteca que ningú va triar

Algú puja una foto. L'avatar del seu perfil, l'adjunt d'un tiquet, la imatge d'un producte al teu portal de clients. La teva aplicació fa el que fa des de fa tres anys: generar la miniatura. I en aquest gest —el més banal que existeix en un web— un atacant sense usuari ni contrasenya s'endú el contingut de fitxers del servidor, començant per les variables d'entorn del procés: la clau que signa les sessions, la de la base de dades, les de l'emmagatzematge al núvol. Això és la CVE-2026-66066, un 9,5 publicat el 29 de juliol. El que ens sembla interessant no és la nota. És on és la fallada: ni al codi que vas encarregar, ni exactament a Rails, sinó a quins formats considera segur llegir una biblioteca de C que ningú de la teva empresa va triar, ni sap que corre, ni sabria anomenar. Una biblioteca que, a més, des del 2022 publica quines de les seves operacions no ha verificat contra entrades hostils, i porta de sèrie un interruptor per bloquejar-les.

Els fets, sense adorns

Tal com els publica l'avís oficial de Rails. Abans d'opinar, les dades:

• CVE-2026-66066, publicada el 29 de juliol del 2026. CVSS 4.0 de 9,5, crítica. Categoria: lectura de fitxers arbitraris i possible execució remota de codi en el processament de variants de l'Active Storage.
• Versions afectades: activestorage anterior a 7.2.3.2, la branca 8.0 anterior a 8.0.5.1 i la branca 8.1 anterior a 8.1.3.1. Corregit en aquestes tres. Rails 6.x només hi entra si l'Active Storage està configurat fora dels seus valors per defecte —i aquí arriba el detall que deixa penjat qui sigui en aquesta branca: Rails no ha publicat versions corregides per a res anterior a la 7.2, així que a 6.x no hi ha pedaç, només mitigació o migració.
• Calen tres condicions alhora, segons els investigadors: que l'aplicació processi variants d'imatge amb libvips, que accepti pujades d'imatges d'usuaris no fiables —per funcionalitat pròpia o per pujada directa— i que el libvips instal·lat estigui enllaçat contra certes biblioteques de tercers. Amb el processador ImageMagick (MiniMagick) aquesta no s'aplica.
• Compte amb la segona condició. Rapid7 avisa que la cadena documentada necessita que la ruta de pujada directa de l'Active Storage sigui accessible, i aquesta ruta hi és per defecte quan l'Active Storage està muntat, encara que la interfície de la teva aplicació no faci servir pujades directes. Dit d'una altra manera: «nosaltres no deixem pujar imatges» pot ser cert a la pantalla i fals a l'enrutador.
• Què aconsegueix l'atacant: la divulgació del contingut de fitxers arbitraris accessibles al sistema de fitxers amb l'usuari del procés, incloses les seves variables d'entorn —on solen viure secret_key_base, la clau mestra, les credencials de base de dades, les de l'emmagatzematge i tokens de tercers—. D'aquí, l'escalada a execució de codi i a moviment lateral cap a altres sistemes.
• Ho van reportar els investigadors 0xacb, s3np41k1r1t0 i castilho, d'Ethiack, i RyotaK, de GMO Flatt Security. La divulgació completa estava prevista per al 28 d'agost com a molt tard; van aparèixer proves de concepte públiques abans d'hora i Rails va acabar publicant els detalls i una eina forense a finals de juliol, en un repositori propi.

Un detall que canvia la mida del problema: des de Rails 7.0 el processador de variants per defecte és Vips —a 6.x era ImageMagick—, i libvips és a més el processador per defecte a les imatges Docker oficials de Rails i als muntatges de Debian i Ubuntu. La configuració vulnerable no és una raresa que algú va activar expressament: és el que ve de sèrie. Amb un matís que convé comprovar abans de donar res per fet: aquest valor per defecte va lligat a config.load_defaults i no al número de versió de la gemma, així que una aplicació migrada a 7.2 que encara declari load_defaults 6.1 continua fent servir ImageMagick.

L'etiqueta ja hi era

Aquí hi ha la part que mereix llegir-se dues vegades, i és la raó per la qual dediquem un article sencer a una CVE d'un framework que potser ni fas servir. Ho explica el mateix avís: libvips llegeix i escriu formats a través de loaders i savers, molts d'ells sostinguts per biblioteques de tercers, i marca algunes d'aquestes operacions com a «unfuzzed» —sense fuzzing, és a dir, no sotmeses a proves amb entrades hostils i per tant no segures per a contingut no fiable—. El que va fallar és que l'Active Storage no les desactivava.

I aquest mecanisme no és d'aquest estiu: arriba amb libvips 8.13, publicada el 28 de maig del 2022, amb un anunci que explicava que amb la variable VIPS_BLOCK_UNTRUSTED s'impedeix executar qualsevol operació etiquetada com a no fiable, per poder desplegar «amb la confiança que no s'està exposant codi sense fuzzejar a dades d'internet». Quatre anys. La informació de seguretat existia: publicada, al lloc correcte, amb el nom correcte, marcada operació per operació per qui millor coneixia el codi, i amb l'interruptor posat. El que no existia era la decisió d'accionar-lo a la baula següent. Això no és un desbordament de memòria exòtic que ningú podia preveure; és una etiqueta d'advertiment que la capa de dalt no va consumir. I la distinció importa, perquè les etiquetes es poden llegir i els desbordaments no es poden endevinar.

Per si queda dubte que aquesta lectura no és una mania nostra: la categoria que han assignat a la fallada és CWE-1188, «inicialització d'un recurs amb un valor per defecte insegur». No «lectura de fitxer fora de rang», no «validació insuficient de l'entrada». El nom oficial del problema apunta al valor per defecte.

Ara compta les baules de la cadena que acaba al teu servidor. La teva empresa va encarregar una aplicació. Qui la va fer va triar Rails. Rails va triar l'Active Storage. L'Active Storage va triar libvips com a processador per defecte. I libvips crida biblioteques de tercers diferents per a cada format d'imatge. Cinc decisions, i la teva empresa només va prendre la primera. La superfície d'atac de la teva aplicació la van decidir quatre projectes que no coneixes, amb bon criteri i de bona fe, resolent problemes que no eren el teu.

Res d'això no és un retret: ni libvips ni Rails ho van fer malament aquí. libvips va etiquetar el que no havia verificat, que és exactament el que un espera d'una biblioteca seriosa. Rails va pedaçar tres branques alhora, va donar una mitigació provisional que no obliga a tocar codi i, quan li van forçar el calendari amb exploits públics, va publicar els detalls i una eina forense en lloc de callar. Això és fer-ho bé. El problema no és a cap baula: és que ningú no és responsable de la unió entre dues.

T'afecta? Se sap en deu minuts

Abans del sobresalt, la comprovació. Ben bé pot ser que aquesta no vagi amb tu, i dir-ho és part de la feina: un avís crític que no s'aplica al teu cas, tractat com si s'apliqués, et gasta la setmana i el crèdit. Quatre comprovacions, executades dins de la màquina o el contenidor que serveix producció ara mateix —amb docker exec o kubectl exec si cal—, no al portàtil de qui va programar ni a la branca principal del repositori:

# 1) Versió REAL d'activestorage a l'entorn que serveix producció
bundle list | grep -i activestorage
grep "^    activestorage " Gemfile.lock

# 2) Processador de variants configurat: vips (afectat) o mini_magick (no)
grep -rn "variant_processor" config/

# 3) De quina versió de defaults tira l'app (decideix el valor per defecte de dalt)
grep -rn "load_defaults" config/application.rb

# 4) Versió de libvips REAL. Si el binari no existeix, pregunta a la biblioteca
vips --version 2>/dev/null || bundle exec ruby -e 'require "vips"; puts Vips::LIBRARY_VERSION'

Dues trampes en aquestes quatre línies, i totes dues empenyen cap al fals «no m'afecta». La primera: si la comprovació 2 no torna res, no estàs fora de perill, estàs al valor per defecte —i amb load_defaults a 7.0 o posterior aquest valor per defecte és Vips—. La segona: que vips no existeixi com a ordre no vol dir que no tinguis libvips. El binari va en un paquet a part (libvips-tools a Debian i Ubuntu) i ruby-vips parla directament amb la biblioteca, així que la imatge típica d'una aplicació Rails té libvips i no té vips. D'aquí la segona meitat de la línia 4.

L'última pregunta la contesta un humà, no una ordre: algú de fora pot pujar una imatge? Un formulari de contacte amb adjunt, l'avatar d'una àrea privada, el portal on els clients pugen albarans. I recorda això de la ruta de pujada directa: la resposta correcta no és la de la pantalla, és la de l'enrutador. Un avís honest per acabar: aquestes comprovacions et diuen què tens, no si ja hi han entrat. Per al segon hi ha l'eina forense que va publicar Rails, i calen registres que moltes aplicacions no guarden.

El que pots desplegar avui no és el pedaç

Tots els titulars diuen «actualitza ja», i tenen raó de fons. En l'ordre, no del tot. Perquè en una aplicació de negoci feta a mida, actualitzar el framework i canviar una variable d'entorn no costen el mateix ni triguen el mateix, i qui decideix ho ha de saber:

1. Avui: la mitigació provisional. L'avís proposa bloquejar les operacions no verificades de dues maneres, i la diferència entre elles no és cosmètica. La variable d'entorn VIPS_BLOCK_UNTRUSTED és un canvi a l'entorn d'execució: es desplega sense tocar el codi de l'aplicació, que és just el que cal quan el codi el manté un altre. La crida Vips.block_untrusted(true) fa el mateix però va en un initializer, o sigui que sí que és tocar codi i sí que passa pel cicle de release. Totes dues requereixen libvips 8.13 o superior; la segona, a més, ruby-vips 2.2.1 o superior.
2. Aquesta setmana: el pedaç de debò. Pujar activestorage a 7.2.3.2, 8.0.5.1 o 8.1.3.1, i comprovar que libvips a la imatge del contenidor és 8.13 o superior. Rapid7 ho diu sense embuts i val la pena subratllar-ho perquè és l'error que més veurem: actualitzar Rails o l'Active Storage per si sol no n'hi ha prou si la versió de libvips instal·lada és antiga. Si tens proves automàtiques i desplegament reproduïble, és una tarda. Si l'aplicació es desplega a mà des del 2022 i no hi ha bateria de proves, no és una tarda: és un projecte petit, i convé dir-ne el nom en comptes de prometre divendres.
3. Amb calendari: rotar. Va al seu propi apartat més avall, perquè és la part que gairebé ningú no fa, i no per mandra.

Un advertiment sobre el punt u que gairebé no hem vist a les cobertures: bloquejar les operacions no verificades pot fer que deixi de processar-se algun format rar que avui sí que processes. Això no és un efecte secundari molest, és una decisió que cal prendre amb els ulls oberts —i la nostra resposta és fàcil: preferim que falli una miniatura abans que no pas que algú llegeixi l'entorn del procés—. Però prova-ho abans a preproducció i mira els registres el primer dia.

Rotar és la part cara. Per això no es fa

L'avís és explícit: cal canviar tots els secrets que el procés podia llegir. secret_key_base, les claus mestres, les credencials de serveis i de base de dades, els tokens de tercers. És el correcte i és el que menys es compleix, per una raó molt pràctica que gairebé mai s'esmenta: secret_key_base és el que signa i xifra les galetes de sessió d'una aplicació Rails. Canviar-ho no és editar una línia: és decidir què passa amb totes les sessions obertes de tots els usuaris en aquell moment.

I la resta de credencials sol viure en més llocs dels que diu l'inventari: al sistema que desplega, al gestor de contrasenyes del proveïdor que va fer l'aplicació, en un fitxer de configuració del portàtil d'algú que ja no hi és. Si tens un servidor de CI/CD, bona part del que cal rotar avui també és allà dins, i rotar en un lloc i no a l'altre és no haver rotat.

No tenim cap dada de quantes aplicacions Rails corren a pimes catalanes ni de quin percentatge rotarà res aquest mes. No ho hem mesurat i no ens ho inventarem. El que sí que veiem, quan ens asseiem a mirar-ho amb algú, és que la pregunta «en quant de temps podries canviar totes les credencials d'aquesta aplicació?» gairebé mai té una resposta en hores o dies; té una pausa llarga i una ganyota. I aquí hi ha la mesura honesta de la teva exposició: no és «estem pedaçats?», és quant trigaries a rotar. Aquest número et diu què et costaria una fuita, la d'aquesta CVE o la de la següent.

On acaba el teu contracte de manteniment

Aquí el tema deixa de ser de Rails. Un contracte de manteniment informàtic normal cobreix servidors, còpies, antivirus, la xarxa i el lloc de treball. I s'atura, amb tota naturalitat, just on comença l'aplicació de negoci: perquè «l'aplicació és del proveïdor que la va fer». El proveïdor que la va fer, per la seva banda, va lliurar, va facturar i va tancar el projecte fa tres anys. Resultat: l'únic programari de la casa que atén peticions d'Internet, processa fitxers de desconeguts i té les credencials de la base de dades és l'únic que no és a cap calendari de pedaçat.

No és mala fe de ningú. És un buit de contracte, i es tanca escrivint-lo. Quan fem aquest inventari amb un client, a la columna d'«aplicacions» hi posem cinc coses, i cap no és glamurosa:

Això és, a la pràctica, el que fem a dades i aplicacions: tractar l'aplicació de negoci com un sistema en producció i no com un lliurable tancat, amb la mateixa disciplina avorrida que se li demana a un servidor. I dir-ho amb honestedat: nosaltres no desenvolupem en Rails, així que no venim a vendre't cap migració. La part de decidir què es pedaça primer, amb quina exposició real i amb quines credencials a dins, és ciberseguretat del muntó, de la que no surt als fullets.

Un 9,5 no és el teu risc. Però aquí hi ha exploit públic

Ho vam dir amb els 622 pedaços d'un sol dimarts de juliol i ho repetim aquí perquè no ha canviat: el CVSS és una etiqueta de gravetat tècnica en el pitjor cas, no una mesura del teu risc. Mesura què passa si es donen les condicions, no si tu les dónes. Per això la comprovació de deu minuts va abans que el sobresalt.

I aquí toca ser precís, perquè els titulars barregen dues coses que no són la mateixa. Explotació real, que se sàpiga, no n'hi ha: Rapid7 deia el 30 de juliol que no en tenia constància, i això no és al catàleg KEV de CISA. El que sí que ha caducat és el «sense exploit públic»: circula codi que diu que ho explota, encara que —matís del mateix Rapid7— no està clar quant s'assembla a la cadena completa que els investigadors van lliurar en privat a Rails. I el mateix Rapid7 ha verificat l'escalada a execució remota i ha proposat un mòdul de Metasploit per fer-la.

Aquesta distinció no és un tecnicisme: és la diferència entre tenir dies i tenir setmanes. Els investigadors s'havien guardat la cadena tècnica fins a finals d'agost precisament per donar marge, i el marge es va evaporar sol. Quan la condició d'entrada és «accepta pujades d'imatges», el mòdul de Metasploit converteix una cadena difícil en un botó, i aquest és el moment en què el nombre de gent capaç d'intentar-ho es multiplica. No cal pintar una explotació massiva que avui no existeix per justificar mirar-s'ho aquesta setmana.

Tres anys funcionant sense donar problemes

La frase que més cops hem sentit sobre una aplicació de negoci és aquesta: «fa tres anys que funciona sense donar problemes». I és veritat, i és exactament el motiu pel qual ningú no la mira. Un servidor que no dóna problemes igualment surt al llistat de pedaços del mes; una aplicació que no dóna problemes desapareix del radar del tot, perquè el seu únic senyal de vida era donar problemes.

La nostra proposta és més modesta que un pla de seguretat i cap en una reunió de mitja hora. Agafa l'aplicació de la qual més depèn el teu negoci i contesta tres coses per escrit: quina versió del framework corre avui a producció, qui decideix quan s'actualitza i quant trigaríeu a canviar-li totes les contrasenyes. Si surt, enhorabona, no necessites aquest article. Si no surt —i el normal és que no surti—, ja tens les tres primeres línies de l'inventari, i les tens sense que t'hagi passat res. Que és, de llarg, el moment més barat d'escriure-les. I si prefereixes que les tres respostes les busquem amb vosaltres, aquí som.

Fonts (verificades el 3 d'agost del 2026): les dades de la vulnerabilitat surten de l'avís de seguretat oficial de Rails GHSA-xr9x-r78c-5hrm, publicat el 29 de juliol del 2026 (CVE-2026-66066; CVSS 4.0 de 9,5; versions afectades i corregides 7.2.3.2, 8.0.5.1 i 8.1.3.1; l'explicació dels loaders i savers de libvips sostinguts per biblioteques de tercers i de les operacions marcades com a «unfuzzed», no segures per a contingut no fiable, que l'Active Storage no desactivava; l'impacte de lectura de fitxers arbitraris incloses les variables d'entorn amb secret_key_base i credencials; les mitigacions VIPS_BLOCK_UNTRUSTED i Vips.block_untrusted(true) amb libvips 8.13 o superior i ruby-vips 2.2.1 o superior; la petició de canviar tots els secrets; i el crèdit a 0xacb, s3np41k1r1t0 i castilho, d'Ethiack, i a RyotaK, de GMO Flatt Security). El calendari de divulgació —detalls previstos per al 28 d'agost com a molt tard, proves de concepte públiques abans d'hora i publicació anticipada dels detalls i de l'eina forense— i el matís que Rails 6.x només hi entra si l'Active Storage està configurat fora dels seus valors per defecte, de la cobertura de BleepingComputer de l'1 d'agost del 2026. Que només afecta el processador Vips i no les aplicacions que fan servir Magick, i les tres condicions (libvips, pujades d'usuaris no fiables per funcionalitat o pujada directa, i un libvips enllaçat contra certes biblioteques de tercers), les precisa la nota dels investigadors d'Ethiack, que van retenir a propòsit la cadena tècnica i el PoC. De l'anàlisi de Rapid7 prenem la classificació CWE-1188 («inicialització d'un recurs amb un valor per defecte insegur»), que a 30 de juliol del 2026 no tenia constància d'explotació a la pràctica, que existeix codi públic que diu que ho explota però no està clar quant s'assembla a la cadena completa lliurada en privat a Rails, que la ruta de pujada directa de l'Active Storage ha de ser accessible i hi és per defecte encara que la interfície de l'aplicació no faci servir pujades directes, que Rails no ha publicat versions corregides per a les branques anteriors a la 7.2, que actualitzar Rails o l'Active Storage per si sol no n'hi ha prou amb un libvips antic, i la verificació de l'escalada a execució remota amb el mòdul proposat per a Metasploit. Que config.active_storage.variant_processor va passar a :vips per defecte a Rails 7.0 (era :mini_magick a 6.x), lligat a config.load_defaults, és a la guia de configuració de Rails; que libvips és el processador per defecte a les imatges Docker oficials de Rails i a Debian i Ubuntu, a BleepingComputer. El mecanisme de bloqueig i la seva data —VIPS_BLOCK_UNTRUSTED introduït a libvips 8.13, publicada el 28 de maig del 2022—, inclosa la cita sobre desplegar «amb la confiança que no s'està exposant codi sense fuzzejar a dades d'internet», surten de l'anunci de la mateixa libvips. Són criteri i opinió nostres, no de les fonts: que el rellevant d'aquest cas és que l'advertiment («unfuzzed») ja estava publicat i el que faltava era consumir-lo a l'baula següent; el compte de les cinc decisions de la cadena de dependències; l'ordre mitigar avui / pedaçar aquesta setmana / rotar amb calendari, i l'avís que bloquejar operacions no verificades pot trencar el processament d'algun format; que la mesura honesta de l'exposició és quant trigaries a rotar i no si estàs pedaçat; i la lectura del buit entre el contracte de manteniment i el proveïdor que va desenvolupar l'aplicació, amb la llista de cinc punts de l'inventari. No hem comptat quantes aplicacions Rails hi ha en producció a pimes catalanes, ni quantes rotaran credencials, ni tenim incidents propis d'aquesta CVE: no ho hem mesurat i no ho inventem. everyWAN no desenvolupa en Ruby on Rails. Foto de portada: «Man Working in Photographic Laboratory», State Government Photographer, Wikimedia Commons, CC0 1.0.