Si el desxifratge falla, el missatge passa igual

El 30 de març, Mark Thomas va pujar a Apache Tomcat un commit titulat «Better error handling - partial revert of 6d955cc». Al fitxer de codi, una línia afegida i una d'esborrada; les altres tres són l'entrada del changelog, que es queda en un pla «Better error handling for the EncryptInterceptor». El que feia aquest canvi era moure la crida que processa un missatge del clúster dins del bloc try. Perquè era a fora. I sent a fora, quan el desxifratge d'un missatge fallava, Tomcat escrivia l'error al log i processava el missatge igualment.

Aquest és CVE-2026-34486, que el 4 d'agost va entrar al catàleg de vulnerabilitats explotades de CISA amb termini de correcció per al dia 7 —el mateix lot on anava el 9,8 de Langflow del qual vam parlar al matí—. Convé dir d'on surt cada número, perquè no vénen del mateix lloc: Apache, com a CNA, es va limitar a classificar-lo «Important», sense puntuació; el 9,8 que veuràs al NVD el va afegir CISA —accés per xarxa, sense autenticació prèvia, sense interacció de l'usuari, impacte alt a les tres potes—; i Red Hat, mirant la mateixa fallada, es queda en 7,5. Tres lectures diferents que coincideixen en l'única cosa que cal retenir: s'hi arriba per xarxa i no cal cap credencial. Tot això, per una línia al lloc equivocat.

Què protegeix l'EncryptInterceptor

Quan muntes diversos Tomcat en clúster perquè la sessió d'un usuari sobrevisqui a la caiguda d'un node, els nodes es parlen entre ells per un canal propi —Tribes— que escolta al port 4000 per defecte. Per allà no hi viatgen peticions HTTP: hi viatgen objectes Java serialitzats. És literal a la documentació del projecte: tots els atributs de sessió han d'implementar java.io.Serializable, i el que s'envia pel socket TCP és «the serialized data».

La mateixa documentació de Tomcat obre el capítol de seguretat del clúster amb una frase que convé llegir a poc a poc: «la implementació del clúster està escrita partint de la base que es fa servir una xarxa segura i de confiança per a tot el trànsit del clúster. No és segur executar un clúster en una xarxa insegura i no fiable». I sobre l'interceptor de xifratge diu que, ben configurat, aporta confidencialitat i integritat, però que no protegeix de tots els riscos de fer córrer el clúster en una xarxa que no controles. L'EncryptInterceptor no és la porta: és el cadenat que poses a una porta que ja hauria de ser dins de casa.

El pedaç del pedaç

La cronologia és pública i es pot seguir commit a commit. Val la pena, perquè explica per què va acabar passant:

Fallar obrint

El codi vulnerable, resumit, era aquest:

} catch (GeneralSecurityException gse) {
    log.error(sm.getString("encryptInterceptor.decrypt.failed"), gse);
}
super.messageReceived(msg);   // fora del try: passa sempre

I la correcció: la mateixa crida, dins del try. Res més.

Convé aterrar què és això que «passa igual», perquè en abstracte sona inofensiu: és un objecte Java que ningú no ha pogut verificar entrant a la cadena de processament del clúster, la mateixa que acaba deserialitzant sessions. A la valoració que CISA adjunta al registre del NVD, amb data del 4 d'agost, l'explotació hi consta com a activa i automatitzable. CISA no publica com s'està fent servir, i nosaltres no ens ho inventarem; amb aquests dos adjectius i un termini de tres dies per a les agències federals ja n'hi ha prou per moure l'actualització de la llista de «pendent» a la d'«avui».

El que crida l'atenció no és el descuit —el descuit és humà i qualsevol que hagi escrit Java l'ha comès—. El que crida l'atenció és cap on falla. Un control de seguretat pot fallar de dues maneres: tancant (si no puc verificar això, ho llenço) o obrint (si no puc verificar això, ho deixo passar i apunto una nota). La primera provoca incidències de disponibilitat i trucades al suport. La segona no provoca res: tot continua funcionant, els usuaris no es queixen, els gràfics són verds i la protecció fa setmanes que està apagada.

I atenció al detall que més ens interessa: la senyal existia. Cada missatge que no es podia desxifrar deixava un Failed to decrypt message al log del node. No som davant d'una fallada silenciosa: som davant d'una fallada que avisava i que ningú no escoltava. Un clúster sa no genera mai aquest missatge; veure'l aparèixer significa, com a mínim, que dos nodes no comparteixen la mateixa clau, i com a màxim, que algú està enviant coses al teu port 4000. És exactament el tipus de línia que hauria de tenir una alerta al darrere, i d'això ja en vam escriure al seu dia a el post sobre fatiga d'alertes: el problema gairebé mai és que falti informació, és que en sobra i ningú no distingeix quina línia importa.

La fallada només afectava qui s'havia molestat a xifrar

Aquí ve la part incòmoda. Mira les versions afectades que publica el NVD: 11.0.20, 10.1.53 i 9.0.116. No «de la tal a la qual». Tres versions soltes. Exactament les tres que portaven el pedaç del padding oracle. Qui anava una versió enrere no va estar mai exposat a això (tenia la fallada anterior, que tampoc és cap premi). I l'EncryptInterceptor no ve activat: cal afegir-lo a mà al pipeline d'interceptors del canal. És a dir, per menjar-te aquest CVE havies de complir tres condicions seguides: tenir clúster, haver-te molestat a xifrar el canal, i haver actualitzat de pressa.

Això es pot explicar com una moralina mandrosa —«ja veus, per córrer»— i seria una ximpleria perillosa. La versió amb la fallada va estar publicada quinze dies a la branca 11.0, del 20 de març al 4 d'abril; l'altre camí era quedar-se amb un xifratge que es podia trencar per una altra banda. No hi ha opció bona entre les dues. La conclusió útil és una altra i és avorrida: el que et salva no és apedaçar ràpid o lent, és saber en quina versió exacta ets i poder canviar-la el mateix dia que calgui. Si t'assabentes avui que la 11.0.20 tenia això i no saps de memòria —o amb una ordre— què corre cadascun dels teus nodes, aquest és el problema a arreglar, no el ritme. Ho vam escriure amb més detall a «latest no és una versió», i aquest cas ho il·lustra millor que nosaltres.

«Better error handling»

L'entrada del changelog de la versió corregida diu, literalment, «Better error handling for the EncryptInterceptor». Res de «bypass», res de «security». Que consti que el projecte va fer el correcte: va publicar el CVE a la seva pàgina de seguretat, amb la severitat, les versions afectades i l'enllaç al commit. Però si el teu procés per decidir si una actualització és urgent consisteix a llegir el changelog i veure si «sona a seguretat», aquest és el contraexemple perfecte. El changelog explica què va canviar; la pàgina de seguretat del projecte explica què et pot passar si no canvies. Són dos documents diferents i només un serveix per prioritzar.

Els cinc minuts d'aquesta tarda

Si tens Java en producció —i n'hi ha molt més del que apareix als inventaris, normalment sota una aplicació de gestió que va comprar un altre departament fa vuit anys—, això és el que mirem nosaltres:

I una cosa que no és a l'avís però sí a la documentació de Tomcat des de sempre: el trànsit entre nodes d'un clúster no hauria de sortir mai d'un segment que controles. Quan els nodes són a llocs diferents —dues oficines, dos centres de dades—, això vol dir un túnel, no «la IP pública i ja xifra l'interceptor». És la conversa que tenim cada vegada que algú ens demana muntar la xarxa entre seus: què va per dins i què va per fora, i qui pot parlar amb qui.

Quants dels teus controls fallen obrint?

Aquesta és la pregunta que ens emportem del cas, i no té res a veure amb Tomcat. El proxy que inspecciona la sortida a internet: si cau, el trànsit es talla o surt directe? El filtre antispam: si l'anàlisi expira, reté el correu o l'entrega? L'accés condicional: si el servei que avalua la política no respon, denega o concedeix? L'agent d'EDR: si el servei està aturat, algú se n'assabenta el mateix dia? Cadascuna d'aquestes respostes és una decisió de disseny que algú va prendre, moltes vegades sense escriure-la enlloc, i gairebé sempre a favor que les coses continuïn funcionant. És una decisió legítima —hi ha sistemes on fallar tancant és pitjor que l'atac—, però ha de ser una decisió, no una casualitat heretada.

Nosaltres hem escrit aquest catch. Tothom que porta anys tocant codi l'ha escrit: captures l'excepció perquè el servei no caigui a les tres de la matinada, i amb això converteixes un error sorollós en un de silenciós. Per això la regla que apliquem quan revisem una arquitectura no és «el xifratge està activat?», sinó «què passa exactament quan això falla, i qui se n'assabenta?». La primera pregunta es respon amb una captura de pantalla. La segona s'ha de provar: apagar el control expressament, en una finestra, i mirar si alguna cosa es trenca o si algú avisa. Si no es trenca res i no avisa ningú, ja saps cap on falla.

Si no tens clar què hi ha corrent sota les teves aplicacions —o ho tens clar però ningú no mira els logs d'aquelles màquines—, escriu-nos. La primera conversa sol ser curta: quines versions, qui arriba a què, i què passa quan alguna cosa es trenca.

Fonts (verificades): CVE-2026-34486, «Missing Encryption of Sensitive Data vulnerability in Apache Tomcat due to the fix for CVE-2026-29146 allowing the bypass of the EncryptInterceptor», afecta 11.0.20, 10.1.53 i 9.0.116, corregit a 11.0.21, 10.1.54 i 9.0.117, CVSS 3.1 de 9,8 (crític, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) afegit per CISA-ADP com a mètrica secundària al NVD, no pel projecte: l'Apache Software Foundation, com a CNA, només el va classificar «Important» sense puntuació, i Red Hat el valora en 7,5; la valoració SSVC de CISA Coordinator del 04-08-2026 inclosa al mateix registre marca «exploitation: active» i «automatable: yes». Publicat el 09-04-2026 — NVD; classificació «Important», dates de report (26-03-2026) i publicació, i enllaços als commits — avisos de seguretat d'Apache Tomcat 11 (equivalents per a les branques 10.1 i 9.0); CVE-2026-29146 (EncryptInterceptor amb CBC per defecte, vulnerable a padding oracle, reportat el 22-02-2026); commits 6d955cce (13-03-2026) i 1fab40cc (30-03-2026, «Better error handling - partial revert of 6d955cc», 2 fitxers, 4 insercions i 1 esborrat) — repositori d'Apache Tomcat; port 4000 per defecte del receptor Tribes, requisit de java.io.Serializable, xarxa de confiança i abast de l'EncryptInterceptor — documentació de clustering de Tomcat 11; missatges de log encryptInterceptor.decrypt.failed i encryptInterceptor.algorithm.switch — fitxer LocalStrings.properties del mateix projecte; inclusió al catàleg de vulnerabilitats explotades el 04-08-2026 amb termini el 07-08-2026 — CISA KEV. CISA no publica detalls de com s'està explotant; nosaltres no ens els inventem. Les lectures, la regla del fail-open i les recomanacions operatives són nostres.