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
- Las dependencias multiplican tu superficie de vulnerabilidad: El riesgo derivado de que Velocity haya llegado al final de su ciclo de vida puede extenderse más allá de los archivos JAR del motor y las herramientas a dependencias de tiempo de ejecución vulnerables, como commons-collections 3.2.1 y, en los casos en que se utilice, Log4j 1.x.
- Las migraciones precipitadas son costosas y arriesgadas: Acelerar la transición de Engine 1.7 a la línea 2.x bajo la presión de los plazos de cumplimiento supone cambiar un riesgo de seguridad por un nuevo riesgo de regresión.
- El fin de la vida útil (EOL) de Apache Velocity no tiene por qué significar el fin de la seguridad: TuxCare ELS ofrece cobertura continua de parches de seguridad para las versiones de Velocity que han llegado al final de su vida útil, mientras planificas una migración controlada según tu propio calendario.
Si Apache Velocity aparece en algún punto del gráfico de dependencias de tu aplicación Java —y sigue siendo habitual en entornos Java empresariales más antiguos—, conviene conocer su estado de fin de vida útil (EOL) antes de que un escáner de seguridad o una auditoría de cumplimiento te obligue a abordar el tema.
Velocity Engine 1.7, la versión final de la línea 1.x, no ha recibido ninguna nueva versión del proyecto original desde noviembre de 2010. Velocity Tools 2.0 tampoco ha recibido ninguna nueva versión desde mayo de 2010, mientras que el desarrollo de Apache ha continuado en las líneas Engine 2.x y Tools 3.x. El registro CVE correspondiente a ambos componentes antiguos pone de manifiesto la vulnerabilidad, y su uso en entornos de producción sin parches conlleva consecuencias reales en materia de cumplimiento normativo.
En este artículo se explica qué significa en la práctica el fin de vida útil (EOL) de Apache Velocity, cuál es su historial en materia de seguridad y cómo TuxCare ELS para Apache Velocity ofrece a tu organización una vía para mantener la seguridad sin obligar a realizar una migración para la que tus equipos aún no están preparados.
¿Qué es Apache Velocity y por qué sigue utilizándose tanto?
Apache Velocity es un motor de plantillas basado en Java que utiliza el lenguaje de plantillas Velocity (VTL), lo que permite a los desarrolladores incorporar directivas dinámicas en plantillas de texto sin formato. En tiempo de ejecución, el motor Velocity fusiona las plantillas con modelos de datos Java para generar el resultado final. Su separación entre la presentación y la lógica de la aplicación contribuyó a que Velocity se convirtiera en una opción de plantillas ampliamente adoptada en las aplicaciones Java empresariales a lo largo de la década de los 2000 y hasta bien entrada la década de los 2010.
El proyecto Apache Velocity incluye dos componentes principales con líneas de versiones e historiales de lanzamientos independientes:
- Velocity Engine: El motor de ejecución de plantillas principal, que se encarga del análisis sintáctico de VTL, la ejecución de directivas, la expansión de macros y la resolución de variables de contexto.
- Herramientas de Velocity: Integraciones de marcos web basadas en el motor, entre las que se incluyen VelocityViewServlet para aplicaciones basadas en servlets, además de conjuntos de herramientas para el formato de fechas, la generación de URL y utilidades comunes para la capa de vista.
Velocity se integró profundamente en Apache Struts, en configuraciones antiguas de Spring MVC, en Apache Turbine y en plataformas CMS de Java, incorporándose a menudo a las aplicaciones como una dependencia transitiva a varios niveles de profundidad. También se convirtió en una opción habitual para los sistemas de plantillas de correo electrónico y los generadores de informes, que rara vez se modernizan. Esa fiabilidad puede crear un punto ciego en cuanto al fin de vida útil (EOL): Velocity suele permanecer integrado en aplicaciones de larga duración precisamente porque sigue funcionando, lo que hace que sea fácil pasarlo por alto hasta que un escáner de vulnerabilidades lo identifica.
Fin de vida útil de Apache Velocity: el ciclo de vida de las versiones
Apache Velocity publica correcciones a través de nuevas versiones, mientras que las versiones anteriores se trasladan a los archivos de Apache. Por lo tanto, es fundamental conocer la cronología del componente para evaluar los riesgos en toda tu pila de aplicaciones.
| Componente | Última versión | Estado actual de la versión |
| Velocity Engine 1.x | v1.7 – 29 de noviembre de 2010 | Obligado; la última versión 1.x está archivada |
| Velocity Tools 2.x | v2.0 – 10 de mayo de 2010 | Obligado; la última versión 2.x está archivada |
| Velocity Engine 2.x | v2.4.1 – 14 de octubre de 2024 | Línea de producción actual |
| Velocity Tools 3.x | v3.1 – Febrero de 2021 | Línea de producción actual |
Velocity Engine 1.7 fue la última versión de la serie 1.x y se convirtió en la versión predeterminada de Velocity integrada en toda una generación de marcos de trabajo de Java. La línea Engine 2.x introdujo cambios importantes en la API con respecto a la 1.x, y muchos marcos de trabajo de origen no actualizaron su dependencia fija de Velocity durante años, lo que hizo que la versión 1.7 siguiera utilizándose de forma generalizada hasta bien entrados los años 2020. Velocity Tools 2.0 tampoco ha tenido ninguna nueva versión desde 2010; ambos componentes han sido sustituidos por versiones principales más recientes y ya no reciben nuevas versiones en sus respectivas líneas de versiones.
Apache remite a los usuarios a sus versiones actuales y archiva las versiones anteriores, sin que exista ningún programa publicado de mantenimiento de seguridad ni de retroportación de parches para las líneas Engine 1.x o Tools 2.x. Esto deja a las organizaciones que utilizan esas versiones sin una fuente documentada de nuevas correcciones de seguridad por parte del desarrollador original; precisamente esa es la laguna que TuxCare ELS para Apache Velocity está diseñado para cubrir.
El historial de CVE que determina el riesgo de fin de vida útil (EOL) de Apache Velocity
El fin de vida útil (EOL) de Apache Velocity no significa que dejen de descubrirse vulnerabilidades en las versiones que han llegado al final de su vida útil; significa que esas versiones ya no reciben correcciones del desarrollador original. Los motores de plantillas pueden ser objetivos muy valiosos, ya que a menudo procesan plantillas o datos influenciados por los usuarios dentro del contexto de ejecución de una aplicación. En configuraciones vulnerables, los fallos en la frontera entre la lógica de las plantillas y el entorno de ejecución de la aplicación pueden acarrear consecuencias tan graves como la ejecución remota de código, y el estado de fin de vida útil elimina la red de seguridad que suponen los parches del desarrollador original precisamente contra este tipo de ataques.
| ID de la CVE | NVD CVSS 3.1 | Componente afectado | Impacto |
| 13936 | 8,8 Alto | Motor 1.x y 2.0–2.2 | Elusión del entorno de pruebas → ejecución remota de código |
| 7501 | 9,8 Crítico | commons-collections 3.2.1 | Cadena de vulnerabilidades de deserialización en Java → RCE (en configuraciones vulnerables) |
| 17571 | 9,8 Crítico | Log4j 1.x (backend opcional) | Ejecución remota de código en SocketServer (cuando está habilitada) |
CVE-2020-13936: Elusión del entorno de pruebas y ejecución remota de código
La vulnerabilidad CVE-2020-13936 (NVD CVSS 3.1: 8,8 —Alta—) afecta a las versiones de Velocity Engine hasta la 2.2, incluida, lo que sitúa a toda la línea 1.x dentro del ámbito de la vulnerabilidad. Un atacante capaz de modificar plantillas de Velocity podría ejecutar código Java arbitrario o comandos del sistema con los privilegios de la cuenta que ejecuta el contenedor de servlets. Esta vulnerabilidad de inyección de plantillas del lado del servidor fue notificada por GitHub Security Lab con el número GHSL-2020-048 y, posteriormente, se abordó en avisos de seguridad de múltiples proveedores y distribuciones.
La vulnerabilidad CVE-2020-13936 se corrigió en Velocity Engine 2.3, lanzada en febrero de 2021, más de una década después de que se publicara la última versión 1.x en noviembre de 2010. Cuando esta vulnerabilidad se hizo pública en marzo de 2021, Engine 1.7 llevaba más de diez años sin una versión oficial, y nunca se publicó ninguna corrección para la línea 1.x.
Para las organizaciones que utilizan la versión 1.7 de Engine, que ha llegado al final de su ciclo de vida, las opciones de corrección más directas son actualizar a una versión corregida y con soporte técnico, o aplicar un parche retrocompatible proporcionado por un proveedor como TuxCare. Restringir quién puede cargar o modificar plantillas de Velocity puede reducir la exposición, pero dichos controles no sustituyen a la aplicación de parches cuando la funcionalidad vulnerable sigue siendo accesible.
El riesgo oculto: la huella de dependencia de Velocity
Velocity Engine 1.7 depende de commons-collections 3.2.1 y commons-lang 2.4 para su funcionalidad general en tiempo de ejecución; Jakarta ORO 2.0.8 solo es necesario para determinadas funciones, como el escape automático de referencias. Log4j 1.x es un backend de registro opcional que solo se utiliza cuando las aplicaciones configuran Velocity para registrar a través de Log4j. Dos componentes de este ecosistema presentan vulnerabilidades CVE con una puntuación CVSS de 9,8 (crítica):
commons-collections 3.2.1: CVE-2015-7501 (CVSS 9,8, crítica). Esta versión puede formar parte de cadenas de exploits de deserialización de Java cuando una aplicación deserializa datos no fiables a través de una ruta de código vulnerable; se trata del mismo tipo de exploit que afectó a WebSphere, JBoss, WebLogic y Jenkins cuando se dio a conocer en 2015. Velocity Engine 1.7 utiliza la versión afectada, aunque la posibilidad real de explotación depende de cómo gestione la aplicación en cuestión los objetos serializados.
Log4j 1.x: CVE-2019-17571 (CVSS 9,8, crítica). Log4j 1.x dejó de recibir soporte en agosto de 2015, y toda la rama 1.x ya no recibe parches para las vulnerabilidades CVE reveladas posteriormente. Las aplicaciones que utilicen Log4j 1.x con Velocity pueden verse expuestas a la vulnerabilidad CVE-2019-17571, que permite la ejecución remota de código, si habilitan y exponen el componente SocketServer vulnerable.
Los escáneres de vulnerabilidades detectan problemas en este árbol de dependencias para los que no existe una corrección oficial por parte del desarrollador original. TuxCare ELS para Apache Velocity amplía la cobertura más allá de los artefactos de Velocity de primer nivel a los componentes compatibles del árbol de dependencias transitivas.
Cumplimiento y exposición a la normativa
Según la norma PCI DSS v4.0, el requisito 6.3.3 establece que los parches y las actualizaciones para las vulnerabilidades clasificadas como críticas en el entorno de una organización deben instalarse en el plazo de un mes desde su publicación; las demás actualizaciones de seguridad aplicables deben instalarse dentro de los plazos establecidos en la evaluación de riesgos de la organización (conforme al requisito 6.3.1).
Dado que la norma PCI DSS no clasifica automáticamente como crítica toda vulnerabilidad con una puntuación CVSS de 7,0 o superior, el impacto en el cumplimiento de la norma de la vulnerabilidad CVE-2020-13936 —pública desde marzo de 2021— depende de la clasificación de riesgos, la exposición y los controles documentados por la organización. Otros marcos y programas de garantía, como la HIPAA, el SOC 2 Tipo II y el FedRAMP, también pueden exigir a las organizaciones que identifiquen, evalúen y solucionen las vulnerabilidades pertinentes, aunque sus requisitos deben evaluarse por separado.
ELS para Apache Velocity ayuda a las organizaciones a solucionar las vulnerabilidades pertinentes en plazos previsibles sin obligarlas a realizar una migración inmediata.
Los riesgos de precipitarse en la migración a Apache Velocity
La presión para dar respuesta a los hallazgos relacionados con el fin de vida útil (EOL) de Apache Velocity es real. Las herramientas de SCA generan hallazgos, los auditores plantean preguntas directas y los plazos de cumplimiento no se aplazan debido a las limitaciones de capacidad de ingeniería. Los equipos que gestionan adecuadamente el fin de vida útil de Apache Velocity abordan la migración como un proyecto de ingeniería planificado, con un inventario completo de plantillas, pruebas de regresión y una ruta de reversión definida.
¿Qué pasa si te precipitas?
Cuando los equipos condensan la migración en un plazo poco realista, las cosas se tuercen de formas previsibles:
- Aumento de la carga de asistencia técnica: Los errores que no se detectan durante las pruebas comprimidas aparecen inmediatamente en producción. Los equipos de soporte se ven desbordados por incidencias relacionadas con la visualización defectuosa de plantillas y cambios en el comportamiento de los flujos de correo electrónico o de informes, la mayoría de las cuales se deben a diferencias en VTL o API entre Engine 1.x y 2.x que nunca se validaron por completo debido a la prisa con la que se llevó a cabo el proyecto.
- Inestabilidad del sistema: Algunos cambios en la API de dependencias solo se manifiestan bajo carga de producción. Los fallos intermitentes en la representación de plantillas, las diferencias de formato en la salida de las cajas de herramientas actualizadas y el cambio en el comportamiento de gestión de errores de VelocityViewServlet generan fallos que son difíciles de reproducir y costosos de diagnosticar.
- Acumulación de deuda técnica: Las diferencias de configuración se incorporan al código de inicialización de la aplicación en lugar de solucionarse en el nivel de la biblioteca. Los cambios en el comportamiento de VTL entre las versiones 1.x y 2.x se solucionan de forma local mediante métodos no documentados. El problema del fin de vida útil (EOL) se aplaza, no se resuelve, y la deuda acumulada encarece la migración adecuada en el futuro.
- Costes imprevistos: Las horas de ingeniería de emergencia, los retrasos en el lanzamiento de nuevas funcionalidades y el coste de oportunidad que supone que tus mejores ingenieros se dediquen a solucionar problemas de compatibilidad entre dependencias en lugar de desarrollar nuevas capacidades suelen superar lo que habría costado el soporte de ciclo de vida ampliado durante todo el periodo de planificación de la migración.
Opciones para garantizar la seguridad y el cumplimiento normativo
Las organizaciones que utilizan versiones de Apache Velocity que han llegado al final de su ciclo de vida tienen tres opciones. Las dos primeras requieren un trabajo de ingeniería considerable y plazos prolongados. La tercera soluciona rápidamente la brecha de seguridad mientras tus equipos planifican la migración adecuadamente.
Opción 1: Migrar a Velocity Engine 2.4.1 y Tools 3.1
La solución a largo plazo consiste en migrar a las versiones actuales del proyecto original: Velocity Engine 2.4.1 y Velocity Tools 3.1, en el momento de redactar este artículo. De este modo, se elimina el riesgo de que el producto llegue al final de su vida útil al pasar a utilizar software que recibe mantenimiento activo.
La migración tiene un alcance real: todas las versiones de Engine desde la 2.1 (marzo de 2019) requieren Java 8 como entorno de ejecución mínimo, incluida la 2.4.1, por lo que es posible que las organizaciones que ejecuten Velocity 1.7 en entornos JVM más antiguos tengan que actualizar Java antes de migrar a cualquier versión moderna de la serie 2.x. Los cambios en la API entre Engine 1.7 y 2.x —clases eliminadas, configuración revisada de ResourceLoader e interfaces de introspección y registro modificadas— pueden requerir cambios en el código de las aplicaciones que amplían o configuran Velocity a través de sus API de Java. Tools 3.1 amplía aún más el alcance con la reestructuración de paquetes y la integración revisada de servlets.
En el caso de las aplicaciones empresariales con múltiples puntos de integración con Velocity, la migración puede requerir meses de inventario, modificaciones en el código y pruebas de regresión.
Opción 2: Sustituir Velocity por otro motor de plantillas
Algunas organizaciones utilizan el hito de fin de vida útil (EOL) de Apache Velocity como motivo para evaluar alternativas: Thymeleaf, FreeMarker, Pebble y Mustache cuentan con un mantenimiento activo. La sustitución del motor de plantillas supone una interrupción mayor que una actualización dentro de la misma versión; por lo general, es necesario reescribir o adaptar las plantillas a la sintaxis del nuevo motor, y hay que volver a probar todas las rutas de salida afectadas. Se trata de un objetivo viable a largo plazo, no de una solución para un problema inmediato de cumplimiento normativo derivado del fin de vida útil de Apache Velocity.
Opción 3: Utilizar el servicio de asistencia técnica de ciclo de vida ilimitado durante la migración
El servicio Endless Lifecycle Support (ELS) de TuxCare para Apache Velocity te permite mantener la seguridad sin tener que llevar a cabo una migración para la que tu equipo aún no esté preparado. Podrás seguir utilizando tu versión actual de Velocity con cobertura continua de parches de seguridad. ELS para Apache Velocity está diseñado precisamente para cubrir este vacío: el periodo comprendido entre el momento en que finaliza el soporte oficial y el momento en que tu organización haya completado realmente una migración planificada y controlada.
La solución sencilla: TuxCare ELS para Apache Velocity
TuxCare ofrece soporte de ciclo de vida ilimitado para las versiones de Apache Velocity que han llegado al final de su vida útil, lo que garantiza la protección de tu implementación actual mediante parches de seguridad que se distribuyen como archivos JAR de sustitución directa a través de tu cadena de herramientas existente de Maven o Gradle. TuxCare ha distribuido más de 220 000 parches de seguridad en todo el ecosistema de código abierto.
Cobertura completa del árbol de dependencias
TuxCare ELS para Apache Velocity va más allá de los archivos JAR del motor y las herramientas para abarcar los componentes compatibles incluidos en la huella de dependencias transitivas, entre los que se encuentran commons-collections 3.2.1 (CVE-2015-7501, CVSS 9,8 —crítico—) y, para las aplicaciones que lo utilicen, Log4j 1.x (CVE-2019-17571, CVSS 9,8 — crítico).
Proceso de aplicación de parches optimizado y automatizado
TuxCare supervisa el NVD, los avisos de seguridad de Apache, los canales de seguridad de GitHub y los canales de divulgación de los proveedores las 24 horas del día. Cuando se identifica un CVE relevante, TuxCare retroaplica la corrección a las versiones compatibles mediante automatización algorítmica y asistida por IA, 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 tus repositorios. Para obtener todos los detalles técnicos, consulta el documento técnico «Proceso de aplicación de parches de código abierto de TuxCare».
Integración perfecta
Tanto si utilizas Velocity a través de Maven Central como de un repositorio privado espejo, puedes cambiar tu fuente de actualización al repositorio seguro de TuxCare con unos cambios mínimos en la configuración de tu repositorio. Los archivos JAR parcheados están diseñados como sustitutos directos que conservan la API y la configuración existentes, al tiempo que incorporan correcciones de seguridad retrocompatibles, por lo que la mayoría de los equipos pueden utilizarlos a través de sus flujos de trabajo de Maven o Gradle y sus procesos de CI/CD ya existentes.
Respuesta rápida respaldada por el SLA
Cuando se dan a conocer nuevas vulnerabilidades que afectan a versiones de Velocity en fin de vida útil para las que se ofrece soporte —ya sea en el motor, en las herramientas o en las dependencias cubiertas—, TuxCare proporciona parches respaldados por acuerdos de nivel de servicio, con el objetivo de corregir las vulnerabilidades de gravedad alta y crítica (CVSS 7.0 y superior) en un plazo de 14 días desde su divulgación pública.
Continuidad de la seguridad a un coste razonable
El coste de TuxCare ELS es una fracción de lo que cuesta una migración de emergencia bajo la presión de los plazos de cumplimiento normativo. Puedes planificar una migración metódica a Velocity Engine 2.4.1 y Tools 3.1 cuando se adapte a la capacidad de tu equipo, incluyendo el tiempo necesario para evaluar el impacto total de las dependencias transitivas y validar cada ruta de salida de las plantillas. O bien, puedes utilizar ELS para mantener la cobertura de los parches de seguridad y respaldar tus esfuerzos de cumplimiento normativo, al tiempo que tomas esas decisiones según tu propio calendario.
No dejes que el fin de la vida útil de Apache Velocity ponga en riesgo tus aplicaciones Java
El fin de vida útil (EOL) de Apache Velocity no significa que tu aplicación quede comprometida de inmediato. Lo que sí significa es que pueden quedar componentes con vulnerabilidades conocidas en tu árbol de dependencias de producción —incluida una vulnerabilidad de Velocity con una puntuación CVSS de 8,8 (alta) y vulnerabilidades en las dependencias con puntuaciones de hasta CVSS 9,8 (crítica)— y que el proyecto original no las corregirá.
Que cada vulnerabilidad sea explotable depende de la configuración de tu aplicación, los flujos de datos y los controles de seguridad, pero cada mes que pasa tras la divulgación de un CVE relacionado con una versión fuera de soporte es un mes durante el cual la ventana de exposición permanece abierta.
La respuesta adecuada ante el fin de la vida útil de Apache Velocity depende del calendario y la capacidad técnica de tu organización. Si puedes migrar ahora mismo a Engine 2.4.1 y Tools 3.1, esa es la opción más adecuada. Si la complejidad de tu integración con Velocity hace que una actualización inmediata no sea viable, TuxCare ELS para Apache Velocity te ofrece una cobertura continua de parches de seguridad mientras planificas y completas la migración de forma adecuada.
Si el fin de la vida útil de Apache Velocity es una de tus prioridades de seguridad en estos momentos, visita el servicio de soporte de ciclo de vida ilimitado de TuxCare para software de código abierto para descubrir cómo el soporte ampliado puede proteger toda tu pila de software de código abierto.
