Fin de la vida útil de Apache Struts: mantén la seguridad de tus aplicaciones web Java | TuxCare ELS

Principales conclusiones

• Cuando una versión de Struts llega al final de su ciclo de vida, toda la pila de dependencias —OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Log4j2 y otras— deja de recibir correcciones de seguridad coordinadas junto con el propio marco.
• La migración de Struts 2.5.x a 6.x requiere actualizaciones del entorno de ejecución de Java, cambios en la API de Servlet, la reescritura de expresiones OGNL, la sustitución de interfaces de interceptores y la eliminación de patrones de acceso a métodos estáticos, todo lo cual exige una planificación minuciosa y pruebas exhaustivas, y no plazos ajustados.
• TuxCare ELS amplía la cobertura de seguridad para las versiones de Struts que han llegado al final de su ciclo de vida (EOL) y sus árboles de dependencias, de modo que las organizaciones puedan mantener la seguridad y el cumplimiento normativo mientras planifican una migración planificada y con los recursos adecuados, según su propio calendario.

Struts ha sido la columna vertebral del desarrollo web Java empresarial durante más de dos décadas. Su arquitectura Modelo-Vista-Controlador, su consolidado ecosistema de complementos y su profunda integración con el conjunto de tecnologías Java empresarial lo han convertido en el marco preferido para aplicaciones web a gran escala en sectores como los servicios financieros, la administración pública, la sanidad y las telecomunicaciones. Pero Struts tiene una historia que hace que la cuestión del fin de su vida útil sea inusualmente delicada. Cuenta con el historial de CVE más grave de todos los marcos web Java en producción, y las organizaciones que ejecutan versiones de Apache Struts en fase de fin de vida útil asumen un perfil de riesgo que la filtración de Equifax de 2017 convirtió de algo teórico en noticia de portada.

Este artículo explica qué implica realmente el fin de la vida útil (EOL) de Apache Struts para los equipos de desarrollo de aplicaciones Java, dónde se esconden los verdaderos riesgos de seguridad en el árbol de dependencias, por qué la migración a las versiones actuales es más compleja de lo que parece y cómo el servicio Endless Lifecycle Support (ELS) de TuxCare te permite mantener una cobertura total en materia de seguridad y cumplimiento normativo sin obligar a realizar una migración para la que tus equipos aún no están preparados.

¿En qué consiste el ciclo de vida del producto Apache Struts?

Struts no sigue un ciclo de lanzamientos formal y documentado basado en plazos, como hacen otros proyectos de código abierto. El Comité de Gestión del Proyecto (PMC) de la Apache Software Foundation publica avisos de fin de vida útil (EOL) directamente en el sitio web del proyecto cuando una rama principal se acerca a su fin, normalmente con un preaviso de seis meses antes de que el soporte finalice oficialmente. Los avisos de EOL no están vinculados a un calendario fijo, sino que reflejan la capacidad de la comunidad para mantener una rama determinada y la disponibilidad de una versión sucesora compatible.

Por ejemplo, puedes consultar nuestra guía sobre el fin de vida útil (EOL) de Apache Kafka para ver cómo la infraestructura de streaming afronta situaciones similares de interrupción del soporte, o informarte sobre cómo los marcos de trabajo de big data gestionan un hito del ciclo de vida relacionado con el fin de vida útil de Apache Spark. Si gestionas componentes de almacenamiento de datos, también puedes obtener más información sobre el fin de vida útil de Apache Hive en nuestra guía detallada.

El proyecto sigue el sistema de versionado semántico y mantiene la compatibilidad con sus ramas activas actuales. Tradicionalmente, los avisos de fin de vida útil (EOL) han ido acompañados de seis meses de cobertura exclusiva de seguridad tras el anuncio inicial, tras los cuales la rama deja de recibir parches de cualquier tipo. Esto significa que no hay periodo de gracia para las vulnerabilidades de seguridad reveladas después de la fecha final de EOL; cualquier CVE que afecte a una rama en EOL no recibirá una corrección oficial por parte de la comunidad.

Estado actual de compatibilidad de la versión de Struts:

Versión	Fecha de publicación	Fecha de fin de vida útil	Estado
Struts 1x	2000-2008	Abril 2013	EOL
Struts 2.3x	2012	May 2019	EOL
Struts 2.5x	May 2016	Abril 30, 2024	EOL
Struts 6x	Junio 2022	No se ha anunciado	Activo (más reciente)
Struts 7x	Diciembre 2024	No se ha anunciado	Activo

Struts 2.5.x, la versión más extendida en entornos empresariales, recibió su versión final (2.5.33) en diciembre de 2023 y llegó oficialmente al final de su ciclo de vida el 30 de abril de 2024. Las organizaciones que no hayan completado su migración a Struts 6.x o 7.x están utilizando actualmente un marco de trabajo Apache Struts fuera de servicio, sin cobertura de parches de seguridad del desarrollador original.

Las consecuencias prácticas de este modelo de ciclo de vida son considerables. Dado que el proyecto no publica con años de antelación fechas fijas para el fin de vida útil (EOL), las organizaciones suelen encontrarse con que el anuncio del EOL llega antes de que se haya presupuestado, dotado de recursos y planificado la migración. El plazo de preaviso de seis meses del EOL de Apache Struts no es tiempo suficiente para que las grandes aplicaciones empresariales con una amplia integración de Struts puedan completar una migración probada y validada.

¿Qué implica el fin de la vida útil (EOL) de Apache Struts para las aplicaciones web en Java?

Para las organizaciones que utilizan Struts como capa web de aplicaciones Java de misión crítica —encargadas de gestionar solicitudes HTTP dirigidas al público, gestionar la carga de archivos, procesar el envío de formularios y actuar como interfaz de las capas de lógica de negocio que manejan registros financieros, datos de pacientes o sistemas gubernamentales—, la designación de fin de vida útil (EOL) de Apache Struts no es una simple cuestión administrativa. Se trata de un incidente de seguridad con consecuencias directas en materia de cumplimiento normativo.

No habrá más parches de seguridad tras la fecha de fin de vida útil

Una vez que una versión de Struts llega al final de su ciclo de vida, la comunidad de Apache deja de publicar correcciones de seguridad para ella. Cualquier vulnerabilidad que se revele después de la fecha de fin de vida útil, ya sea en el distribuidor central del marco, en su motor de evaluación de expresiones OGNL, en la gestión de la carga de archivos o en su pila de interceptores, no recibirá un parche oficial. La única solución que ofrece la comunidad es migrar a una versión compatible.

Para los equipos que gestionan aplicaciones web de gran envergadura y críticas para la producción, en las que la migración requiere reescribir clases de acción, sustituir interfaces de interceptores, actualizar expresiones OGNL en todas las plantillas y validar el comportamiento en decenas o cientos de puntos finales de la aplicación, esto no siempre es una opción a corto plazo. El intervalo entre el momento en que entra en vigor el estado de fin de vida útil (EOL) y el momento en que, de forma realista, se puede completar y validar la migración es precisamente cuando se acumulan las vulnerabilidades sin parchear.

Riesgos de seguridad y cumplimiento normativo tras el fin de la vida útil

Las consecuencias en materia de cumplimiento normativo derivadas del uso de una versión de Struts fuera de ciclo de vida (EOL) son directas. La norma PCI DSS (requisito 6.3.3) exige que los parches críticos y de alta gravedad se instalen en el plazo de un mes desde su publicación; sin embargo, en una versión de Struts fuera de ciclo de vida no hay parches que instalar, lo que hace imposible cumplir con la normativa por los medios habituales. Los auditores de SOC 2 señalan el software fuera de ciclo de vida en entornos de producción. Las organizaciones que ejecutan implementaciones de Apache Struts fuera de ciclo de vida se enfrentan a lagunas en la documentación que salen a la luz en los cuestionarios de seguridad, retrasan las certificaciones de los proveedores y, en los sectores regulados, bloquean las renovaciones de los clientes.

Para las organizaciones en las que las aplicaciones Struts se encuentran dentro del ámbito de aplicación de la norma PCI, tratan datos de carácter personal o sustentan servicios sujetos a obligaciones contractuales de SLA, el riesgo de incumplimiento derivado de este fin de vida útil no es meramente teórico. Se trata de una deficiencia de auditoría a la espera de materializarse.

Historial de CVE: lo que revela el registro de vulnerabilidades

Struts tiene el historial de vulnerabilidades CVE más significativo de todos los marcos web de Java en producción, y este historial demuestra claramente por qué la aplicación de parches para los productos en fin de vida útil no es opcional.

CVE-2017-5638 (CVSS 10.0 Crítico) es la vulnerabilidad que expuso los datos personales y financieros de 147 millones de personas en la filtración de Equifax, una de las filtraciones de datos más perjudiciales de la historia. La falla residía en el analizador Jakarta Multipart: un atacante podía crear un encabezado HTTP Content-Type malicioso que provocaba un manejo incorrecto de excepciones en el analizador, lo que daba lugar a la ejecución de comandos arbitrarios en el servidor con los privilegios del proceso del servidor web. No se requería autenticación. Los exploits estuvieron disponibles públicamente a los pocos días de la divulgación, y la explotación activa en la red comenzó de inmediato. Se publicó un parche el 7 de marzo de 2017. El hecho de que Equifax no lo aplicara dejó sus sistemas expuestos durante 144 días, tiempo suficiente para que los atacantes sustrajeran números de la Seguridad Social, fechas de nacimiento y números de permiso de conducir a lo largo de una campaña prolongada. La filtración dio lugar a un acuerdo de 700 millones de dólares, a comparecencias ante el Congreso y se convirtió en el caso de estudio definitivo sobre lo que realmente cuesta la exposición de Struts sin parchear. La solución estaba disponible. El intervalo entre la disponibilidad del parche y su aplicación fue lo que determinó el resultado.

CVE-2023-50164 (NVD CVSS 3.1: 9,8 Crítico) demostró que la exposición crítica a la ejecución remota de código (RCE) de Struts no terminó con la generación de vulnerabilidades de 2017. Esta falla residía en la lógica de carga de archivos del marco: un atacante podía manipular los parámetros de carga de archivos para habilitar el recorrido de rutas y, a continuación, cargar un archivo malicioso en una ubicación accesible para el servidor web, lo que permitía la ejecución remota de código. El vector CVSS AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H indica que no se requiere autenticación, no hay interacción del usuario, es accesible desde la red y supone un compromiso total de la confidencialidad, la integridad y la disponibilidad. A los pocos días de la divulgación en diciembre de 2023 se publicaron exploits de prueba de concepto. Las versiones afectadas abarcaban todo el historial de Struts 2, desde la 2.0.0 hasta la 2.5.32 y desde la 6.0.0 hasta la 6.3.0. Struts 2.5.33 recibió un parche, pero Struts 2.5.33 es la última versión de Struts 2.5.x, lo que significa que la rama ha llegado al final de su vida útil (EOL). Cualquier CVE que se divulgue en el futuro contra Struts 2.5.33 no recibirá una corrección de la comunidad.

CVE-2024-53677 (NVD CVSS 3.1: 9,8 Crítico) es el ejemplo más claro de lo que significa en la práctica el estado de fin de vida útil (EOL) de Apache Struts hoy en día. Revelada en diciembre de 2024, esta vulnerabilidad crítica de traversal de ruta en el mecanismo de carga de archivos de Struts afecta a todas las versiones de Struts desde la 2.0.0 hasta la 6.3.0.2, incluida la 2.5.33, la última versión EOL. El vector de ataque es idéntico en su naturaleza al de CVE-2023-50164: un atacante manipula los parámetros de carga de archivos para recorrer una ruta del servidor no prevista y cargar un archivo malicioso, logrando la ejecución remota de código. La solución requiere actualizar a Struts 6.4.0 y migrar al nuevo interceptor Action File Upload. Struts 2.5.33, al ser una rama EOL, no recibió ningún parche. Cualquier organización que siga ejecutando Struts 2.5.x queda expuesta de forma permanente a esta vulnerabilidad crítica de RCE sin que exista una vía de corrección oficial disponible —exactamente el escenario de riesgo de fin de vida útil (EOL) de Apache Struts que aborda este artículo—.

Este es precisamente el tipo de vulnerabilidad —ejecución de código remoto sin autenticación y accesible desde la red en la infraestructura de aplicaciones web en producción— que se convierte en una vulnerabilidad sin resolver de forma permanente en las versiones que han llegado al final de su ciclo de vida. El caso de Equifax demostró que este no es un riesgo que las organizaciones puedan gestionar únicamente mediante la supervisión o la detección. La única solución duradera es una versión parcheada.

El riesgo oculto: el árbol de dependencias de Struts

La superficie de vulnerabilidad de una implementación de Struts no se limita al propio binario del marco. Struts incluye un conjunto considerable de dependencias que conllevan sus propios riesgos de seguridad; y cuando Struts llega al final de su ciclo de vida, también cesa la aplicación coordinada de parches para esas dependencias en el contexto de esa versión de Struts.

El módulo struts2-core incorpora OGNL (la biblioteca Object-Graph Navigation Language) como dependencia directa en tiempo de ejecución, y OGNL tiene su propio historial de CVE derivado de su papel como principal motor de evaluación de expresiones, que ha sido objeto de explotación en numerosas vulnerabilidades de Struts. Se incluye FreeMarker para la representación de plantillas. Apache Commons FileUpload gestiona los datos de formularios multiparte y estuvo directamente implicado en CVE-2017-5638. Apache Commons BeanUtils, Commons Collections, Commons IO y Commons Lang son todas dependencias de tiempo de ejecución. Se incluye Log4j2 para el registro: una biblioteca cuyo propio historial de vulnerabilidades críticas (Log4Shell, CVE-2021-44228) generó su propia oleada de parches de emergencia en todo el ecosistema Java. Jackson Databind se encarga del procesamiento de JSON en los complementos. La integración del marco Spring incorpora spring-core, spring-beans, spring-context, spring-web y Spring AOP cuando se utiliza el complemento Spring. Hibernate Validator se integra para la validación de beans.

Cada una de estas dependencias cuenta con su propio flujo de CVE de origen. Cuando una rama de Struts llega al final de su ciclo de vida (EOL), la comunidad deja de publicar actualizaciones coordinadas para todas estas dependencias en el contexto de esa versión de Struts. Los escáneres de vulnerabilidades que se ejecutan en implementaciones de Struts que han llegado al final de su ciclo de vida generarán resultados en todo el árbol de dependencias para los que no existe una corrección oficial disponible para esa versión, lo que deja a los equipos de seguridad con una lista cada vez mayor de resultados de análisis sin resolver.

El árbol de dependencias de Struts2-core abarca más de 20 dependencias directas y transitivas cuando se incluyen los complementos habituales. Cada una de ellas conlleva su propio árbol transitivo. La superficie de parcheo efectiva de una implementación de Struts 2.5.x en producción con un conjunto típico de complementos es considerablemente mayor que la del binario del marco por sí solo, y todos los componentes de ese árbol dejan de recibir una cobertura coordinada cuando la rama principal de Struts llega al final de su vida útil (EOL).

Opciones para garantizar la seguridad y el cumplimiento normativo

Las organizaciones que utilizan versiones de Apache Struts llegadas al final de su ciclo de vida tienen tres opciones. Dos de ellas implican un esfuerzo técnico considerable, riesgos operativos y plazos prolongados. La tercera —el servicio de soporte de ciclo de vida ilimitado de TuxCare— subsana inmediatamente las brechas de seguridad mientras sus equipos planifican la migración adecuadamente.

Opción 1: Migrar a una versión actual de Struts

La solución a largo plazo consiste en migrar la aplicación a una versión de Struts que cuente actualmente con soporte técnico. Las versiones que reciben soporte activo son Struts 6.x y Struts 7.x, siendo la 7.1.1 la versión más reciente a fecha de octubre de 2025.

La realidad práctica, especialmente para las aplicaciones de gran envergadura desarrolladas con Struts 2.5.x, es que no se trata de un simple cambio de versión. Se trata de una migración que implica cambios coordinados en el código fuente de la aplicación, la configuración y el entorno de ejecución. Struts 6.0 requiere como mínimo Java 8 y la API Servlet 3.1; las organizaciones que utilicen entornos Java más antiguos deben actualizar el entorno de ejecución antes de poder proceder a la migración del marco. Todas las constantes de configuración de Struts 2.3 se eliminaron en la versión 6.0; cualquier aplicación que utilice constantes obsoletas debe actualizarse a sus sustitutos. Se reorganizó el espacio de nombres del paquete XWork, lo que requiere actualizaciones de importación en todas las clases Action. El acceso a métodos estáticos mediante expresiones OGNL, un patrón utilizado en muchas aplicaciones de Struts 2.x, se ha eliminado por completo en la versión 6.0 y debe sustituirse por envoltorios de métodos de instancia de Action. La longitud de las expresiones OGNL está limitada a 256 caracteres por defecto, lo que rompe las expresiones más largas que puedan estar dispersas por las plantillas FreeMarker y los JSP.

 

La migración a Struts 7.x conlleva un número considerablemente mayor de requisitos, y dos de ellos suponen un esfuerzo enorme por sí mismos antes incluso de tocar una sola línea de código de Struts. En primer lugar, Struts 7.x requiere Java 17 como entorno de ejecución mínimo. Para las organizaciones que aún utilizan Java 8 o Java 11, algo habitual en las implementaciones de Struts de grandes empresas, esto implica planificar y ejecutar una actualización completa de la JVM en todos los entornos: desarrollo, CI, staging y producción. En segundo lugar, Struts 7.x requiere Jakarta EE, lo que significa que todas y cada una de las importaciones `javax.*` de todo el código fuente deben actualizarse a su equivalente `jakarta.*` correspondiente. Esta migración del espacio de nombres de javax a jakarta afecta a `javax.servlet.*`, `javax.annotation.*`, `javax.persistence.*` y a cualquier otro paquete `javax.*` dondequiera que aparezca en clases de acción, archivos de configuración, interceptores personalizados, JSP y cualquier biblioteca de terceros en el árbol de dependencias que aún no haya publicado versiones compatibles con Jakarta EE. En los grandes códigos base empresariales, esta migración de espacios de nombres por sí sola puede abarcar miles de sentencias de importación en cientos de archivos y requiere una validación de extremo a extremo en cada capa de la pila de la aplicación. Solo después de que se hayan abordado esos dos requisitos previos comienza el trabajo de migración específico de Struts: cada setter de clase Action que acepte parámetros de solicitud debe anotarse explícitamente con `@StrutsParameter`, un cambio que puede afectar a cientos de setters en una aplicación madura. Los valores predeterminados de la asignación de espacios de nombres se modificaron para exigir coincidencias exactas, lo que podría romper enlaces en las plantillas existentes. El anterior interceptor de carga de archivos se eliminó por completo y se sustituyó por el interceptor de carga de archivos de Action, lo que requiere cambios de configuración y de código en las aplicaciones que gestionan la carga de archivos. Para las aplicaciones con una inversión significativa en Struts —que son la mayoría de las aplicaciones para las que la cuestión de la migración es relevante—, una migración a Struts 7.x debidamente planificada y probada se mide en meses, no en semanas.

Opción 2: Migrar a otro marco de desarrollo web

Algunas organizaciones aprovechan el fin de vida útil (EOL) de Apache Struts como motivo para evaluar otros marcos web de Java: Spring MVC, Jakarta EE con Faces, Micronaut, Quarkus u otros. Este argumento arquitectónico tiene su fundamento en algunos contextos, especialmente cuando las arquitecturas modernas basadas en REST se adaptan mejor a las necesidades actuales de la aplicación, o cuando los modelos de implementación nativos de la nube se beneficiarían de un marco más ligero.

Una migración completa del marco de trabajo resulta mucho más costosa que una actualización de la versión de Struts. Las clases de acción, las plantillas JSP, las vistas FreeMarker, los diseños Tiles, las configuraciones de validación, las pilas de interceptores y las asignaciones de struts.xml requieren todas ellas una sustitución o una reelaboración significativa. El modelo de programación es diferente, el modelo de implementación es diferente, y las versiones de Struts en fin de vida útil siguen ejecutándose en producción durante todo el proceso de evaluación, planificación y migración. Se trata de una decisión estratégica de infraestructura que merece su propio calendario cuidadosamente planificado, no uno impuesto por una fecha de fin de vida útil que se adelanta a lo previsto.

Opción 3: Soporte de ciclo de vida ampliado de TuxCare: la opción recomendada

Esta es la opción que resuelve el problema inmediato sin generar otros nuevos. El servicio «Endless Lifecycle Support» de TuxCare para Struts te permite seguir utilizando tu versión actual de Struts en producción, al tiempo que recibes cobertura continua de parches de seguridad para el marco y su árbol de dependencias a través de tu cadena de herramientas existente de Maven o Gradle, sin necesidad de realizar una migración obligatoria.

La brecha de seguridad se subsana de inmediato. Se mantiene el nivel de cumplimiento normativo. Tus equipos tienen libertad para planificar la migración adecuada siguiendo un calendario que tenga sentido desde el punto de vista operativo, incluyendo el margen de tiempo adicional necesario para anotar las clases de acción contra la inyección de parámetros en Struts 7.x, actualizar los patrones de expresión OGNL en todas las plantillas y validar el comportamiento en el conjunto completo de puntos finales de la aplicación. Sin migraciones forzadas bajo la presión de los plazos, sin emergencias de cumplimiento normativo, sin regresiones de comportamiento en las aplicaciones web en producción que dan servicio a usuarios reales.

Los riesgos de precipitarse en la migración a Struts

Cuando aparece un aviso de fin de vida útil (EOL) en un panel de control de seguridad y el equipo de cumplimiento normativo empieza a hacer preguntas, la presión para actuar de inmediato es real. Entender lo que implica realmente una migración apresurada de Struts es tan importante como comprender el riesgo en sí mismo.

En qué consiste realmente una migración de Struts

Una migración adecuada de Struts —especialmente de la versión 2.5.x a la 6.x o 7.x— es un proyecto de aplicación que se desarrolla en varias fases, no una simple actualización de la versión de las dependencias. Requiere auditar todo el código en busca de API obsoletas y características eliminadas, actualizar el entorno de ejecución de Java si la versión actual no alcanza el mínimo requerido por Struts 6.x, actualizar las referencias a la API de Servlet y las configuraciones de los descriptores de implementación, sustituir las constantes de configuración obsoletas en todo el archivo struts.xml, actualizar todas las importaciones de clases Action afectadas por la reorganización del paquete XWork y reescribir las expresiones OGNL que dependan del acceso a métodos estáticos o superen el nuevo límite de 256 caracteres.

Adaptación del código: Todos los setters de la clase Action que acepten parámetros de formulario o de solicitud deben estar anotados con @StrutsParameter en Struts 7.x. En una aplicación grande con docenas o cientos de clases Action, se trata de un cambio sistemático en el código base que requiere una revisión exhaustiva para evitar omitir inadvertidamente puntos de inyección, lo que provocaría fallos silenciosos en el manejo del envío de formularios.

Verificación de compatibilidad: Es necesario revisar todas las plantillas JSP, FreeMarker y Velocity de la aplicación para detectar expresiones OGNL que utilicen el acceso a métodos estáticos, superen los límites de longitud o hagan referencia a bibliotecas de etiquetas obsoletas. Los cambios en el comportamiento de renderización de las plantillas —incluidos los valores predeterminados de escape automático de FreeMarker— pueden introducir diferencias sutiles en la salida que se ponen de manifiesto en las pruebas de extremo a extremo.

Adaptación de la cadena de herramientas: Es necesario revisar y actualizar las configuraciones de compilación, los flujos de CI/CD y los descriptores de implementación que hacen referencia a complementos específicos de Struts, declaraciones DTD y constantes de configuración. El complemento Tiles sufrió cambios a lo largo de las versiones; la compatibilidad con Velocity se trasladó a un complemento específico. Cualquier dependencia de complemento que se haya eliminado en la versión de destino debe sustituirse o eliminarse de la compilación.

Carga de las pruebas: No se pueden omitir las pruebas exhaustivas de extremo a extremo en toda la aplicación, que abarcan el envío de formularios, la carga de archivos, los flujos de validación, el comportamiento de los interceptores y la representación de resultados. Los cambios de comportamiento en el modelo de inyección de parámetros, los valores predeterminados de asignación de espacios de nombres y la semántica de evaluación de OGNL deben validarse con patrones de solicitud realistas antes del lanzamiento en producción.

¿Qué ocurre cuando se precipita una migración?

Cuando los equipos se ven obligados a acelerar este trabajo bajo la presión de los plazos, las consecuencias son previsibles y siguen un patrón constante.

Aumento de la carga de asistencia técnica: Las lagunas en las anotaciones de las clases Action, las actualizaciones omitidas de expresiones OGNL y los cambios no verificados en la representación de plantillas se manifiestan en producción como errores en el envío de formularios, flujos de validación defectuosos y un comportamiento inesperado en la representación de las páginas. Esto genera una oleada de incidencias que los equipos de ingeniería y operaciones deben gestionar además de su carga de trabajo habitual.

Inestabilidad del sistema: Las aplicaciones Struts suelen sustentar flujos de trabajo orientados al cliente, como solicitudes de préstamos, portales para pacientes y tramitaciones de servicios públicos, en los que las regresiones de comportamiento afectan de forma inmediata a los usuarios reales. Pequeños cambios en la vinculación de parámetros, en el orden de ejecución de los interceptores o en la representación de los resultados pueden provocar fallos intermitentes que son difíciles de reproducir y que se manifiestan ante volúmenes de solicitudes en producción que las pruebas de preproducción rara vez alcanzan.

Acumulación de deuda técnica: Las soluciones provisionales implementadas bajo presión de tiempo se convierten en permanentes. Las clases de acción anotadas en masa sin revisión introducen puntos de inyección de parámetros no deseados. Las expresiones OGNL se refactorizaron rápidamente sin comprender las implicaciones de seguridad del nuevo modelo de lista de permitidos, creando vulnerabilidades que no existían antes de la migración. El problema del fin de vida útil (EOL) de Apache Struts se ha aplazado, no resuelto.

Costes imprevistos: Las horas de ingeniería de emergencia, los retrasos en el lanzamiento de nuevas funciones, los gastos generales de respuesta a incidentes y el coste de oportunidad que supone que los ingenieros sénior dediquen su tiempo a depurar fallos en las aplicaciones web de producción en lugar de desarrollar nuevas capacidades se acumulan rápidamente y de formas difíciles de predecir con antelación.

La solución sencilla: TuxCare ELS para Apache Struts EOL

TuxCare ofrece soporte técnico de ciclo de vida ilimitado para las versiones de Struts que han llegado al final de su vida útil. En lugar de forzar una migración para la que tus equipos aún no están preparados, puedes seguir utilizando tu implementación actual de Struts con cobertura continua de parches de seguridad a través de tu cadena de herramientas de compilación Maven o Gradle existente.

TuxCare lleva más de una década dedicándose a esto, proporcionando parches de seguridad para sistemas operativos, entornos de ejecución, bibliotecas y marcos de aplicaciones que han llegado al final de su ciclo de vida. Han distribuido más de 220 000 parches de seguridad en todo el ecosistema de código abierto. Cuando afirman que saben cómo mantener seguro el software al final de su ciclo de vida a escala empresarial, no se trata de mera retórica comercial. Lo han hecho a gran escala y de forma constante.

Cobertura completa del árbol de dependencias: El ELS de TuxCare para Struts cubre el marco y sus dependencias directas y transitivas, incluyendo OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Commons Collections, Log4j2 y otras bibliotecas que conllevan su propia exposición a CVE sin coste adicional. Los escáneres de vulnerabilidades no respetan los límites de los paquetes, y tampoco lo hace la cobertura de TuxCare. Se aborda toda la superficie de parcheo, no solo el artefacto Struts de nivel superior.

Proceso de aplicación de parches optimizado y automatizado: TuxCare supervisa el NVD, los avisos de seguridad de los proveedores, la propia lista CVE de Apache y los canales de seguridad de GitHub, todos los canales en los que se divulgan las vulnerabilidades de Struts y sus dependencias. Cuando se identifica un CVE, las herramientas algorítmicas y la automatización asistida por IA se encargan de adaptar las correcciones de seguridad a la versión compatible, y los expertos en seguridad validan cada parche antes de su distribución. Cada actualización se somete a pruebas de integridad, funcionalidad y regresión antes de llegar a sus repositorios. Para obtener todos los detalles técnicos, consulte el informe técnico de TuxCare sobre su proceso de aplicación de parches de código abierto.

Integración perfecta: Tanto si actualmente utiliza Struts a través de Maven como de Gradle, puede cambiar su fuente de actualizaciones al repositorio seguro de TuxCare con cambios mínimos en su flujo de trabajo actual. No hay cambios en su canal de compilación, ni en sus flujos de trabajo de CI/CD, ni en la forma de trabajar de sus equipos. Las actualizaciones de seguridad se distribuyen automáticamente a través de su cadena de herramientas existente.

Respuesta rápida respaldada por un acuerdo de nivel de servicio (SLA): Cuando se revelan nuevas vulnerabilidades en versiones de Apache Struts fuera de ciclo de vida (EOL), ya sea en el propio marco o en su árbol de dependencias, TuxCare proporciona parches en un plazo garantizado respaldado por acuerdos de nivel de servicio. Las vulnerabilidades de gravedad alta y crítica (CVSS 7+) se abordan en un plazo de 14 días desde su divulgación pública. No tendrá que esperar a un backport de la comunidad que nunca llegará para una versión de Struts fuera de ciclo de vida. Obtendrá parches listos para producción en un plazo que podrá planificar, con soporte de expertos las 24 horas del día, los 7 días de la semana, para la clasificación de vulnerabilidades y la resolución de problemas.

Continuidad de la seguridad a un precio asequible: El coste de TuxCare ELS es una fracción de lo que cuesta una migración de emergencia del marco de trabajo cuando se ve obligada por un plazo de cumplimiento en cuanto a tiempo de ingeniería, riesgo operativo, respuesta a incidentes y retrasos en el trabajo de la hoja de ruta. Una cobertura de seguridad predecible, un calendario de migración controlado y la ausencia de emergencias de cumplimiento son los factores que hacen que el soporte ampliado sea la estrategia empresarial adecuada.

Para ver exactamente qué vulnerabilidades se han solucionado en las versiones de Struts que han llegado al final de su ciclo de vida, TuxCare mantiene un rastreador CVE en tiempo real para Struts.

No dejes que el fin de la vida útil de Apache Struts ponga en riesgo tus aplicaciones web

El fin de la vida útil (EOL) de Apache Struts no significa que tu aplicación quede comprometida de inmediato, ni que debas llevar a cabo una migración de emergencia para la que tus equipos no estén preparados. Sin embargo, este estado de EOL de Apache Struts sí implica que la protección de seguridad de la que dependía la infraestructura de tu aplicación web ya no existe, y la filtración de Equifax demostró con claridad cuáles son las consecuencias a gran escala de dejar Struts sin parches.

Las organizaciones que gestionan bien esta situación son aquellas que consideran este estado de fin de vida útil (EOL) como un problema de seguridad que hay que gestionar, y no como una fecha límite a la que hay que reaccionar bajo presión. Se puede planificar una migración meditada a Struts 6.x o 7.x cuando realmente se ajuste a la capacidad de su equipo, incluyendo el tiempo adicional necesario para anotar correctamente las clases Action, actualizar los patrones de expresión OGNL en toda la capa de plantillas y validar el comportamiento en todo el conjunto de puntos finales. Puede evaluar si una migración más amplia del marco de trabajo tiene una finalidad arquitectónica real. O puede utilizar TuxCare ELS para mantener la seguridad y el cumplimiento normativos al máximo mientras toma esas decisiones según su propio calendario, y no el de un auditor de cumplimiento.

El soporte ampliado no es una solución provisional. Es la opción que mantiene la seguridad de tus aplicaciones Struts, garantiza el cumplimiento normativo y permite que tus equipos de ingeniería se centren en desarrollar, en lugar de en apagar incendios. Si el fin de la vida útil (EOL) de Apache Struts figura actualmente entre tus prioridades de seguridad, visita el soporte de ciclo de vida ilimitado de TuxCare para software de código abierto para ver cómo el soporte extendido puede proteger su infraestructura de aplicaciones web durante todo el tiempo que necesite.