«¿Tiene pase?» «No, lo dibujé yo» «Adelante». Explicamos un fallo en el código que permite acceder al sistema con documentos falsos.

A veces, para eludir una protección no hacen falta herramientas complejas. Basta con decirle al sistema algo que no sabe comprobar. Ese tipo de fallo fue descubierto durante un proyecto para un cliente por investigadores de seguridad en la biblioteca OpenID Connect Authenticator for Tomcat. La vulnerabilidad permitía acceder al sistema con tokens falsos y con cualquier dato en su interior.

El problema afecta a las versiones de OpenID Connect Authenticator for Tomcat desde la 2.0.0 hasta la 2.5.0, así como al estado actual de la rama master. El error apareció después de uno de los cambios en el código y afecta a la verificación de la firma digital de los tokens JWT (JSON Web Token), que se usan para confirmar la identidad del usuario.

Dentro de la función de verificación isSignatureValid en la clase org.bsworks.catalina.authenticator.oidc.BaseOpenIDConnectAuthenticator, los desarrolladores implementaron el manejo de distintos algoritmos de firma. Sin embargo, si en la cabecera del token se indica un algoritmo desconocido, la biblioteca no rechaza ese token. En lugar de ello, simplemente registra una advertencia en el log y devuelve el valor true, es decir, considera la firma como válida.

En esencia, si el sistema encuentra un algoritmo desconocido en el campo alg, omite por completo la verificación de la firma. Esto significa que un atacante puede crear su propio token JWT, especificar un algoritmo ficticio y añadir cualquier dato, por ejemplo la dirección de correo electrónico de otra persona, y la aplicación aceptará ese token como válido.

Durante la prueba, los investigadores generaron un JWT con una cabecera en la que en el campo alg pusieron el valor arbitrario ernw. En la carga útil incluyeron campos estándar, incluidos la expiración, el emisor, el destinatario y la dirección de correo electrónico. Como firma usaron la misma cadena ernw. El token resultante pasó con éxito la autenticación en la aplicación que confiaba en esta función para verificar los tokens de acceso.

De este modo, cualquier servicio que utilice versiones vulnerables de la biblioteca para verificar tokens Bearer corre el riesgo de que un atacante pueda acceder al sistema sin conocer la clave secreta ni disponer de una firma válida.

Los autores del estudio recomiendan rechazar todos los tokens con algoritmos de firma desconocidos o no soportados y considerar tales peticiones como no autorizadas. Si en el código se encuentra un algoritmo desconocido, la biblioteca debe interrumpir inmediatamente el procesamiento y devolver una denegación de acceso.

El investigador Malte Heinzelmann informó que intentó contactar con el desarrollador de la biblioteca, Boyle Software Inc., desde el 8 de septiembre de 2025 a través del formulario de contacto. Después siguieron intentos por LinkedIn y por correo electrónico, así como por otros canales en diciembre de 2025 y enero de 2026. No obtuvo respuesta. La divulgación pública de la información se produjo el 17 de febrero de 2026.