Redis: el pedaç feia 164 dies que estava publicat

El 16 i 17 d'octubre, uns esquers van registrar intents repetits contra una fallada de Redis. El pedaç d'aquella fallada es va publicar el 5 de maig. Entre una data i l'altra hi ha 164 dies. Del retard ja en sabem prou tots; el que val la pena mirar és quina informació tenia al davant, durant aquells 164 dies, qui va decidir que allò podia esperar. Eren dues notes de severitat i una fitxa oficial. Les dues notes no es poden comparar entre si, i la fitxa continua avui igual que el 6 de maig.

Què es trenca exactament

La fallada és CVE-2026-25243 i viu a l'ordre RESTORE, la que reconstrueix una clau a partir d'un valor serialitzat. La descripció del NVD, tal qual: «l'ordre RESTORE no valida correctament els valors serialitzats. Un atacant autenticat amb permís per executar RESTORE pot proporcionar una càrrega útil serialitzada manipulada que desencadena un accés a memòria no vàlid i pot conduir a l'execució remota de codi». Està classificat com a CWE-122, desbordament de memòria intermèdia al munt. La mateixa tanda de maig en portava quatre més: dos usos després d'alliberar —un al flux de desbloqueig de clients, l'altre a Lua— i dues variants del mateix RESTORE quan hi intervenen els mòduls RedisTimeSeries i RedisBloom.

La mitigació oficial, també literal, cap en una línia: «restringir l'accés a l'ordre RESTORE amb regles ACL». Red Hat ho diu amb més fil: limitar l'execució de RESTORE «exclusivament a usuaris administratius i d'alta confiança». És la part útil de l'avís, i hi tornarem.

Un apunt abans de continuar, perquè ho vam trobar en contrastar les fonts i no ho hem vist escrit enlloc: el registre del CVE descriu aquesta fallada com un accés a memòria no vàlid a RESTORE, però els crèdits del mateix avís de Redis atribueixen el mateix identificador a una altra cosa —un double-free trobat per Emil Lerner i, a més, un desbordament d'enters i una lectura fora de límits a VectorSets, de Joseph Surin—. És el mateix número per a troballes que no són la mateixa troballa. No canvia el que has de fer, però sí que convé saber-ho si algun dia proves de casar un identificador amb una línia de codi.

Dues notes que no es poden restar

El mateix CVE porta dues puntuacions diferents segons qui el signi:

La temptació és llegir-ho com un desacord: uns diuen que és difícil d'explotar i els altres que és fàcil. No ho és, i la diferència importa. El 7,7 està calculat en CVSS 4.0 i el 8,8 en CVSS 3.1, que són dos reglaments diferents en què la casella AC no vol dir el mateix. A la 3.1, la complexitat de l'atac barrejava dues coses: les defenses que cal esquivar i les condicions del desplegament que s'han de donar. La 4.0 les va separar: va deixar a AC només la primera —«evadir o esquivar condicions de seguretat ja existents», del tipus ASLR o DEP— i va treure la segona a una mètrica nova, AT.

Mira llavors el vector sencer del 7,7: AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H. Aquell AT:N vol dir «l'atac funciona a la majoria d'instàncies». És a dir: qui va posar el 7,7 va dir el mateix que el NVD sobre l'única cosa que t'afecta —que no calen condicions estranyes perquè això funcioni a casa teva— i va marcar AC:H perquè, sent un desbordament al munt, cal barallar-se amb les proteccions de memòria. Per a una fallada d'aquest tipus, en el reglament de la 4.0, aquella és la resposta correcta. No hi ha dues opinions sobre el món: hi ha dues escales.

I aquí hi ha el problema de debò, que no és de Redis ni del NVD sinó teu i nostre: aquells dos números acaben a la mateixa columna del mateix full de càlcul, i algú l'ordena de més gran a més petit. A la majoria de llocs per on passem, el criteri escrit diu alguna cosa com ara «es pedaça en 15 dies el que superi 9,0». Un 7,7 no hi entra. Un 8,8 tampoc, en molts. Ningú no mira de quina versió de l'estàndard surt cada xifra, entre altres coses perquè l'eina que les agrega tampoc no ho diu. Un punt i un decimal decideixen la finestra de manteniment, i resulta que aquell punt i aquell decimal són, en bona part, un canvi de reglament del 2023.

Si el que buscaves era la casella que sí que prediu si t'atacaran, a CVSS 4.0 existeix i es diu E, maduresa de l'exploit. En aquest CVE és sense definir, E:X. Ningú no la va omplir.

La fitxa que ningú no va tornar a tocar

Hi ha un tercer document, i és el que pitjor ha envellit. El 6 de maig —un dia després de publicar-se el pedaç— CISA va deixar registrada la seva valoració SSVC d'aquest CVE amb tres caselles: exploitation: none, automatable: no i technicalImpact: total. Traduït: no es veu explotació, no esperem que s'automatitzi a escala, però si entren s'ho enduen tot.

Les tres caselles eren defensables el 6 de maig. La que avui ja no se sosté és la primera, perquè el que van registrar els esquers a l'octubre és exactament explotació intentada. I això és el que ens sembla important: aquella fitxa continua amb data de 6 de maig. No és un indicador en viu, és una foto —i una foto de fa cinc mesos, feta un dia després que existís el pedaç, que és el moment de la vida d'un CVE en què menys se'n sap—. Si el teu procés consulta aquella casella i confia que algú l'actualitzi, el teu procés té una dependència que ningú no t'ha promès complir. Ja vam dedicar un post a la rapidesa amb què caduquen aquestes etiquetes: en aquell cas de vCenter, «sense explotació coneguda» va durar cinc dies.

«Autenticat» fa menys feina de la que et penses

«Autenticat» és la paraula que tranquil·litza tothom en llegir l'avís, i en un Redis real fa moltíssima menys feina de la que suggereix. Comencem pel que no és opinió: la fitxa oficial de l'ordre RESTORE la classifica a les categories ACL @keyspace, @write, @slow i @dangerous. Que sigui a @write vol dir que qualsevol identitat a la qual hagis concedit +@write pot executar RESTORE per definició, no per descuit. Si la teva aplicació escriu a Redis, la teva aplicació pot cridar RESTORE.

Afegeix-hi com són les instal·lacions de debò. A la majoria que ens trobem, «autenticació» vol dir una sola contrasenya a requirepass, la mateixa per a tothom qui s'hi connecti, sobre l'usuari default, que ve amb permisos sobre tot. Les ACL amb usuaris separats existeixen des de Redis 6 i són fantàstiques, però continuaven per estrenar en força llocs on hem mirat, perquè ningú no les va demanar i perquè el servei ja funcionava. Així que «requereix autenticació» acaba descrivint qualsevol que arribi a aquell port amb la contrasenya que és al fitxer de configuració de la teva aplicació, a la variable d'entorn d'un contenidor o en un repositori de fa tres anys.

La bona notícia és a la quarta categoria d'aquella llista. Si en el seu dia vas aplicar el modisme que el mateix manual de Redis posa com a exemple —+@all -@dangerous— ja estàs mitigat contra això sense haver-te'n assabentat, perquè RESTORE cau dins de @dangerous. És la mena de decisió que es pren un dimarts qualsevol, costa deu minuts i es rendibilitza cinc mesos després.

No, no has de saltar a la 8.6.3

Gairebé tota la cobertura que hem llegit resumeix l'arranjament així: «afecta tot allò anterior a 8.6.3, actualitza a 8.6.3». Si corres una branca 7.x i t'ho creus, acabes de convertir un pedaç de manteniment en un salt de versió major, amb la seva finestra, les seves proves i el seu risc.

El just és dir que aquella cobertura no s'ho va inventar: ho va copiar del registre del CVE. L'avís de GitHub que serveix de font a l'identificador diu, literalment, «això està pedaçat a la versió 8.6.3», i el NVD ho recull amb un rang que marca com a vulnerable tot allò anterior a 8.6.3. Segons aquell rang, una 7.2.14 —que està pedaçada— hi figura com a vulnerable. Qui repeteix «puja a 8.6.3» està citant bé una font que es queda curta. Les sis branques corregides apareixen en un lloc diferent: a la taula de l'avís del blog de Redis, que és el document que gairebé ningú no obre perquè l'identificador ja el va portar a un altre.

Aquí són les sis. L'única cosa que has de fer és quedar-te a la teva:

És una diferència pràctica enorme. «Actualitza a 8.6.3» és un projecte; «passa de 7.2.13 a 7.2.14» és un dimarts a la tarda. I quan el consell que circula converteix la segona cosa en la primera, el resultat previsible no és que la gent faci el projecte: és que no faci res.

El teu pedaç no el publica Redis: el publica la teva distribució

Hi ha un segon esglaó que la pregunta «quina versió corro?» s'estalvia sencer. Gairebé ningú no compila Redis: l'instal·la del repositori del seu sistema. I allà els números no s'assemblen als de dalt. Per a aquest únic CVE, Red Hat ha publicat quinze errates diferents (RHSA), perquè cada línia de producte va pel seu costat: el paquet corregit a Red Hat Enterprise Linux 9 és redis-6.2.22-1.el9_8, i hi conviuen mòduls redis:6 i redis:7 amb les seves pròpies dates i les seves pròpies finestres de suport estès.

I un detall que se li escapa a gairebé tota la cobertura: en aquelles mateixes fitxes, Red Hat segueix aquest CVE també contra el paquet valkey. Si en el seu dia vas marxar cap a la bifurcació per sortir del canvi de llicència, el codi que vas heretar venia amb això a dins. No és cap retret a ningú —és que una bifurcació hereta la base de codi sencera, el bo i l'altre—, però sí que és un recordatori que l'inventari no pot dir «Redis» i quedar-se tan ample. Ha de dir quin paquet, de quin repositori, en quina versió i qui l'actualitza.

Això no és un cas estrany. Quan comptem on viuen de debò les fallades que s'exploten, la resposta incomoda: només un de cada vuit errors explotats és en un aparell. La resta són peces del muntatge de les teves aplicacions —gestors de continguts, repositoris, servidors de documents, bases de dades en memòria— que ningú no sent seves perquè no tenen un adhesiu amb el nom d'un fabricant a la part del davant d'un rack.

Si el teu disparador és el KEV, continues esperant

Molta gent sensata té escrit que s'actua quan una fallada entra al catàleg KEV de CISA, el de vulnerabilitats explotades conegudes. És un criteri defensable i ens sembla mil vegades millor que no tenir-ne cap. Però convé saber què et deixa fora: vam descarregar el catàleg mentre escrivíem això —versió 2026.10.16, 1.748 entrades— i CVE-2026-25243 no hi és, amb els esquers ja registrant intents.

Hi ha una cosa més en aquell catàleg que val la pena. Si hi busques «Redis» com a fabricant, en surt una sola entrada en gairebé quatre anys: CVE-2022-0543, afegida el 28 de març del 2022, i el producte amb què hi figura és «Debian-specific Redis Servers». Aquella fallada no la va posar Redis, la va posar l'empaquetament d'una distribució.

I hi ha un segon Redis al catàleg que no trobes buscant Redis, perquè és dins d'un Cisco: CVE-2022-20821, afegit el 23 de maig del 2022, la descripció del qual diu que la comprovació de salut d'IOS XR «obre el port TCP 6379 per defecte» i que un atacant pot connectar-se a la instància de Redis que corre en aquell contenidor. Allà ningú no va comprar cap Redis ni el va apuntar en cap full. Venia a dins. Les dues vegades que això ha arribat al catàleg d'explotació coneguda, el problema no era al codi de Redis sinó a la capa que l'empaqueta, el desplega o l'encén sense preguntar —que és justament la capa que l'inventari s'estalvia—.

Segons el relat: va esborrar la base i va esborrar les petjades

Queda un detall del relat dels esquers, i és el que converteix això en un assumpte de continuïtat a més de seguretat. Convé dir amb precisió què es reporta: intents, no una execució de codi confirmada. Dins d'aquells intents, cada passada acabava buidant l'espai de claus, emportant-se per davant les dades i, de passada, les seves pròpies petjades. Si el teu Redis és una memòria cau de debò, això és una mala estona i una tempesta de peticions contra la base de dades del darrere. Si a més guarda sessions, cues o estat —i en guarda més del que la gent es pensa—, això és una caiguda amb gent mirant una pantalla.

Un atacant que s'emporta les seves petjades et deixa amb els teus registres com a única manera de reconstruir què va passar. Quant duren i on són se sol preguntar el pitjor dia; l'avís va arribar 47 dies tard i els teus registres duren 30 va just d'aquest compte enrere.

Les cinc comprovacions

Això és el que nosaltres executem per tancar l'assumpte. No porta mitja hora i val igual encara que la teva branca ja estigui pedaçada, perquè quatre de les cinc no van d'aquest CVE: van del següent.

1. Què corres de debò. redis-server --version i, des de dins, INFO server. Apunta les dues coses: la versió que diu Redis i la versió del paquet de la teva distribució. No són el mateix i la segona és la que et pedaça.
2. Quantes identitats hi ha. ACL LIST i ACL WHOAMI. Si la resposta és un sol usuari default amb permisos sobre tot, ja saps què val la paraula «autenticat» a casa teva.
3. Treu-li RESTORE a qui no el faci servir. És la mitigació que publica el mateix fabricant, i és una línia: ACL SETUSER lamevaapp -restore per al cas puntual, o ACL SETUSER lamevaapp on >clau ~app:* +@all -@dangerous si prefereixes tallar d'arrel tota la categoria. Les aplicacions de negoci no solen cridar mai RESTORE: el fan servir les eines de migració i còpia, que no són la teva API. Abans d'aplicar-ho, mira als registres si algú l'està fent servir.
4. Qui arriba al port. CONFIG GET bind i CONFIG GET protected-mode, i després comprova-ho des de fora, no sobre el paper. Un Redis que només escolta on toca converteix aquesta fallada en un problema intern, que és una categoria molt diferent.
5. Qui és el responsable. Un nom i un cognom al costat de la paraula «Redis» en un full, amb la data de l'última actualització. Si aquella casella és buida, les quatre comprovacions anteriors tornaran a estar sense fer d'aquí a sis mesos.

Qui té la culpa dels 164 dies

Gairebé ningú, i aquest és l'assumpte. Redis va publicar l'arranjament el mateix dia de l'avís i per a sis branques. CISA va omplir una fitxa raonable amb el que se sabia el 6 de maig. El NVD va fer la seva feina i va puntuar en l'estàndard que fa servir. Ningú no va mentir, ningú no va arribar tard, i tot i així el resultat van ser 164 dies. Les peces estaven totes bé; el que no funciona és com encaixen: dues escales que es llegeixen com si fossin una, una fitxa amb data que es consulta com si fos un indicador en viu, i un número que acaba decidint una finestra de manteniment sense que ningú recordi d'on va sortir.

Nosaltres no venem llicències de Redis ni de ningú, així que podem dir l'evident: la resposta a això no es compra, s'escriu. És saber quines peces de dades i aplicacions sostenen el teu negoci, tenir-les en un inventari amb responsable i versió, i decidir l'accés a cadascuna abans que calgui, que és la part de ciberseguretat que no surt a cap fullet perquè no és un producte. El que sí que venem és la feina de mantenir-ho viu quan l'equip de dins està ocupat traient el producte endavant.

La pregunta amb què tanquem no és si estàs pedaçat. És més barata de respondre i diu més: quantes aplicacions diferents es connecten avui al teu Redis amb la mateixa contrasenya? Si per contestar-la has d'obrir tres repositoris, ja tens la resposta i no és sobre Redis.

Fonts i mètode: la descripció de la fallada, la data de publicació (5 de maig del 2026), el CWE-122, els dos vectors CVSS en desacord (7,7 en CVSS 4.0 amb AC:H des del CNA; 8,8 en CVSS 3.1 amb AC:L com a puntuació primària del NVD), la fitxa SSVC de CISA del 6 de maig del 2026 i la llista de paquets afectats —inclòs valkey— i de les quinze errates RHSA procedeixen del registre de CVE-2026-25243 al NVD, consultat via la seva API el 20 d'octubre del 2026. Les sis branques corregides i les versions dels mòduls, així com la mitigació per ACL, surten de l'avís de seguretat de Redis del 5 de maig del 2026 i de les notes de la versió 8.6.3. L'impacte «Important» i la redacció de la mitigació de Red Hat, de la seva fitxa del CVE. L'absència al KEV i l'única entrada de Redis del catàleg (CVE-2022-0543, 28-03-2022) les vam comprovar descarregant el catàleg KEV de CISA el 20 d'octubre del 2026: versió 2026.10.16, 1.748 entrades. L'explotació del 16 i 17 d'octubre —esquers de Defused, mateix atacant cinc vegades amb temporitzador, buidatge de l'espai de claus— està presa d'una font secundària, l'article de securityonline.info que cita la publicació de Defused; no l'hem verificada de manera independent i la donem com el que és, un report de tercers. No tenim telemetria pròpia d'aquests intents. El que és nostre aquí és la lectura —el desacord sobre AC com a predicció i no com a fet, què vol dir «autenticat» en una instal·lació real, el salt de versió innecessari que indueix el consell que circula— i les cinc comprovacions, que són de collita pròpia. Les traduccions de les citacions són nostres.