Riesgos de seguridad de pac4j-jwt, CVE-2026-29000 y lo que realmente requiere una validación JWT segura

pac4j-jwt se convirtió en un problema de seguridad de primera línea

Durante años, pac4j-jwt estuvo en una categoría que muchos equipos de ingeniería subestiman en silencio: la biblioteca que "sólo maneja tokens". En la práctica, es cualquier cosa menos eso. pac4j es un marco de seguridad Java utilizado en múltiples pilas y marcos Java, y su módulo JWT es responsable de convertir el material de identidad suministrado externamente en perfiles de aplicación de confianza. Cuando esa capa falla, el problema no es un "mal análisis de token". Es un fallo directo del límite de confianza de la aplicación. El proyecto pac4j se describe a sí mismo como un marco de seguridad Java para proteger aplicaciones y servicios web a través de muchas implementaciones, mientras que su módulo JWT está documentado como el componente que valida los tokens web JSON y construye perfiles a partir de ellos. (pac4j.org)

Esta distinción es importante porque las bibliotecas de gestión de JWT no viven en el borde de la pila. A menudo se sitúan exactamente donde se decide el estado de inicio de sesión, la continuidad de la sesión, la identidad de la API, la autorización del servicio o la confianza delegada. En otras palabras, si su aplicación acepta un token y pac4j-jwt dice "esto corresponde al usuario X con rol Y", el resto del sistema normalmente deja de hacer preguntas. Esta es la razón por la que la última vulnerabilidad pac4j-jwt es tan importante: convierte un problema de análisis aparentemente técnico en una ruta de falsificación de identidad completa. (pac4j.org)

La actual ola de atención en torno a pac4j-jwt no está impulsada por un debate genérico sobre JWT. Está siendo impulsada por una vulnerabilidad específica y crítica: CVE-2026-29000. Según NVD, GitHub Advisory Database, y el propio aviso de seguridad del proyecto pac4j, las versiones afectadas de pac4j-jwt contienen un bypass de autenticación en JwtAuthenticator al procesar JWT cifrados. La guía de corrección oficial es inequívoca: actualizar a 4.5.9 o posterior en 4.x, 5.7.9 o posterior en 5.xo 6.3.3 o posterior en 6.x. (NVD)

Lo que hace que esta vulnerabilidad destaque no es sólo su puntuación de gravedad, aunque ya es alarmante. NVD registra un Puntuación base CVSS 3.1 de 10,0 y clasifica la debilidad como CWE-347, Verificación incorrecta de firma criptográfica. Y lo que es más importante, la vulnerabilidad permite a un atacante remoto que tenga la clave pública RSA del servidor crear un token malicioso que pueda autenticarse como cualquier usuario, incluido un administrador, en las condiciones afectadas. La idea de que un público puede llegar a ser suficiente para acuñar identidades de confianza es el tipo de fallo que llega al corazón de cómo los desarrolladores modelan mentalmente los sistemas JWT. (NVD)

Qué hace pac4j-jwt en realidad

Para entender por qué CVE-2026-29000 es tan peligroso, se necesita un modelo mental limpio de lo que pac4j-jwt se supone que debe hacer. pac4j JWT documentación dice que el módulo soporta la validación de JSON Web Tokens utilizando el Nimbus JOSE + JWT biblioteca, y JwtAuthenticator puede validar tokens y devolver un perfil pac4j o un mapa de reclamaciones. La misma documentación también explica que JwtGenerator puede crear JWTs en texto plano, firmados y encriptados dependiendo de la configuración de firma y encriptación que le apliques. (pac4j.org)

Parece sencillo, pero los sistemas JWT rara vez lo son en producción. Un único token puede representar reclamaciones, estado de firma, estado de cifrado, identidad de la clave, vida útil, relación con el emisor y datos de autorización específicos de la aplicación. El RFC 7519 define JWT como un contenedor compacto de reclamaciones que puede representarse como un objeto protegido por JWS o como el texto sin formato de un objeto JWE. El RFC 7515 define JWS como el mecanismo de protección de la integridad basado en firma o MAC. El RFC 7516 define JWE como el mecanismo de cifrado. RFC 8725, el documento de Mejores Prácticas Actuales JWT, existe precisamente porque las implementaciones del mundo real desdibujan repetidamente estos límites y hacen suposiciones de confianza no válidas. (IETF Datatracker)

La lección central es sencilla, pero a menudo se ignora: el cifrado y la firma no son propiedades intercambiables. El cifrado garantiza la confidencialidad. La firma garantiza la integridad y el origen. En los diseños JOSE por capas, es posible que necesite ambos. La guía de selección de algoritmos Nimbus de Connect2id hace explícita esta distinción: las firmas digitales proporcionan integridad, autenticación y no repudio, mientras que el cifrado autenticado proporciona confidencialidad además de propiedades de integridad/autenticación dependiendo de la construcción. La guía también señala que los JWT firmados y cifrados son un patrón válido cuando se requiere tanto confidencialidad como autenticidad. (Conectar2id)

Por eso este problema de pac4j-jwt es más que un error de implementación. Es un recordatorio de que los equipos a menudo dicen "usamos JWTs encriptados" como si la encriptación por sí sola hiciera que la identidad fuera fiable. No es así. Si la aplicación descifra un token pero no puede demostrar que las afirmaciones proceden de un firmante de confianza, el sistema ha preservado el secreto al tiempo que ha renunciado a la autenticidad. CVE-2026-29000 convierte en arma exactamente ese malentendido. (NVD)

La vulnerabilidad que cambió la conversación

Las descripciones públicas de CVE-2026-29000 son coherentes en las fuentes más importantes. NVD afirma que las versiones de pac4j-jwt anteriores a 4.5.9, 5.7.9y 6.3.3 contienen un bypass de autenticación en JwtAuthenticator al procesar JWT cifrados. El atacante puede crear un JWE envuelto PlainJWT con tema y papel y eludir la verificación de firmas, autenticándose como cualquier usuario, incluidos los administradores. GitHub Advisory Database refleja la misma descripción. El boletín de Arctic Wolf añade una explicación especialmente útil: tras el descifrado, la biblioteca puede acabar en una ruta lógica en la que el token interno no se valida realmente como firmado, pero sus afirmaciones se siguen utilizando para construir el perfil de usuario. (NVD)

El propio proyecto pac4j publicó un breve pero urgente aviso confirmando que una vulnerabilidad en JwtAuthenticator había sido corregido y que los usuarios debían actualizar a las líneas parcheadas. La brevedad del aviso es notable. Los mantenedores no publicaron una larga narración; publicaron una instrucción directa para actualizar. Cuando el responsable de un proyecto dice "DEBE actualizar", normalmente es porque las condiciones del exploit son lo suficientemente prácticas como para que los matices sean menos importantes que la acción inmediata. (pac4j.org)

El escrito de Arctic Wolf, que coincide con la descripción del NVD, es útil porque traduce el fallo a lenguaje operativo. En su análisis, el fallo afecta a los despliegues que utilizan JWE basado en RSA junto con JwtAuthenticator configurado con EncryptionConfiguration y FirmaConfiguración. Si el token interior es un PlainJWTEn el caso de los perfiles de usuario, la ruta de verificación de la firma puede omitirse, pero las reclamaciones siguen fluyendo hacia la creación del perfil. Ese es el abuso de confianza específico que convierte una entrada malformada en una identidad autenticada. (Lobo Ártico)

Esto no es un problema teórico vago, y no es un error "tal vez explotable si las estrellas se alinean". Se trata de una condición en la que la biblioteca puede aceptar reclamaciones controladas por atacantes como estado de usuario autenticado. Cuando las afirmaciones afectadas incluyen subEl resultado no es una corrupción parcial. Se trata de una suplantación total de cuentas en la capa de identidad. La puntuación de NVD refleja esa realidad: no se requieren privilegios, no hay interacción con el usuario, se puede acceder a la red, tiene un alto impacto en la confidencialidad y la integridad. (NVD)

Por qué JWE no fue suficiente

Una buena forma de entender el fallo es olvidarse por un momento de la jerga y pensar en lo que la aplicación cree que ha ocurrido.

La aplicación recibe un token.

La aplicación ve que el token está encriptado.

La aplicación lo descifra con éxito.

A continuación, la aplicación utiliza las reivindicaciones descifradas para crear un perfil de usuario.

Esta secuencia parece razonable hasta que se formula la pregunta que falta: que demostró que la carga útil descifrada estaba firmada por un emisor de confianza?

En términos de JOSE, el cifrado por sí mismo no es una declaración de autenticidad del emisor. RFC 7516 define cómo se representa el contenido cifrado. El RFC 7515 define cómo se representan las firmas. La RFC 7519 permite explícitamente que las declaraciones JWT sean firmadas, cifradas o ambas. La RFC 8725 se publicó porque las bibliotecas y aplicaciones hacían repetidamente suposiciones inseguras cuando analizaban o validaban tokens a través de estas representaciones. (IETF Datatracker)

La guía de algoritmos de Connect2id expresa el mismo principio desde el punto de vista del diseño criptográfico. Si necesita que otros verifiquen quién emitió un token, necesita firmas digitales. El cifrado resuelve un problema diferente. Un JWE puede mantener el contenido del token oculto a los observadores, pero no dice mágicamente a su aplicación si la carga útil fue aprobada por el firmante legítimo a menos que el diseño aplique explícitamente la semántica de firma anidada. (Conectar2id)

La documentación actual de pac4j explica esto más claramente de lo que muchos equipos probablemente recuerden de versiones anteriores. La documentación de JWT dice que si un token está cifrado y se definen configuraciones de firma, entonces la carga útil descifrada debe ser un JWT firmadoy se rechaza un JWE que descifre un JWT sin firmar. Esa redacción es importante porque codifica el modelo seguro: si tu aplicación espera declaraciones firmadas, descifrar a un objeto de declaración sin firmar no es "lo suficientemente cerca". Es un fallo duro. (pac4j.org)

También por eso CVE-2026-29000 debe leerse como una lección de diseño para el ecosistema de seguridad Java en general. El problema no era que la criptografía fallara en abstracto. El problema era que la política de confianza tras el descifrado no se aplicaba con la suficiente firmeza. La capa externa hacía lo que hace el cifrado. La capa interna era donde debería haberse establecido la verdad de la identidad. Esa es la capa a la que llegaban los atacantes. (NVD)

Lectura correcta del modelo de comportamiento pac4j

La documentación de pac4j JWT es excepcionalmente útil aquí porque nos da la semántica prevista en lenguaje llano. Establece que si al menos un FirmaConfiguración se define un PlainJWT es rechazada. También explica que el cifrado está controlado por un encryptionRequired que, por defecto, es falsoy que si encryptionRequired es verdadero y las configuraciones de cifrado están presentes, se rechaza un JWT no cifrado. Y lo que es más importante, los documentos dicen ahora explícitamente que si un token está cifrado y se definen configuraciones de firma, la carga útil descifrada debe ser un JWT firmado, no uno sin firmar. (pac4j.org)

Eso nos da el contrato de seguridad previsto de forma concisa:

Escenario de fichas	En qué debe confiar el sistema	Qué requieren ahora los documentos de pac4j
JWT simple sin configuración de firma	Muy poco, y sólo en diseños estrechamente controlados.	Sólo puede aceptarse cuando no se ha definido ninguna configuración de firma (pac4j.org)
JWT firmado con configuración de firma	Integridad y origen, si se verifica la firma	Aceptada si una configuración de firma coincidente la verifica (pac4j.org)
JWT cifrado sin expectativa de firma	Confidencialidad de las reclamaciones, pero la autenticidad depende del diseño más amplio	Puede descifrarse si la configuración de cifrado coincide (pac4j.org)
JWT cifrado más configuración de firma	Confidencialidad y autenticidad del testigo interno	La carga útil descifrada debe ser un JWT anidado firmado, no un PlainJWT (pac4j.org)

Ese modelo sigue la ruta del código actual visible en el código fuente GitHub de pac4j. En el JwtAuthenticator el código actual analiza el token, descifra EncryptedJWT en su caso, y luego comprueba si existe un JWT firmado antes de continuar con la verificación de la firma. En la fuente actual, si las configuraciones de firma no están vacías y firmadoJWT permanece nulo, se lanza una excepción de credenciales utilizando la lógica "no se puede aceptar un JWT sin firma". El código también muestra que encryptionRequired sigue siendo falso por defecto por compatibilidad con versiones anteriores. (GitHub)

Ese defecto merece atención. Los propios comentarios de la biblioteca dicen que encryptionRequired existe por compatibilidad con versiones anteriores y puede establecerse en true en una versión futura. En otras palabras, el propio pac4j reconoce que el comportamiento de cifrado opcional introduce una ambigüedad que los equipos de seguridad deben razonar cuidadosamente. La compatibilidad con versiones anteriores es comprensible en una biblioteca madura, pero la compatibilidad con versiones anteriores y las expectativas de seguridad modernas suelen estar en tensión. (GitHub)

La forma técnica de CVE-2026-29000

A alto nivel, la vulnerabilidad surge cuando un token es cifrado, descifrado con éxito, y luego tratado como si sus afirmaciones internas fueran de confianza sin que la aplicación pruebe que el objeto interno fue realmente firmado por la parte legítima. NVD resume claramente la condición del exploit: un atacante que tenga la clave pública RSA del servidor puede crear un JWE-wrapped PlainJWT con reivindicaciones arbitrarias de sujeto y función. Estas declaraciones pueden eludir la verificación de firmas y ser aceptadas como información de identidad. (NVD)

La explicación de Arctic Wolf completa los detalles operativos. Su análisis afirma que cuando JwtAuthenticator descifra un JWE, intenta parsear el token interno como un FirmadoJWT. Si la carga útil descifrada es en cambio un PlainJWTel objeto de firma es nulo y la ruta de verificación de la firma puede saltarse debido al fallo lógico, tras lo cual el código construye un perfil a partir de declaraciones no verificadas. Ese es exactamente el tipo de condición de bifurcación que muchos equipos pasan por alto en la revisión de código porque el código "suele funcionar" para tokens firmados normales. Los atacantes no envían tokens normales. (Lobo Ártico)

Aquí hay un detalle conceptual importante. No se trataba de un fallo del propio RSA, y no era un caso en el que el atacante tuviera que robar la clave privada de firma. La clave pública era suficiente porque el comportamiento vulnerable residía en cómo la biblioteca interpretaba la estructura del token después del descifrado, no en romper la criptografía. Por eso esta vulnerabilidad parece tan contraintuitiva a primera vista. Los desarrolladores aprenden correctamente que una clave pública está destinada a ser pública. La cadena de exploits no contradice eso; explota una implementación que trataba el resultado del descifrado como una base fiable para la identidad incluso cuando faltaba la prueba de autenticidad interna. (NVD)

Merece la pena insistir en esa distinción porque se generaliza mucho más allá de pac4j-jwt. Muchos consumidores de bibliotecas siguen pensando en términos de "¿puede un atacante firmar un token?" cuando a menudo deberían preguntarse "¿puede un atacante hacer que el verificador acepte reclamaciones sin una firma válida?". No son la misma pregunta. La primera es un compromiso criptográfico. La segunda es el compromiso de la lógica del verificador. El RFC 8725 existe en gran medida porque la segunda clase de error se ha repetido en todos los ecosistemas durante años. (Editor de RFC)

Por qué es importante en los sistemas Java reales

La página principal de pac4j enfatiza el amplio alcance del framework a través de Spring Web MVC, Spring Security, JAX-RS, Undertow, Jooby, Play, Vert.x, Ratpack y otros stacks Java. Por lo tanto, una vulnerabilidad en pac4j-jwt importa no sólo donde los ingenieros escribieron explícitamente "usamos pac4j-jwt", sino también donde aparece como parte de una configuración de autenticación mayor o una cadena de dependencia transitiva. El repositorio de Maven muestra que el artefacto tiene muchas versiones y es usado por otros paquetes, reforzando la necesidad práctica de un inventario de dependencias en lugar de suposiciones. (pac4j.org)

Esto cambia la carga de respuesta. Es posible que un equipo no sepa que pac4j-jwt está en el ámbito de aplicación hasta que inspeccione su lista de materiales de software, el árbol de dependencias o el tiempo de ejecución de la aplicación empaquetada. Si lo encuentran, la siguiente pregunta no es simplemente "¿qué versión? Sino "¿cómo la estamos utilizando?". Las condiciones del exploit descritas públicamente apuntan con más fuerza a los despliegues que utilizan JWT cifrados, especialmente con JWE basado en RSA y la configuración de cifrado y firma presentes. Los equipos que sólo utilizan JWS firmados pueden no estar en el camino vulnerable de la misma manera, pero todavía necesitan verificar su configuración real en lugar de inferir la seguridad de los diagramas de arquitectura. (Lobo Ártico)

El riesgo se amplifica cuando la autorización de la aplicación está estrechamente vinculada a las reclamaciones de token. La fuente actual de pac4j muestra que la creación de perfiles lee en última instancia el conjunto de reclamaciones JWT, extrae el sujeto y los atributos, y puede hidratar los roles y los valores de identidad vinculados en el perfil de usuario. En un sistema sano, ese es el punto de procesamiento de JWT. En un sistema no saludable, se convierte en el lugar donde las reclamaciones falsificadas se convierten en permisos operativos. (GitHub)

Esta es la razón por la que las vulnerabilidades de la capa de identidad a menudo producen daños desmesurados. Un fallo RCE puede dar una ruta para el control del servidor. Un bypass de autenticación da control sobre lo que el sistema cree acerca de quién eres. En grandes sistemas, la falsificación de identidades puede conducir a una escalada de privilegios, acciones administrativas, acceso a datos, autorización de servicios laterales o persistencia oculta a través de planos de control de confianza. Esta es la razón por la que los escritos sobre vulnerabilidades en torno a pac4j-jwt se centran tanto en la suplantación del administrador: es el camino más corto desde el manejo de tokens malformados hasta el fallo total de la confianza. (NVD)

pac4j ha visto esta película antes en otras formas

CVE-2026-29000 es la crisis actual, pero no es la primera vez que el ecosistema pac4j más amplio ha revelado una peligrosa brecha entre la entrada similar a un token y la confianza verificada.

Un ejemplo anterior es CVE-2021-44878que NVD describe como un fallo en pac4j v5.1 y anteriores en el que los clientes podían, de forma predeterminada, aceptar tokens de ID de OpenID Connect mediante el método "ninguno" algoritmo. NVD señala que el "ninguno" no requiere verificación de firma, lo que permite eludir la validación de token mediante un token de identificación malformado. Se trataba de un módulo diferente y un contexto diferente, pero la lección de seguridad rima estrechamente con el problema actual de pac4j-jwt: los datos de identidad no firmados o insuficientemente validados pueden cruzar la frontera de la entrada no fiable al estado de sesión fiable. (NVD)

Otro ejemplo importante es CVE-2023-25581 en pac4j-core. NVD describe una vulnerabilidad de deserialización en Perfil de usuario manejo de atributos, donde los valores controlados externamente con un prefijo especial podrían ser tratados como objetos Java serializados, lo que potencialmente llevaría a la ejecución remota de código en el peor de los casos. Una vez más, los detalles difieren, pero el tema subyacente sigue siendo consistente: una vez que un marco asume que las estructuras de datos adyacentes a la identidad son seguras y de confianza, un atacante sólo tiene que encontrar un camino para introducir de contrabando contenido hostil en ellas. (NVD)

Estos ejemplos no significan que pac4j tenga defectos exclusivos en comparación con cualquier otro framework. Las bibliotecas de identidad de todos los ecosistemas han tenido problemas similares durante años. Lo que sí significan es que los equipos que utilizan pac4j deben ser especialmente disciplinados sobre la diferencia entre análisis sintáctico, descifrar, verificando, normalizandoy autorizando. Son etapas distintas. Cuando se funden en una sola caja negra en la mente de los desarrolladores, los fallos de seguridad son mucho más probables. (Editor de RFC)

Cómo es una postura pac4j-jwt más segura

El primer paso, y el más obvio, es parchear. Si está en una línea vulnerable, tiene que pasar a 4.5.9, 5.7.9o 6.3.3o versiones más recientes en esas líneas. Esa es la recomendación de los mantenedores de pac4j, NVD, GitHub Advisory Database, Arctic Wolf y Snyk. No hay ningún argumento responsable para retrasar esa actualización si su despliegue está plausiblemente afectado. (pac4j.org)

Pero los parches no lo son todo. Las vulnerabilidades de JWT a menudo son reveladas por un CVE y realmente solucionadas por cambios en la arquitectura. El RFC 8725 recomienda una validación rigurosa, expectativas claras sobre los algoritmos y evitar la confusión de confianza entre clases de tokens. La guía de mejores prácticas de Curity también hace hincapié en la validación completa de la firma, el emisor, la audiencia y el propósito del token, y advierte contra la intercambiabilidad descuidada entre tipos de token o la sobrecarga de lógica empresarial en los tokens. (Editor de RFC)

En el contexto pac4j-jwt, eso suele significar cinco movimientos concretos.

En primer lugar, pregúntese si necesita JWE en absoluto. Muchos sistemas necesitan principalmente autenticidad e integridad, no confidencialidad de las declaraciones en cada salto. La guía de algoritmos de Connect2id señala explícitamente que JWS y JWE resuelven problemas diferentes. Si su aplicación sólo necesita probar el emisor y el conjunto de reclamaciones, JWS por sí solo puede ser más sencillo y seguro que un diseño JWE anidado que su equipo apenas audita. (Conectar2id)

En segundo lugar, si necesita tokens encriptados, exija JWT firmados anidados. los propios documentos de pac4j dicen ahora exactamente eso: cuando se definen configuraciones de firma, un JWE descifrado debe producir un JWT firmado. Trate cualquier token interno sin firmar como una violación del protocolo, no como un caso fallback. (pac4j.org)

En tercer lugar, hay que bloquear los algoritmos y la gestión de claves. La guía de algoritmos de Connect2id recomienda RS256 para un amplio soporte y señala las ventajas y desventajas de las familias EC y EdDSA. En términos más generales, el RFC 8725 advierte contra la confusión de algoritmos y una validación insuficiente. Acepte sólo los algoritmos que pretenda utilizar explícitamente y asegúrese de que la detección de claves y los identificadores de claves no crean rutas de confianza ambiguas. (Conectar2id)

En cuarto lugar, tratar las reclamaciones como aportación a la políticano la política en sí. Una ficha papeles no debe convertirse automáticamente en toda la historia de la autorización si llega de una ruta que tu aplicación no ha autenticado completamente. Las reclamaciones deben estar vinculadas al emisor, el público, la caducidad, el tiempo no anterior y, en ocasiones, el contexto de autorización adicional del lado del servidor. Curity recomienda la validación completa de estas propiedades circundantes, lo cual es exactamente correcto. (Seguridad)

En quinto lugar, pruebe la ruta infeliz. La mayoría de las pilas de identidades se prueban a fondo con tokens válidos y apenas se prueban con tokens anidados malformados, cargas útiles sin firmar dentro de envoltorios cifrados, claves obsoletas, algoritmos mal etiquetados o desajustes en la forma de las reclamaciones. CVE-2026-29000 es un recordatorio de que esos no son casos de esquina para los atacantes. Son el camino principal. (Lobo Ártico)

Un patrón de configuración que merece escrutinio

El siguiente ejemplo no es código de explotación. Es un patrón de configuración representativo que los equipos de seguridad deberían revisar cuidadosamente porque combina los conceptos exactos que importan aquí: cifrado, firma y confianza en las afirmaciones.

JwtAuthenticator jwtAuthenticator = new JwtAuthenticator();

// Verificación de la firma
jwtAuthenticator.addSignatureConfiguration(
    new RSASignatureConfiguration(rsaKeyPair)
);

// Soporte de cifrado
jwtAuthenticator.addEncryptionConfiguration(
    new RSAEncryptionConfiguration(rsaKeyPair)
);

// El comportamiento por defecto aún puede permitir ambigüedad si los equipos
// no razonan cuidadosamente sobre rutas cifradas vs firmadas.
jwtAuthenticator.setEncryptionRequired(false);

La documentación de pac4j muestra que JwtAuthenticator admite configuraciones tanto de firma como de cifrado, y la fuente actual sigue documentando encryptionRequired por defecto a falso para compatibilidad con versiones anteriores. Esto no hace que la configuración sea automáticamente insegura en versiones parcheadas, pero significa que los equipos necesitan entender exactamente qué formas de token aceptará la aplicación. Si un equipo de ingeniería no puede responder "debe firmarse el JWT descifrado interno" sin comprobar el código o los documentos, ese equipo está corriendo un riesgo de identidad evitable. (pac4j.org)

Una mejor postura defensiva es hacer explícito el contrato de token previsto y luego verificarlo en las pruebas.

JwtAuthenticator jwtAuthenticator = new JwtAuthenticator();

// Aceptar sólo firmas de la clave del emisor de confianza
jwtAuthenticator.addSignatureConfiguration(
    new RSASignatureConfiguration(trustedIssuerKeyPair)
);

// Si los tokens cifrados son realmente necesarios, sólo descifrar utilizando la
// clave del destinatario previsto y exigir el cifrado explícitamente.
jwtAuthenticator.addEncryptionConfiguration(
    new RSAEncryptionConfiguration(recipientKeyPair)
);

jwtAuthenticator.setEncryptionRequired(true);

// Añade la validación circundante en tu propia capa de integración:
// emisor, audiencia, caducidad, no-antes, ID de clave,
// y comprobaciones de autorización específicas de la ruta.

Esto sigue sin ser "seguro por arte de magia". Es simplemente más cercano al contrato de confianza que los equipos realmente quieren decir. La aplicación está diciendo que los tokens cifrados son obligatorios en este camino, las firmas de una clave de confianza son obligatorias en este camino, y la aceptación de tokens no se reduce a "la biblioteca podría analizarlo". Esa mentalidad está mucho más cerca de la postura de mejores prácticas del RFC 8725. (Editor de RFC)

Cómo auditar rápidamente su dependencia y exposición

Cuando una vulnerabilidad aterriza en una biblioteca como pac4j-jwt, el primer fallo de ingeniería suele ser la visibilidad. No se puede arreglar lo que no se sabe que se envía.

Un primer paso práctico es inspeccionar tu árbol de dependencias de Maven o Gradle y sacar a la superficie tanto las referencias directas como las transitivas.

mvn dependency:tree | grep pac4j-jwt

./gradlew dependencies | grep pac4j-jwt

El repositorio Maven muestra actualmente la línea de artefactos pac4j-jwt y la existencia de las versiones parcheadas 5.7.9 y 6.3.3que hace que el inventario de dependencias sea inmediatamente procesable. Los equipos no deben detenerse en las dependencias raíz, porque las bibliotecas de autenticación a menudo se obtienen a través de integraciones de marcos de trabajo de nivel superior o módulos de identidad empaquetados. (Repositorio Maven)

Un segundo paso es buscar en su código base los posibles puntos de configuración y de procesamiento de tokens.

grep -R "JwtAuthenticator" src/
grep -R "SignatureConfiguration" src/
grep -R "EncryptionConfiguration" src/
grep -R "RSASignatureConfiguration" src/
grep -R "RSAEncryptionConfiguration" src/

Un tercer paso es la verificación en tiempo de ejecución. En la puesta en escena, alimenta el servicio con un conjunto de tokens deliberadamente malformados y confirma que cada ruta falla al cerrarse. No necesitas un exploit público para hacer esto de forma responsable. El objetivo no es convertir el fallo en un arma. El objetivo es confirmar que su aplicación rechaza cargas útiles internas sin firmar, emisores no coincidentes, audiencias incorrectas, tokens caducados, IDs de clave erróneos y algoritmos JOSE inesperados. Ese es el tipo de prueba negativa que exige implícitamente el RFC 8725, y es exactamente el tipo de prueba que muchos equipos se saltan hasta que una CVE les enseña lo contrario. (Editor de RFC)

El error de ingeniería detrás de muchos incidentes de JWT

La lección más profunda aquí no es "parchea siempre más rápido", aunque deberías hacerlo. Es que los incidentes JWT ocurren con frecuencia porque los equipos reducen la confianza a la sintaxis.

El token se ha analizado correctamente.

El token se ha descifrado correctamente.

El objeto de reclamación existe.

Se ha creado el perfil de usuario.

Ninguno de esos eventos prueba la identidad por sí mismo. Sólo prueban que la aplicación procesó la entrada. El RFC 7519 define el contenedor. El RFC 7515 define la semántica de la firma. El RFC 7516 define la semántica del cifrado. El RFC 8725 existe porque demasiados sistemas desplegados desdibujaron estas capas y trataron el procesamiento satisfactorio como una validación satisfactoria. (IETF Datatracker)

La documentación actual de pac4j JWT es en realidad un fuerte correctivo a este respecto. Distingue claramente cómo deben manejarse los JWT simples, firmados y cifrados, y ahora hace explícito el requisito de JWT firmado anidado cuando se configuran las firmas. Este es el lenguaje de documentación que los ingenieros de seguridad deberían propagar internamente: un token descifrado no es automáticamente un token autenticado. (pac4j.org)

Esto también explica por qué vulnerabilidades como CVE-2021-44878 y CVE-2026-29000 tienden a parecer familiares incluso cuando ocurren en módulos diferentes. En ambos casos, el atacante encontró un camino por el que se podía hacer que el verificador aceptara un token que carecía de la prueba de autenticidad que la aplicación pensaba que estaba requiriendo. Una vez que eso ocurre, el sistema ya no está haciendo autenticación. Está haciendo la ingestión de reclamaciones. (NVD)

Lista de comprobación defensiva práctica para equipos pac4j-jwt

La tabla siguiente recoge los movimientos defensivos de mayor valor para los equipos responsables de pac4j-jwt en producción.

Zona de riesgo	Qué verificar	Por qué es importante	Acción práctica
Versión de biblioteca vulnerable	¿Está por debajo de 4.5.9, 5.7.9, o 6.3.3	Estas líneas están explícitamente afectadas por CVE-2026-29000	Actualizar inmediatamente (pac4j.org)
Confusión en el modo Token	¿Están claramente separados los requisitos del JWS y del JWE?	El cifrado y la firma resuelven problemas diferentes	Documentar las formas de token aceptadas por punto final (Editor de RFC)
Aplicación de tokens anidados	¿Puede un JWE descifrar a un JWT interno sin firmar	Ese es el peligroso patrón central de esta CVE	Requerir JWTs anidados firmados cuando existan configuraciones de firma (pac4j.org)
Cifrado opcional por defecto	Es encryptionRequired falso sin revisión intencionada	Los valores por defecto retrocompatibles pueden preservar la ambigüedad	Establezca la política explícitamente y pruebe las rutas infelices (GitHub)
Reclamar confianza	¿Las funciones y los temas determinan inmediatamente la autorización?	Las demandas falsificadas pueden convertirse en privilegios reales	Revalidar emisor, audiencia, vida útil y política de rutas (Seguridad)
Visibilidad de la dependencia	¿Es pac4j-jwt transitivo en su build	Los equipos a menudo echan en falta bibliotecas auth en deps indirectos	Inspeccionar SBOM, árbol de dependencias y empaquetado en tiempo de ejecución (Repositorio Maven)

Este tipo de fallos en la capa de identidad suelen dejar al descubierto un punto ciego en los flujos de trabajo de seguridad tradicionales. Un escáner de versiones puede decirle que org.pac4j:pac4j-jwt está presente. Una herramienta SCA puede decirle si la versión está por debajo de la línea fija. Lo que esas herramientas normalmente no le dicen es si su aplicación es realmente accesible a través de la ruta de token vulnerable, si acepta flujos JWE anidados en producción, si las reclamaciones de esos flujos alcanzan decisiones de autorización, y si su parche realmente cerró la condición de explotación bajo sus propios proxies inversos, puertas de enlace y código de aplicación. Las descripciones públicas de CVE-2026-29000 dejan claro que la configuración y la forma del token importan, no sólo la presencia del paquete. (NVD)

Ese es el punto en el que un flujo de trabajo de validación nativo de IA se vuelve más útil que las alertas estáticas por sí solas. En una plataforma como Penligent, el valor no es simplemente "escanear la dependencia". El valor real es encadenar el descubrimiento de dependencias, el descubrimiento de rutas de procesamiento de tokens, la generación de solicitudes de prueba, la validación de reclamaciones malformadas y la repetición de pruebas de regresión tras la implementación de parches. Esto es especialmente relevante para la gestión de JWT, donde la presencia de una biblioteca vulnerable no lo dice todo, pero una ruta de solicitud reproducible a menudo sí. La propia cobertura de Penligent en Hacking Labs ya incluye un artículo dedicado a CVE-2026-29000 en pac4j-jwt y el material de seguridad JWT relacionado, lo que lo convierte en un punto de referencia interno natural para los equipos que intentan pasar de la concienciación a la validación. (Penligente)

Cómo debería ser una validación JWT segura después de esto

Después de este CVE, la respuesta correcta no es "ten más cuidado con pac4j-jwt". La respuesta correcta es más amplia y duradera.

Una canalización segura de JWT debe empezar por decidir qué tipo de token acepta cada ruta y qué propiedad de seguridad necesita realmente esa ruta. Si una ruta sólo necesita autenticidad de origen e integridad de la solicitud, un JWS firmado puede ser suficiente. Si también necesita confidencialidad en tránsito o en reposo fuera de la aplicación, un diseño anidado firmado y cifrado puede ser apropiado. Pero esa decisión debe ser deliberada. El RFC 8725 existe porque la industria ha construido repetidamente sistemas de tokens flexibles y luego los ha validado de forma ambigua. (Editor de RFC)

A partir de ahí, la verificación debe ser estratificada y explícita. La aplicación debe validar el algoritmo JOSE con respecto a una lista de permisos, validar la relación de claves, validar el emisor y el público, validar las reivindicaciones de tiempo, validar el propósito del token y validar que la representación del token coincide con el contrato para esa ruta. Sólo entonces las reclamaciones podrán influir en la autorización. Las directrices de Curity para validar completamente la firma, el emisor y el público son básicas, pero siguen sin aplicarse lo suficiente, especialmente en API internas y rutas de servicio a servicio que los equipos tratan incorrectamente como de confianza por defecto. (Seguridad)

La historia de pac4j-jwt es particularmente valiosa porque derrumba una ilusión común. Los ingenieros suelen sentirse más seguros cuando ven más criptografía, más estructura JOSE, más capas, más abstracción. Pero la complejidad no es garantía. Un token firmado que se valida limpiamente es más seguro que un token cifrado anidado que el equipo no entiende completamente. En ingeniería de seguridad, lo más sencillo y explícitamente validado suele ser mejor que lo más rico y ambiguamente fiable. (Conectar2id)

Conclusión

La razón por la que pac4j-jwt importa ahora no es que JWT se haya vuelto peligroso de repente en 2026. JWT siempre ha exigido una validación precisa. Lo que ha cambiado es que CVE-2026-29000 hizo dolorosamente visible un fallo de validación concreto: la diferencia entre descifrar un token y confiar en una ficha. La biblioteca aceptó un camino en el que esas dos ideas podían distanciarse, y los atacantes podían entrar en esa brecha. (NVD)

Por eso esta vulnerabilidad merece algo más que una nota de parche. Merece una revisión de arquitectura. Si sus aplicaciones Java utilizan pac4j-jwt, debería actualizar inmediatamente. Entonces debería auditar si realmente necesita JWE, si los JWTs firmados anidados son aplicados donde deberían serlo, si las reclamaciones son sobre-confiables, y si sus pruebas de validación de tokens incluyen casos adversos en lugar de sólo accesorios de camino feliz. El aviso oficial de pac4j le proporciona el objetivo de actualización. Las RFC y la guía de mejores prácticas le indican cómo pensar en el diseño. La única pregunta que queda es si su proceso de ingeniería está dispuesto a tratar el análisis sintáctico de identidades como el límite crítico que realmente es. (pac4j.org)

Lecturas complementarias

• Documentación sobre pac4j JWT (pac4j.org)
• pac4j aviso de seguridad para JwtAuthenticator (pac4j.org)
• Entrada NVD para CVE-2026-29000 (NVD)
• Entrada de la base de datos de avisos de GitHub para CVE-2026-29000 (GitHub)
• Análisis de Arctic Wolf de CVE-2026-29000 (Lobo Ártico)
• RFC 7519, Token web JSON (IETF Datatracker)
• RFC 7515, Firma web JSON (IETF Datatracker)
• RFC 7516, Cifrado web JSON (IETF Datatracker)
• RFC 8725, Mejores prácticas actuales de JWT (Editor de RFC)
• Guía de selección del algoritmo Nimbus JOSE + JWT (Conectar2id)
• Penligencia en CVE-2026-29000 en pac4j-jwt (Penligente)
• Penligent JWT token decode tutorial (Penligente)
• Guía de pruebas de API Penligent con ejemplos de autorización JWT (Penligente)