Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- El fin de la vida útil (EOL) de Jackson aumenta tu superficie de riesgo: Jackson Databind depende de Jackson Core, que tiene un historial real de CVE, por lo que el fin de vida útil deja expuesta la capa de análisis de JSON.
- Las actualizaciones precipitadas resultan costosas: los cambios de versión menor de Jackson pueden afectar a la deserialización, las anotaciones y el comportamiento de ObjectMapper, lo que requiere una validación coordinada entre aplicaciones.
- El fin del soporte técnico no significa el fin de la seguridad: El servicio ELS de TuxCare para Jackson proporciona parches continuos para las versiones de Jackson que ya no reciben soporte, mientras usted actualiza a su propio ritmo.
ELS para Jackson existe porque Jackson Databind es una de las bibliotecas Java más utilizadas en entornos de producción y uno de los riesgos de fin de vida útil (EOL) que más se pasan por alto en las pilas de aplicaciones empresariales. Jackson es el estándar de facto para el procesamiento de JSON en la JVM. Se encarga de la serialización y deserialización en API REST, intermediarios de mensajes, microservicios y flujos de datos en prácticamente todas las aplicaciones Java desarrolladas en la última década. Cuando una versión de Jackson llega al final de su vida útil, todas las aplicaciones que dependen de ella dejan de recibir parches de seguridad para la biblioteca que procesa cada carga JSON que gestionan.
El equipo de FasterXML mantiene Jackson bajo un modelo de soporte a largo plazo, pero los equipos que siguen utilizando ramas cerradas más antiguas quedan expuestos, incluso cuando existen versiones de parches más recientes en las ramas actuales. Las organizaciones que utilizan Jackson 2.17, 2.16, 2.15 o cualquier rama cerrada anterior operan sin la cobertura de seguridad del desarrollador original, y el historial de CVE de Jackson Core y Jackson Databind hace que esa vulnerabilidad sea concreta y cuantificable.
En esta publicación se explica cómo funciona realmente el ciclo de vida de las versiones de Jackson, qué implica el fin de la vida útil (EOL) de Jackson Databind en términos de seguridad y cumplimiento normativo, y por qué ELS para Jackson es la vía más directa para subsanar esa carencia mientras planificas la actualización según tu propio calendario.
¿En qué consiste el ciclo de vida de las versiones de Jackson?
Jackson sigue un modelo de soporte a largo plazo, similar al que utiliza el JDK para la gestión de versiones. Comprender este modelo es fundamental para saber exactamente cuándo dejará de recibir parches tu versión de Jackson y si la versión que estás utilizando sigue estando cubierta.
Ramas LTS frente a ramas no LTS. No todas las versiones menores de Jackson son versiones LTS. Aproximadamente una de cada tres versiones menores se designa como LTS en el momento de su lanzamiento inicial, en función del momento y la estabilidad de la versión. Las ramas LTS se mantienen abiertas durante un mínimo de dos años. Las ramas no LTS se mantienen abiertas solo hasta que se lanza la siguiente versión LTS.
Qué significa «cerrada». Cuando una rama de Jackson se cierra, el equipo de FasterXML deja de publicar parches para ella. No hay correcciones de seguridad ni de errores; la rama queda congelada. La wiki del proyecto describe explícitamente las ramas cerradas: las organizaciones que ejecutan una versión cerrada deben valerse por sí mismas.
Situación actual de las ramas. A principios de 2026, las ramas abiertas que se mantienen activamente son:
- 2.18 (LTS), lanzada el 26 de septiembre de 2024, abierta a adaptaciones a versiones anteriores y a la publicación de parches
- 2.21 (LTS), lanzada el 18 de enero de 2026, abierta a la publicación de parches
- 3.1 (LTS), lanzada el 23 de febrero de 2026
Todas las demás ramas se han cerrado. La rama Jackson 2.17 se cerró en agosto de 2025, cuando se lanzó la versión 2.20.0. La rama Jackson 2.19 se cerró en octubre de 2025. La rama Jackson 2.20 se cerró en enero de 2026, cuando se lanzó la versión 2.21.0 (LTS). La rama Jackson 2.16 se cerró en abril de 2025. Jackson 2.15 se cerró en septiembre de 2024. Jackson 2.13 y 2.14 se cerraron ambas en noviembre de 2023. Cualquier aplicación que se ejecute en estas versiones está ejecutando una versión de Jackson al final de su vida útil (EOL).
Requisito de versión de los componentes principales. Los tres componentes principales de Jackson —Jackson Annotations, Jackson Core y Jackson Databind— deben compartir siempre la misma versión secundaria. No se puede mezclar, por ejemplo, Jackson Core 2.18.x con Jackson Databind 2.17.x. Este estrecho acoplamiento implica que un evento de fin de vida útil (EOL) de Jackson Databind es también, simultáneamente, un evento de fin de vida útil de Jackson Core, y viceversa.
Requisitos mínimos de Java. Jackson 2.13 fue la última versión de la rama 2.x que admitía JDK 6 como base para el streaming de Jackson Core. Jackson 2.14 y todas las versiones posteriores de la rama 2.x requieren como mínimo Java 8.
| Sucursal de Jackson | Estado de LTS | Estado | Cerrado los |
| 2.21 | LTS | Abrir | - |
| 2.20 | No LTS | Cerrado | Enero de 2026 (con la versión 2.21.0) |
| 2.19 | No LTS | Cerrado | Enero de 2026 (con la versión 2.21.0) |
| 2.18 | LTS | Abrir | - |
| 2.17 | No LTS | Cerrado | Agosto de 2025 (con la versión 2.20.0) |
| 2.16 | No LTS | Cerrado | Abril de 2025 (con la versión 2.19.0) |
| 2.15 | No LTS | Cerrado | Septiembre de 2024 (con la versión 2.18.0) |
| 2.14 | No LTS | Cerrado | Noviembre de 2023 (con la versión 2.16.0) |
| 2.13 | No LTS | Cerrado | Noviembre de 2023 (con la versión 2.16.0) |
¿Qué significa «fin de vida útil» (EOL) de Jackson Databind?
Se acabaron los parches de seguridad
Cuando se cierra una rama de Jackson, el equipo de FasterXML deja de publicar correcciones de seguridad para ella. Cualquier vulnerabilidad que se detecte tras ese cierre —ya sea en la capa de análisis, en el proceso de deserialización o en el tratamiento que hace ObjectMapper de las entradas no fiables— recibirá un parche en las ramas abiertas actuales, mientras que tu versión seguirá expuesta.
Esto es importante porque Jackson no es una biblioteca de utilidades pasiva. Analiza de forma activa los datos JSON no fiables que llegan desde puntos finales de red, colas de mensajes, clientes REST y API externas. Cada llamada a ObjectMapper.readValue() u ObjectMapper.readTree() sobre los datos entrantes constituye una ruta de ejecución a través de un analizador cuyos parches de seguridad han dejado de publicarse en una rama cerrada. Esa vulnerabilidad está presente en cada solicitud.
Riesgos de seguridad y cumplimiento tras el fin de la vida útil de Jackson Databind
El panorama en materia de cumplimiento normativo es claro. La norma PCI DSS (requisito 6.3.3) exige que las vulnerabilidades críticas y de alta gravedad con una puntuación CVSS de 7,0 o superior se corrijan en el plazo de un mes desde la publicación del parche para los sistemas incluidos en el ámbito de aplicación. Las normas HIPAA, FedRAMP y SOC 2 contienen requisitos similares. En el caso de las aplicaciones que gestionan datos de pago, historiales médicos o tráfico API autenticado, utilizar una versión de Jackson en fin de vida útil (EOL) que no se puede parchear crea una brecha de seguridad y cumplimiento que los controles compensatorios solo pueden subsanar parcialmente.
Jackson se encuentra en la capa de deserialización de las aplicaciones que gestionan algunos de los datos más sensibles en entornos empresariales, como tokens de autenticación, datos financieros, historiales médicos y respuestas de API de servicios internos. Los auditores consideran que las bibliotecas de deserialización JSON sin parches constituyen hallazgos significativos, ya que el analizador sintáctico es la primera capa que procesa datos no fiables procedentes de fuentes externas.
La trayectoria de Jackson en la lucha contra el extremismo violento
El historial de CVE de Jackson ilustra perfectamente cómo se manifiesta en la práctica la exposición del analizador tras el fin de la vida útil del producto.
CVE-2025-52999: puntuación CVSS 4.0 de 8,7, gravedad alta (NVD). Divulgada el 25 de junio de 2025, esta vulnerabilidad afecta a Jackson Core en todas las versiones anteriores a la 2.15.0. Cuando Jackson Core analiza archivos de entrada que contienen estructuras JSON profundamente anidadas —objetos o matrices anidados con miles de niveles—, el analizador crea un nuevo JsonReadContext en la pila de llamadas de la JVM para cada nivel de anidación. En las versiones anteriores a la 2.15.0, no hay límite en cuanto a la profundidad que puede alcanzar este anidamiento. Un atacante puede crear una carga útil JSON compuesta por miles de matrices u objetos anidados, lo que provoca que la JVM agote su pila de llamadas y lance un StackOverflowError, provocando el bloqueo de la aplicación. El ataque es explotable a través de la red, no requiere autenticación y no necesita interacción del usuario. El vector NVD es CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N. La corrección en Jackson Core 2.15.0 introdujo StreamReadConstraints, una profundidad máxima de anidamiento configurable cuyo valor predeterminado es 1000. Dado que Jackson Databind utiliza Jackson Core para analizar todas las entradas JSON, todas las aplicaciones que ejecutaban Jackson Databind en una rama EOL anterior a la 2.15.0 estaban expuestas a esta condición de denegación de servicio explotable de forma remota, sin que hubiera ningún parche de origen disponible para esa versión.
En el caso de las plataformas Java empresariales que ejecutan Spring Boot 2.7, cuya estructura de dependencias de Jackson está fijada en la versión 2.13.x: esta vulnerabilidad estaba presente y sin parchear en una rama que se había cerrado en noviembre de 2023. No se publicó ningún parche de origen para esa rama cerrada; la vía estándar recomendada era una actualización más amplia del marco de trabajo o un acuerdo de soporte ampliado.
El problema de la superficie de dependencias
El árbol de dependencias directas de Jackson Databind es reducido por diseño. El archivo README del proyecto FasterXML indica explícitamente que los componentes básicos, las anotaciones, el streaming y Databind no requieren dependencias adicionales más allá del JDK básico. En la práctica, Jackson Databind depende directamente de solo dos paquetes: Jackson Core (el analizador y generador de streaming de bajo nivel) y Jackson Annotations (la capa de procesamiento de anotaciones). Ambos son paquetes de FasterXML, comparten la misma versión menor y forman parte del mismo evento de fin de vida útil (EOL) cuando se cierra una rama de Jackson.
Aunque se trata de un árbol pequeño, CVE-2025-52999 demuestra que la vulnerabilidad de Jackson Core es real y tiene una relevancia directa. Cuando se cierra una rama de Jackson, no solo es Jackson Databind el que deja de recibir parches: Jackson Core y Jackson Annotations se cierran simultáneamente. Una aplicación que ejecute una rama cerrada de Jackson queda expuesta a vulnerabilidades sin parchear en los tres componentes principales a la vez. ELS for Jackson de TuxCare cubre toda la superficie de dependencias: Jackson Databind, Jackson Core y Jackson Annotations, por lo que esta exposición se aborda de forma integral, no solo en el paquete de nivel superior.
Opciones para mantener la seguridad y el cumplimiento normativo tras el fin de la vida útil de Jackson Databind
Actualiza a una versión de Jackson compatible
La migración a Jackson 2.18 o 2.21 (las ramas LTS actuales) es la estrategia adecuada a largo plazo. El equipo de FasterXML publica notas de migración detalladas para cada versión menor, y la comunidad de Jackson mantiene una sólida compatibilidad con versiones anteriores dentro de una misma línea de versiones principales.
La complejidad de esa migración depende de tu entorno. Las organizaciones que gestionan grandes conjuntos de aplicaciones suelen tener muchos códigos fuente vinculados a una versión secundaria específica de Jackson, no por dependencia directa, sino a través de la gestión del marco de trabajo. Spring Boot, Quarkus y otros marcos de trabajo de Java gestionan las versiones de Jackson de forma transitiva, lo que significa que una actualización de una versión menor de Jackson a menudo requiere también un cambio de versión del marco de trabajo. Actualizar Jackson en un conjunto de aplicaciones empresariales requiere identificar todos los consumidores de Jackson en toda la base de código, validar el comportamiento de serialización en todas las configuraciones de ObjectMapper y probar la aplicación con cargas útiles realistas, especialmente cuando se utilizan serializadores, deserializadores o módulos de Jackson personalizados.
Migrar a una biblioteca JSON alternativa
Algunas organizaciones aprovechan el fin de vida útil (EOL) de Jackson Databind para evaluar bibliotecas JSON alternativas, como Gson, Moshi, JSON-B u otras. Se trata de una decisión arquitectónica viable a largo plazo para algunos equipos, pero requiere reescribir toda la lógica de serialización, sustituir todas las anotaciones @JsonProperty y otras relacionadas, migrar las configuraciones de ObjectMapper y validar el comportamiento en todos los contratos de API y modelos de datos.
Para la mayoría de las organizaciones que se enfrentan a una brecha inmediata en materia de seguridad y cumplimiento normativo, la migración de la biblioteca no es una respuesta a un plazo de aplicación de parches.
La ruta recomendada: TuxCare ELS para Jackson
El ELS de TuxCare para Jackson aborda directamente los problemas de seguridad y cumplimiento normativo, sin necesidad de actualizar inmediatamente el marco de trabajo ni las dependencias. TuxCare proporciona parches de seguridad continuos para las versiones de Jackson que ya no reciben soporte, cubriendo Jackson Databind, Jackson Core y Jackson Annotations sin coste adicional, lo que permite que su parque de aplicaciones mantenga un nivel de seguridad defendible mientras planifica la actualización que realmente desea llevar a cabo.
TuxCare supervisa el NVD, los avisos de seguridad de FasterXML y los canales de lanzamiento de Jackson para detectar vulnerabilidades que afecten al ecosistema de Jackson Core; a continuación, adapta y distribuye correcciones para las versiones fuera de ciclo de vida (EOL) mediante procesos respaldados por un acuerdo de nivel de servicio (SLA). Tanto si actualmente obtienes las actualizaciones de Jackson a través de Maven, Gradle o tus procesos de compilación existentes, puedes cambiar tu fuente de actualizaciones al repositorio seguro de TuxCare con cambios mínimos en tu flujo de trabajo actual. No se produce ninguna interrupción en su cadena de herramientas de compilación actual, en la configuración de su marco de trabajo ni en el código de aplicación generado.
Los riesgos de precipitarse al actualizar a Jackson
Cuando surge la presión relacionada con el fin de vida útil (EOL) de Jackson a raíz de los resultados de auditorías de cumplimiento, las alertas de los escáneres de vulnerabilidades o las escaladas del equipo de seguridad, el instinto es actuar de inmediato. Sin embargo, el coste de reaccionar sin la preparación adecuada suele ser siempre mayor de lo que los equipos prevén. Las organizaciones que implementan ELS para Jackson evitan por completo esta presión, ya que mantienen su nivel de seguridad mientras se planifica adecuadamente la actualización.
En qué consiste realmente una actualización menor de Jackson
Una actualización de versión secundaria de Jackson no consiste simplemente en cambiar el número de versión en un archivo POM. Implica una validación del comportamiento de deserialización. Las versiones secundarias de Jackson modifican ocasionalmente los comportamientos predeterminados en lo que respecta al manejo de valores nulos, las reglas de conversión y el manejo de propiedades desconocidas, lo que significa que las aplicaciones que dependen de un comportamiento de deserialización específico deben validarse con la nueva versión utilizando cargas útiles realistas. Implica la verificación de la compatibilidad del marco de trabajo para aplicaciones que utilizan Spring Boot, Quarkus u otros marcos gestionados, que deben validar que la versión de Jackson de destino sea compatible con su versión del marco de trabajo y que no surjan conflictos de dependencias transitivas. Implica comprobaciones de compatibilidad de módulos personalizados para aplicaciones que utilizan módulos de Jackson para Kotlin, Scala, Guava u otras integraciones, que deben verificar que dichos módulos estén disponibles y sean compatibles con la versión menor de Jackson de destino. Y supone una sobrecarga de pruebas en todos los puntos finales de la API, consumidores de mensajes y canalizaciones de datos que utilizan Jackson para la serialización.
En un entorno empresarial en el que decenas o cientos de servicios comparten configuraciones comunes de Jackson, en el que varios equipos pueden ser responsables de diferentes partes del gráfico de dependencias de Jackson y en el que el control de cambios rige las implementaciones en producción, una actualización de Jackson por fin de vida útil (EOL) es un programa de trabajo coordinado, no una simple incidencia.
¿Qué ocurre cuando se precipita la actualización?
Cuando los equipos de desarrollo se ven obligados a realizar una actualización menor de Jackson debido a un plazo de cumplimiento normativo, en lugar de por estar preparados para ello, el patrón es siempre el mismo. En el entorno de producción surgen cambios sutiles en el comportamiento de la deserialización con cargas de datos en casos extremos que no aparecían en las pruebas automatizadas. Las aplicaciones que utilizaban configuraciones de ObjectMapper anteriormente permisivas dejan de funcionar cuando la nueva versión impone reglas de conversión más estrictas. Los módulos de Jackson para integraciones de terceros fallan de forma silenciosa o lanzan excepciones en tiempo de ejecución cuando las versiones de los módulos no se ajustan a la nueva versión menor. La deuda técnica se acumula a medida que los equipos aplican soluciones provisionales de MapperFeature y indicadores de compatibilidad para cumplir con el plazo, lo que genera una carga de mantenimiento que se agrava con el tiempo. Y los costes imprevistos se disparan en horas de ingeniería, en incidentes de producción y en la sobrecarga de coordinación que supone ejecutar una actualización cuyo alcance no se definió adecuadamente antes de comenzar.
Los equipos que gestionan bien las transiciones de fin de vida útil (EOL) de Jackson son aquellos que las tratan como migraciones planificadas, con un inventario completo de las aplicaciones, una validación de la compatibilidad de los marcos de trabajo y una postura de seguridad estable que se mantiene a lo largo de todo el proceso. ELS para Jackson es lo que hace posible ese enfoque planificado.
La solución fácil: TuxCare ELS para Jackson
TuxCare lleva más de una década perfeccionando la automatización, los conocimientos especializados y los procesos necesarios para distribuir de forma fiable y a gran escala parches de seguridad para software al final de su ciclo de vida. Con más de 220 000 parches distribuidos en toda su cartera de productos compatibles, TuxCare ha creado un flujo de trabajo de aplicación de parches que es a la vez rápido y seguro para el entorno de producción.
ELS for Jackson cubre las carencias en materia de seguridad y cumplimiento normativo que deja el fin de vida útil (EOL) de Jackson Databind:
Parches de seguridad rápidos y respaldados por un acuerdo de nivel de servicio (SLA): TuxCare supervisa continuamente las divulgaciones de vulnerabilidades y proporciona parches para CVE de gravedad alta y crítica (CVSS 7.0+) según los SLA definidos, lo que garantiza que sus implementaciones de Jackson se mantengan dentro de los plazos de aplicación de parches exigidos por PCI DSS, HIPAA, FedRAMP y otros marcos de cumplimiento.
Cobertura completa de la superficie de dependencias: ELS para Jackson cubre Jackson Databind, Jackson Core y Jackson Annotations —el conjunto completo de paquetes principales de FasterXML que se cierran simultáneamente en un evento de fin de vida útil (EOL) de Jackson— sin coste adicional. La exposición oculta al fin de vida útil en su pila de procesamiento de JSON no se convierte en una brecha que tenga que gestionar manualmente.
Integración perfecta con tus flujos de trabajo actuales: Tanto si actualmente obtienes las actualizaciones de Jackson a través de Maven como de Gradle, puedes cambiar tu fuente de actualizaciones al repositorio seguro de TuxCare con cambios mínimos en tu flujo de trabajo actual. No se producirá ninguna interrupción en tu cadena de herramientas de compilación actual ni en las configuraciones de ObjectMapper de tu aplicación.
Paquetes firmados y a prueba de manipulaciones: Cada parche que TuxCare entrega se somete a exhaustivas pruebas de integridad, funcionalidad y regresiones antes de llegar a tu repositorio, y los paquetes están firmados criptográficamente para que sepas exactamente lo que estás implementando.
Asistencia especializada las 24 horas del día, los 7 días de la semana: El equipo de seguridad de TuxCare está disponible las 24 horas del día para la clasificación de vulnerabilidades, solicitudes de parches y resolución de problemas, por lo que nunca tendrás que gestionar un incidente de seguridad relacionado con el fin de vida útil (EOL) de Jackson sin el apoyo de especialistas.
Para ver qué vulnerabilidades CVE de Jackson ya se han solucionado, consulta el rastreador de CVE en tiempo real de TuxCare. Para obtener más detalles sobre el proceso de aplicación de parches y los estándares de validación de TuxCare, consulta el informe técnico.
No dejes que el fin de la vida útil de Jackson Databind ponga en riesgo tus aplicaciones
El fin de vida útil (EOL) de Jackson no significa que tus aplicaciones dejen de procesar JSON. Sin embargo, sí implica que la protección de seguridad en la que se basaba tu capa JSON ha desaparecido, y que cada vulnerabilidad CVE revelada en Jackson Core o Jackson Databind a partir de ese momento afecta a la biblioteca que gestiona todas las cargas útiles que tus aplicaciones intercambian con el mundo exterior.
Los equipos que gestionan adecuadamente el fin de vida útil (EOL) de Jackson lo planifican como una línea de trabajo de seguridad. Definen un proceso de aplicación de parches, delimitan el inventario de aplicaciones y establecen un calendario de validación antes de que el plazo de cumplimiento obligue a abordar el tema. Puede planificar una actualización deliberada a la versión LTS actual de Jackson cuando realmente se ajuste a la capacidad de sus equipos de aplicaciones, a los requisitos de compatibilidad de su marco de trabajo y al calendario de lanzamientos de su organización. Puede delimitar adecuadamente la validación de la deserialización y la implementación antes de comprometerse con un calendario. O bien, puede utilizar el ELS para Jackson de TuxCare para mantener la cobertura de seguridad y cumplimiento mientras establece usted mismo el calendario de actualización.
ELS for Jackson proporciona a su parque de aplicaciones parches de seguridad continuos para las versiones de Jackson que FasterXML ya no mantiene. Mantiene el nivel de cumplimiento del que dependen sus auditorías y permite a sus equipos de ingeniería planificar la actualización adecuadamente.
Si el fin de la vida útil (EOL) de Jackson Databind figura actualmente entre tus prioridades de seguridad, visita Soporte de ciclo de vida ilimitado para Jackson para obtener más información sobre el soporte ampliado para las versiones de Jackson que ya no cuentan con soporte.
