CVE-2026-34486: una llamada a `super.messageReceived()` movida convirtió el cifrado de clúster de Tomcat en una ruta de RCE con fallo abierto

crítica

CVE

CVE-2026-34486

CWE

CWE-311

Sistemas afectados

Apache Tomcat `9.0.116`, `10.1.53` y `11.0.20`
Despliegues de Tomcat en clúster que usan Tribes con `EncryptInterceptor` habilitado y un receptor de clúster alcanzable, típicamente TCP `4000`
Pilas de aplicaciones Java cuyo classpath de Tomcat contiene cadenas de gadgets de deserialización utilizables alcanzables desde la ruta de mensajes de Tribes
Paquetes empresariales y de Linux downstream que distribuyen las líneas vulnerables de Tomcat, incluyendo las compilaciones de Red Hat y JBoss Web Server listadas por los avisos de NVD y Red Hat

CVE-2026-34486 es el tipo de fallo que los equipos de AppSec deberían mantener en su repertorio mental porque la parte peligrosa no es una reescritura gigante de un analizador ni una función nueva. Es una línea de flujo de control. En los lanzamientos vulnerables de Tomcat, EncryptInterceptor.messageReceived() registra un fallo de descifrado y aun así reenvía el mensaje original al resto de la ruta de recepción de Tribes. La inclusión en el KEV de CISA el 4 de agosto importa porque cambia la priorización, pero la lección de ingeniería subyacente es más antigua y más general: una vez que un límite de seguridad se implementa como “descifra, luego despacha”, mover el despacho fuera de la ruta de éxito convierte el límite en un analizador que falla abierto.

Para los despliegues de Tomcat en clúster que exponen el receptor de Tribes más allá de un segmento estrictamente controlado, esto no es solo “falta de cifrado”. Es una ruta desde bytes de red suministrados por el atacante hasta la superficie de deserialización de objetos Java que la pila de clúster espera consumir solo después de un descifrado exitoso.

Versiones afectadas confirmadas y límite de la corrección

El registro público es consistente entre Apache, NVD y los metadatos de vulnerabilidad legibles por máquina:

Proyecto	Versión afectada	Versión corregida
Apache Tomcat 9.x	`9.0.116`	`9.0.117`
Apache Tomcat 10.1.x	`10.1.53`	`10.1.54`
Apache Tomcat 11.0.x	`11.0.20`	`11.0.21`

El límite de despliegue importa tanto como el límite de versión. El análisis público y los escritos de exploit coinciden en que la exposición práctica requiere todo lo siguiente:

el clustering Tribes de Tomcat está habilitado
EncryptInterceptor está configurado en la cadena de interceptores
el receptor del clúster es alcanzable por red, comúnmente en TCP 4000
el classpath objetivo contiene una cadena de gadgets de deserialización utilizable

Por eso esto es a la vez más limitado y más peligroso de lo que sugiere el titular promedio de “vulnerabilidad de Tomcat”. No afecta a todos los contenedores de servlets. Afecta al subconjunto que deliberadamente activó el cifrado de mensajes en clúster y por lo tanto esperaba que un fallo de descifrado fuera la barrera.

La regresión es visible en el diff

El núcleo del fallo se entiende mejor como un problema de flujo de control antes-y-después.

El patrón vulnerable se veía así:

public void messageReceived(ChannelMessage msg) {
    try {
        byte[] data = msg.getMessage().getBytes();

        data = encryptionManager.decrypt(data);

        XByteBuffer xbb = msg.getMessage();
        xbb.clear();
        xbb.append(data, 0, data.length);
    } catch (GeneralSecurityException gse) {
        log.error(sm.getString("encryptInterceptor.decrypt.failed"), gse);
    }

    super.messageReceived(msg);
}

Esa última llamada es todo el problema. Si decrypt() lanza una excepción, el código registra el fallo y de todos modos ejecuta:

super.messageReceived(msg);

El commit de corrección de la 9.0.117 hace explícita la propiedad de seguridad pretendida moviendo esa llamada de vuelta a la ruta de éxito:

             xbb.clear();
             xbb.append(data, 0, data.length);
+
+            super.messageReceived(msg);
         } catch (GeneralSecurityException gse) {
             log.error(sm.getString("encryptInterceptor.decrypt.failed"), gse);
         }
-        super.messageReceived(msg);

Esa es toda la restauración del límite:

estado vulnerable: “descifra si es posible, de lo contrario continúa”
estado corregido: “descifra con éxito o descarta el mensaje”

Para los defensores, es un buen ejemplo de por qué la revisión de código debería tratar la ubicación de las excepciones como lógica de seguridad y no como un asunto de estilo.

Por qué un fallo de descifrado se convierte en un problema de deserialización

La implementación actual de EncryptInterceptor de Tomcat muestra con claridad la ruta segura pretendida:

byte[] data = msg.getMessage().getBytes();

data = encryptionManager.decrypt(data);

XByteBuffer xbb = msg.getMessage();
xbb.clear();
xbb.append(data, 0, data.length);

super.messageReceived(msg);

El contrato es: entran bytes de red cifrados, los bytes descifrados sustituyen el búfer de mensaje original, y solo entonces el resto del canal procesa el mensaje.

CVE-2026-34486 rompe ese contrato. Ante un fallo de descifrado, los bytes de red en crudo permanecen en msg, pero el pipeline de recepción avanza de todos modos. Los análisis de exploit públicos describen que la ruta posterior llega al flujo de deserialización de mensajes de Tribes, donde los bytes controlados por el atacante pueden convertirse en entrada de objetos Java.

Reducida a su forma esencial, la ruta vulnerable es:

el atacante alcanza el receptor de Tribes
-> EncryptInterceptor.decrypt(...) lanza una excepción
-> se registra el error
-> el búfer de mensaje original queda intacto
-> super.messageReceived(msg) se ejecuta de todos modos
-> el código posterior de Tribes deserializa bytes que nunca debería haber aceptado

Por eso la etiqueta de NVD “Missing Encryption of Sensitive Data” subestima el riesgo operativo. La historia de explotabilidad no es solo un fallo de confidencialidad. La barrera de cifrado se convierte en un bypass de la barrera del analizador.

Este fallo se introdujo al corregir otro problema de EncryptInterceptor

El propio aviso de Apache es explícito en que CVE-2026-34486 provino de la corrección de CVE-2026-29146. Ese problema anterior abordaba un problema de oráculo de padding en el mismo componente. En otras palabras:

corrección de seguridad en un límite de seguridad
-> pequeña refactorización en el manejo de errores del lado de recepción
-> el límite pasa de fallar cerrado a fallar abierto

Esa secuencia merece atención mucho más allá de Tomcat:

el componente original ya era sensible para la seguridad
la regresión ocurrió en la estructura de manejo de excepciones, no en una nueva función
el síntoma en tiempo de ejecución es fácil de malinterpretar como “solo un fallo de descifrado registrado”

Los equipos que revisan trenes de parches deberían tratar los lanzamientos de “corrección para un CVE anterior” como potencialmente riesgosos incluso cuando suenan puramente defensivos.

Por qué la inclusión en el KEV del 4 de agosto cambia la urgencia

El aviso del proveedor ha sido público desde abril, pero CISA añadió el problema al catálogo de vulnerabilidades explotadas conocidas el 4 de agosto de 2026. Eso cambia el marco de toma de decisiones.

Antes del KEV, muchas organizaciones podían haber triado razonablemente esto como:

importante pero dependiente de la configuración
relevante principalmente para infraestructuras de Tomcat en clúster
a parchear durante la próxima ventana de la plataforma de aplicaciones

Después del KEV, la pregunta relevante se convierte en:

¿Tenemos algún receptor de Tribes expuesto o semiexpuesto en versiones vulnerables,
y podemos demostrar que están segmentados lo suficientemente bien como para que la explotación sea imposible?

Si la respuesta no es un sí inmediato y respaldado por evidencia, esto pertenece cerca de la parte superior de la cola.

Delimitación y detección

Empieza determinando si realmente usas la ruta de clúster afectada:

rg -n "EncryptInterceptor|SimpleTcpCluster|NioReceiver|Receiver className|TcpFailureDetector" \
  conf server.xml webapps "$CATALINA_BASE" "$CATALINA_HOME"

Luego confirma si el receptor del clúster es alcanzable:

ss -ltnp | rg ":4000\\b"

Revisa los registros en busca del mensaje que emite el código vulnerable al fallar:

rg -n "encryptInterceptor\\.decrypt\\.failed|Failed to decrypt message" \
  logs "$CATALINA_BASE/logs" /var/log/tomcat* /var/log

Para infraestructuras de Linux empaquetadas, inventaría los paquetes de Tomcat downstream además de los despliegues de aplicaciones. Tanto Red Hat como NVD listan productos downstream afectados, por lo que los equipos de plataforma no deberían detenerse en “nuestro pom.xml de aplicación no menciona Tomcat directamente”.

La pregunta de delimitación más importante es:

¿Ejecutamos Tomcat en clúster con EncryptInterceptor habilitado en algún lugar donde un
par de red hostil, un host interno comprometido o un inquilino no confiable puedan alcanzar el receptor?

Si la respuesta es sí, trata la exposición como real incluso si todavía no has demostrado una cadena de gadgets en tu aplicación específica. La suposición segura es que la superficie de ataque es inaceptable hasta que se parchee o se aísle.

Remediación

Aplica el parche a la línea corregida para tu rama:

9.0.117+
10.1.54+
11.0.21+

Si el parcheo inmediato está bloqueado, reduce la superficie de ataque mientras la actualización está en curso:

restringe el puerto del receptor de Tribes solo a los miembros de confianza del clúster
desactiva el clustering donde no sea necesario
confirma la configuración de EncryptInterceptor pero no confundas su presencia con protección en las versiones vulnerables
revisa si hay bibliotecas ricas en gadgets vulnerables en el mismo classpath

Si tienes evidencia de exposición o actividad sospechosa de fallo de descifrado, la ruta de respuesta a incidentes debería incluir revisión de registros y triaje de hosts/aplicaciones en lugar de tratar el evento como un problema rutinario de solo parcheo.

La lección de AppSec

CVE-2026-34486 es un buen recordatorio de que los diseños de “seguro por envoltorio” viven o mueren según la aplicación de la postcondición. Se supone que EncryptInterceptor garantizaba:

solo se despachan bytes descifrados con éxito

Una vez que ese invariante se convirtió en:

intenta descifrar, y despacha de todos modos

el límite de seguridad se derrumbó.

Por eso este problema de Tomcat pertenece a la misma categoría mental que los fallos de confianza de gestores de paquetes, las brechas de validación de procedencia y las regresiones de endurecimiento de analizadores. El fallo no es llamativo. El límite simplemente deja de aplicar lo que los operadores creían haber activado.

De la investigación a la remediación

Comprueba si este patrón existe en tu código

Convierte esta investigación en un flujo de remediación. Analiza dependencias y manifiestos para detectar riesgos similares en la cadena de suministro y prioriza las correcciones con contexto de alcanzabilidad.

Explorar el análisis de dependencias Solicitar demo