Cuando un parche rompe el modelo de seguridad: anatomía de la regresión fail-open en Apache Tomcat Tribes (CVE-2026-34486)

Las vulnerabilidades más interesantes rara vez aparecen por errores complejos de criptografía o por sofisticadas técnicas de explotación. En muchas ocasiones surgen como consecuencia de una modificación aparentemente inocua durante un refactoring. Eso es exactamente lo que ocurrió con CVE-2026-34486.

En este artículo vamos a analizar cómo una única modificación en el flujo de control de Tomcat Tribes convirtió un componente diseñado para impedir la deserialización de mensajes no confiables en un mecanismo que, precisamente, permitía que dichos mensajes alcanzaran el código de deserialización.

Más allá del CVE concreto, el caso resulta especialmente interesante porque ejemplifica uno de los errores de diseño más peligrosos en software de seguridad: pasar de un comportamiento fail-closed a otro fail-open.

Recordando cómo funciona Tomcat Tribes

Tomcat Tribes implementa el sistema de clustering de Apache Tomcat. Su objetivo principal consiste en replicar información entre distintos nodos del clúster, especialmente sesiones HTTP, mensajes internos y eventos de replicación. La comunicación se realiza mediante un protocolo propio sobre TCP.

Simplificando el flujo:

El punto importante es que la deserialización ocurre únicamente después de atravesar la cadena de interceptores. Por tanto, el modelo de seguridad asumía que cualquier mensaje recibido ya había sido autenticado (o, más concretamente, correctamente descifrado).

El papel del EncryptInterceptor

Cuando el administrador configura cifrado entre nodos del clúster, Tomcat inserta un EncryptInterceptor.

Su responsabilidad es sencilla:

1. recibir el mensaje
2. descifrarlo
3. reemplazar el contenido original
4. reenviarlo al siguiente interceptor

El comportamiento esperado es: llega el mensaje, lo descifra (decrypt ()) y lo deja continuar si tiene éxito o lo descarta si hay algún error. Es decir, un diseño claramente fail-closed.

Hasta Tomcat 11.0.18, el método seguía precisamente esa lógica:

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);

        super.messageReceived(msg);

    } catch (GeneralSecurityException gse) {
        log.error(...);
    }
}

La llamada a:

super.messageReceived(msg);

estaba dentro del bloque try.

Si el descifrado fallaba se lanzaba una excepción, el mensaje nunca continuaba y la deserialización jamás ocurría. Desde el punto de vista del diseño, el comportamiento era correcto.

El refactoring

Durante la corrección de una vulnerabilidad previa relacionada con el uso de CBC y padding oracle, el código fue reorganizado para facilitar nuevos algoritmos como AES-GCM. En ese proceso apareció un cambio aparentemente irrelevante.

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(...);

    }

    super.messageReceived(msg);
}

La única diferencia importante es la posición de una línea. Desde el punto de vista del compilador, el código sigue siendo perfectamente válido, pero desde el punto de vista del modelo de seguridad, ya no.

Ahora el flujo pasa a ser:

La excepción deja de detener el procesamiento. El mensaje continúa exactamente igual. Sin modificar. Sin validar. Sin autenticarse...

Resulta tentador pensar que el problema está relacionado con AES pero no es así. El algoritmo utilizado es irrelevante. Da igual AES-CBC, AES-GCM o cualquier otro modo, el error aparece después de que la operación criptográfica falle. No importa el motivo del fallo. La excepción simplemente deja de impedir que el mensaje avance.

Esto resulta tan peligroso porque el siguiente componente de la cadena asume que todo mensaje recibido ya ha superado las comprobaciones anteriores. GroupChannel no vuelve a validar el contenido, confía en el interceptor. Este caso es un ejemplo de manual del antipatrón fail-open.  

Una vulnerabilidad introducida por una mitigación

Lo realmente llamativo del caso es que el cambio aparece durante la corrección de otra vulnerabilidad. El parche original perseguía endurecer la criptografía. Sin embargo, durante ese proceso terminó eliminando la propiedad de seguridad más importante del componente: impedir que mensajes no autenticados llegasen a la capa de deserialización.

Este tipo de regresiones son especialmente difíciles de detectar mediante análisis estático. El código compila, funciona, registra errores y pasa muchas pruebas funcionales. Lo único que ha cambiado es una propiedad del flujo de control.

Lecciones para revisiones de seguridad

Este incidente deja varias conclusiones interesantes.

1. Los refactorings también modifican el modelo de amenazas: Mover una llamada fuera de un bloque try puede alterar completamente la superficie de ataque.

2. Las propiedades de seguridad deberían validarse mediante tests: No basta con comprobar que el código funciona.

También debería verificarse que:

• un error de descifrado nunca produce procesamiento posterior;
• las excepciones mantienen el comportamiento fail-closed.

3. Los interceptores representan fronteras de confianza: Cuando un interceptor garantiza una propiedad ("todo lo que sale está autenticado"), el resto del sistema deja de comprobarla. Romper esa garantía equivale a eliminar un control de seguridad de todo el pipeline.

Mitigación

Apache corrigió la regresión restaurando el comportamiento original, devolviendo la llamada a super.messageReceived() al interior del bloque protegido y recuperando así el modelo fail-closed. Según la investigación publicada, las versiones corregidas son 11.0.21, 10.1.54 y 9.0.117. Las ramas vulnerables fueron 11.0.20, 10.1.53 y 9.0.116, mientras que la serie 8.5.x no se ve afectada por esta regresión.

Conclusión

CVE-2026-34486 demuestra que las vulnerabilidades más críticas no siempre nacen de algoritmos criptográficos rotos o de primitivas inseguras.

En este caso bastó desplazar una única línea de código para transformar un interceptor que descartaba mensajes inválidos en otro que los reenviaba de forma incondicional.

Es un recordatorio de que las propiedades de seguridad no dependen únicamente del código que ejecutamos, sino también del flujo de ejecución que decidimos mantener. En componentes encargados de establecer límites de confianza, un pequeño cambio estructural puede ser suficiente para convertir una defensa en el origen de una vulnerabilidad crítica.

Fuente: https://www.striga.ai/research/tomcat-tribes-unauth-rce