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
- Commons Lang está presente en todas las pilas de Java empresarial, por lo que una sola copia sin parchear se convierte en un problema generalizado.
- Apache ofrece correcciones en versiones posteriores en lugar de ramas de retroportabilidad, por lo que las versiones antiguas de la serie 3.x dejan de recibirlas.
- Las actualizaciones precipitadas salen mal porque
commons-lang3suele llegar de forma transitiva, y las sorpresas de mediación aparecen en tiempo de ejecución. - El ELS de TuxCare publica versiones parcheadas de versiones anteriores de Commons Lang, para que sigas estando protegido mientras te organizas.
Commons Lang es esa dependencia sobre la que nadie convoca una reunión. Te proporciona los ayudantes que el JDK nunca incluyó, StringUtils y ClassUtils y NumberUtils y las clases de generadores, para luego pasar a un segundo plano en todos los servicios que tengas. No carga nada en tiempo de ejecución, casi nunca falla y lleva funcionando discretamente desde que se lanzó Commons Lang 1.0 en 2002. MvnRepository lo sitúa actualmente en lo más alto de la categoría «Core Utilities», con unos 50 000 artefactos que figuran como usuarios del mismo, lo cual es una forma educada de decir que es casi seguro que se encuentra en algún lugar de tu archivo de compilación.
Eso es precisamente lo que hace que una copia obsoleta resulte molesta. Una vulnerabilidad CVE en una biblioteca a la que solo accede tu servicio de facturación afecta únicamente a ese servicio. Una vulnerabilidad CVE en commons-lang3 aparece en cualquier lugar donde tu código lo llame, y en muchos entornos Java empresariales se trata de una larga lista de lugares de los que nadie tiene un inventario claro.
Aquí está el punto que suele pillar desprevenidos a los equipos. Apache no publica una fecha de fin de vida útil para las versiones individuales de Commons Lang. No hay ningún aviso de fin de vida útil, ni ningún comunicado que te indique que la rama en la que te encuentras ha dejado de recibir actualizaciones. Tampoco se ofrece una rama mantenida para tu versión anterior, por lo que, una vez que una corrección se incorpora a una versión más reciente, por lo general no hay una línea de mantenimiento que la traslade a la tuya.
Cómo gestiona realmente Apache Commons Lang las versiones
Vale la pena tenerlo claro antes de acabar discutiendo con un escáner por este tema.
Empecemos por la división. Apache lanzó Commons Lang 3.0 en 2011 con un cambio deliberado en el espacio de nombres de los paquetes. La línea 2.x se encuentra en org.apache.commons.lang y la versión 3.x se encuentra en org.apache.commons.lang3. Eso se hizo a propósito para que ambas versiones pudieran coexistir en la misma ruta de clases sin entrar en conflicto, razón por la cual muchas bases de código de gran tamaño siguen incluyendo ambas. En lo que respecta a su ciclo de vida, la versión 2.x ha llegado a su fin en todos los aspectos relevantes. La última versión fue la 2.6, lanzada en 2011; el desarrollo pasó a la línea 3.x y no se ha publicado nada desde entonces. Quienes sigan utilizando la versión 2.x llevan desde 2011 sin recibir las correcciones del proyecto original.
La línea 3.x funciona de forma diferente a lo que la mayoría de la gente supone. Apache no mantiene ramas paralelas de soporte a largo plazo como lo hace el JDK. Las correcciones se incorporan a la siguiente versión, y el historial de versiones publicado no muestra ninguna rama de mantenimiento 3.12.x ni ninguna rama de retroportabilidad 3.17.x. Así que, aunque Apache nunca ha declarado formalmente el fin de la vida útil de ninguna versión 3.x, el resultado práctico es el mismo. Si una corrección se incluye en una versión más reciente, no llegará a la tuya.
Vale la pena aclarar bien esa distinción cuando se redacte el informe para un auditor. «No hay ninguna versión de retroportabilidad upstream para esta versión» es una afirmación precisa y defendible. «Fin de vida útil oficial a partir de una fecha concreta» no lo es, ya que Apache nunca ha publicado ninguna.
A fecha de septiembre de 2026, la versión más reciente es la 3.20.0, publicada el 12 de noviembre de 2025. También conviene conocer los requisitos mínimos de Java. A partir de la versión 3.9, la biblioteca requiere Java 8, por lo que todas las versiones a partir de la 3.9 necesitan Java 8 o posterior, y la integración continua (CI) del proyecto se ejecuta actualmente con las versiones LTS compatibles, es decir, las 8, 11, 17, 21 y 25.
| Línea de versión | Espacio de nombres del paquete | Situación actual | Último lanzamiento |
|---|---|---|---|
| Commons Lang 2.x | org.apache.commons.lang |
El desarrollo ha finalizado; no se han realizado correcciones desde 2011 | 2,6 (2011) |
| Commons Lang 3.x, versiones anteriores | org.apache.commons.lang3 |
Todavía se distribuye en la versión de producción, pero no hay rama de retroportabilidad | n/a, derogado |
| Commons Lang 3.x, versión actual | org.apache.commons.lang3 |
Dónde se aplican realmente las correcciones | 3.20.0 (noviembre de 2025) |
Qué significa en la práctica el fin de vida útil (EOL) de Commons Lang
Ya no recibes las actualizaciones
La vulnerabilidad CVE-2025-48924, dada a conocer en julio de 2025, es un buen ejemplo precisamente porque carece de atractivo. ClassUtils.getClass() resolvía los nombres de clases anidadas de forma recursiva, por lo que una entrada lo suficientemente larga podía agotar la pila y provocar un StackOverflowError. Dado que se trata de un error y no de una excepción, las aplicaciones no suelen gestionarlo, y el fallo puede provocar que la aplicación se bloquee. Apache le otorgó una calificación baja, el ADP de la CISA le asignó una puntuación de 5,3 y fue detectado por OSS-Fuzz. Nunca iba a ser noticia.
Lo interesante es su forma. La recomendación abarca las versiones 2.0 a 2.6 de commons-lang y todas las commons-lang3 versiones desde la 3.0 hasta la 3.18.0, excluida esta última, que incorpora la corrección del desarrollador original. No existe una versión 3.17.0 parcheada por el desarrollador original. Si un marco de trabajo te obliga a quedarte en esa versión, o si hay una congelación de cambios, o si nadie dispone del presupuesto necesario para realizar pruebas de regresión de una biblioteca de utilidades en cuarenta servicios, ese hallazgo permanecerá indefinidamente en el resultado de tu escáner.
Una cosa que hay que tener clara al evaluar la gravedad de los problemas es que una vulnerabilidad CVE de Commons Lang recién revelada no afecta automáticamente a la versión que estés utilizando. Muchas de ellas no lo harán. Lo que supone el fin de la vida útil (EOL) es que ya no se pueden corregir aquellas que sí afectan sin tener que cambiar también de versión.
Cuando el cumplimiento normativo se complica
El requisito 6.3.3 de la norma PCI DSS v4.0.1 exige que los parches para vulnerabilidades críticas —clasificadas mediante el proceso establecido en el requisito 6.3.1— se apliquen en el plazo de un mes desde su publicación. Todo lo demás se rige por un plazo que usted mismo determina en función de su propia evaluación del grado de gravedad del riesgo para su entorno. La norma PCI DSS v4.0 también había aplicado ese plazo de un mes a los parches críticos o de alta seguridad, y la versión v4.0.1 lo limitó de nuevo a las vulnerabilidades críticas.
Otros marcos normativos son menos prescriptivos, y exagerar su importancia es una forma segura de perder a un lector con conocimientos técnicos. FedRAMP establece plazos de corrección en función de la gravedad. La Norma de Seguridad de la HIPAA exige realizar un análisis de riesgos y gestionar las vulnerabilidades conocidas sin especificar un número concreto de días. SOC 2 se basa en criterios, por lo que a tu auditor le importa si el proceso de aplicación de parches que has documentado es el que realmente sigues. Ninguno de ellos hace que un componente sin una vía de corrección sea fácil de defender.
El problema específico que plantean las bibliotecas de utilidades es el alcance. Un servidor de aplicaciones vulnerable se encuentra en un único lugar y genera un único hallazgo. Un servidor vulnerable commons-lang3 aparece una vez por cada artefacto que lo incluye, lo que convierte una única versión sin parches en un ejercicio de corrección en el que participan equipos que nunca han hablado entre sí. Los controles compensatorios pueden ganar tiempo y suelen ser la decisión acertada, pero determinar si son suficientes es algo que hay que discutir con tu evaluador, en lugar de ser simplemente una casilla que marcar.
Tus opciones tras el fin de vida útil de Apache Commons Lang
Actualizar a la versión actual
Para los equipos que puedan hacerlo, pasar a la versión actual es la solución adecuada a largo plazo. Apache mantiene una compatibilidad bastante estricta dentro de la serie 3.x, el espacio de nombres «lang3» se ha mantenido estable en toda la línea y el proyecto publica informes de compatibilidad binaria para sus versiones. Las versiones individuales siguen dejando de recomendar ciertas funciones y ajustando el comportamiento, por lo que conviene tratarlo como una actualización y no como un simple trámite.
El problema es que rara vez se trata de un cambio de una sola línea. commons-lang3 suele estar en tu árbol de proyectos porque algo lo ha colocado allí —una capa de persistencia, un marco de trabajo u otro componente de Apache Commons— y la versión con la que acabas es la que haya elegido la mediación de Maven. Una declaración directa con su propia versión en tu pom.xml gana ese conflicto. Si no se especifica la versión y se deja que la proporcione un POM padre o una BOM importada, será la versión gestionada la que decida. Una copia sombreada incluida en el artefacto de otra persona queda totalmente al margen de la mediación y no se verá afectada por ella en absoluto. Por eso mvn dependency:tree -Dverbose es el primer comando que se ejecuta, en lugar del último.
Sustituir por otra biblioteca de utilidades
Algunos equipos aprovechan el momento para replantearse por completo esa dependencia. Guava cubre gran parte de ese terreno; Spring incluye sus propias clases de utilidades; y las API básicas de Java 8 y versiones posteriores han incorporado una parte considerable de lo que Commons Lang ofrecía en un principio.
Es una decisión arquitectónica legítima, pero hay que ser sinceros sobre las ventajas e inconvenientes. Guava también es una dependencia de terceros con su propio historial de CVE, y adopta un enfoque más flexible en cuanto a la rotación de versiones que Apache Commons, ya que cualquier elemento marcado como @Beta puede cambiar o desaparecer en cualquier versión. Lo que se hace es sustituir una superficie de la cadena de suministro por otra, en lugar de eliminar una. La migración también implica auditar cada sitio de llamada, reescribirlos y validar su comportamiento con la sustitución. Eso es un proyecto de migración, no un sprint, lo que lo convierte en una mala solución para un plazo de corrección que vence el mes que viene.
Mantén tu versión y actualízala de todos modos
La tercera opción consiste en dejar la versión tal y como está y obtener las correcciones de seguridad de una fuente distinta a la del desarrollador original. Eso es lo que ofrece el servicio «Endless Lifecycle Support» de TuxCare, y es la única de las tres opciones que desvincula el estado de tus parches de tu calendario de actualizaciones.
Por qué precipitarse a actualizar el lenguaje de Commons puede resultar contraproducente
Cuando surge la presión —y suele surgir más como un hallazgo del escáner que como una decisión—, el instinto es aumentar la versión y lanzarla. Hay algunas cosas que suelen salir mal.
La mediación de versiones es la primera. Cuando varias dependencias declaran diferentes commons-lang3 versiones, Maven recurre a la declaración más cercana en el gráfico en lugar de a aquella con la que se probó el código, y el orden de las declaraciones sirve para desempatar en caso de que haya varias a la misma profundidad. La compilación puede seguir siendo correcta mientras que un NoSuchMethodError, un NoClassDefFoundError o que más adelante surja algún otro problema de compatibilidad, en una ruta de ejecución que se haya pasado por alto en las pruebas.
La reacción habitual puede empeorar las cosas. Los equipos recurren a <exclusions> en Maven o mediante restricciones de dependencias en Gradle para forzar la versión que desean, lo que elimina el error inmediato pero deja un grafo de dependencias que nadie querrá tocar en la próxima actualización. Si haces eso en varios servicios bajo presión de tiempo, habrás cambiado un problema de parche por uno de mantenimiento.
La deriva de comportamiento es el riesgo más silencioso. Las funciones de cadena, reflexión y ayuda numérica de Commons Lang se han ido perfeccionando a lo largo de numerosas versiones, y el código que se basa en un caso extremo, como el manejo de valores nulos en un concreto StringUtils Un método, por ejemplo, puede modificar el comportamiento sin cambiar la firma. No se produce ningún error en tiempo de compilación. Simplemente devuelve un valor ligeramente diferente en producción.
Nada de esto es inevitable. Es lo que ocurre cuando el trabajo se ve comprimido en un plazo determinado por un calendario de cumplimiento normativo, en lugar de por el gráfico de dependencias. Los equipos que superan estas transiciones sin problemas hacen siempre las mismas tres cosas: revisan el árbol de forma adecuada, comprueban el comportamiento del que realmente depende su código y mantienen una postura de seguridad sólida mientras se llevan a cabo ambas tareas.
Qué te ofrece ELS para Apache Commons Lang
TuxCare lleva quince años desarrollando parches para software de código abierto y ha publicado más de 420 000 parches en toda su cartera. El servicio de Commons Lang señala las versiones en las que los usuarios siguen atascados. La documentación incluye actualmente Commons Lang 2.4 y 2.6 en el espacio de nombres antiguo, además de commons-lang3 3.4, 3.8.1, 3.10, 3.11, 3.12.0, 3.14.0, 3.15.0 y 3.17.0.
Desde el punto de vista técnico, no tiene nada de especial, y eso es precisamente lo que se busca. Tus credenciales se introducen en el de Maven settings.xml, el repositorio de TuxCare se instala en tu pom.xml, o sus equivalentes en Gradle, y se indica que la dependencia apunta a la versión actualizada, de modo que la 2.6 pasa a ser 2.6-tuxcare.1. Tus sitios de llamada no cambian, tus herramientas de compilación no cambian y la integración continua (CI) sigue resolviendo los artefactos como siempre lo ha hecho. Si prefieres que tus compilaciones no se conecten directamente con un proveedor, puedes canalizar todo el proceso a través de tu propio gestor de repositorios.
En cuanto a los plazos, TuxCare establece un objetivo de 14 días desde la divulgación pública para las vulnerabilidades altas y críticas con una puntuación CVSS 7.0 o superior, 60 días para las medias y 90 días para las bajas. Estos plazos comienzan a contar a partir de la divulgación. La norma PCI DSS comienza a contar a partir del lanzamiento del parche, por lo que el objetivo de 14 días está pensado para dejarte margen dentro del plazo de un mes. El requisito 6.3.3 se aplica a las vulnerabilidades críticas.
Una nota sobre la cobertura de dependencias, ya que es fácil exagerar su importancia. commons-lang3 Por su propio diseño, no tiene ninguna dependencia de tiempo de ejecución, por lo que no hay ningún árbol oculto detrás. Funciona al revés. commons-lang3 suele ser la dependencia transitiva que se encuentra en el árbol de otra persona, y precisamente por eso pasa desapercibida. ELS for Libraries cubre las dependencias directas y transitivas de los componentes compatibles sin coste adicional, y eso es de gran importancia para algo como Struts o Tomcat. En el caso concreto de Commons Lang, la ventaja es que la biblioteca de la que dependen todos los demás componentes cuenta por fin con una versión actualizada y mantenida.
El resto es la infraestructura que cualquiera desearía. Los paquetes incluyen firmas OpenPGP independientes y proceden de un registro gestionado por TuxCare, por lo que la autenticidad y la integridad son verificables, en lugar de suponerse. Existe un feed VEX de CycloneDX para las bibliotecas de Java, incluida Commons Lang, que indica a tus escáneres y auditores qué CVE se aplican realmente a una compilación concreta, en lugar de cuáles simplemente mencionan el paquete. Las SBOM se distribuyen en formatos SPDX y CycloneDX, y el feed de Java se publica en Nexus junto con los paquetes. El servicio de asistencia está disponible las 24 horas del día, los 7 días de la semana y los 365 días del año a través del portal de asistencia de TuxCare para la clasificación de incidencias, las solicitudes de parches y los ocasionales problemas con el sistema de compilación.
Para consultar la lista actualizada de versiones compatibles de Apache Commons Lang, consulta la documentación de TuxCare. Para comprobar qué CVE de Apache Commons Lang ya se han solucionado, echa un vistazo al rastreador de CVE en tiempo real.
No dejes que el fin de la vida útil de Commons Lang ponga en riesgo tus aplicaciones
Dejar de recibir el mantenimiento del proyecto original no provoca ningún fallo por sí solo. Ese es precisamente el problema, y la razón por la que no se incluye en la hoja de ruta hasta que un escáner o un auditor lo añade. Tus aplicaciones siguen funcionando, tus pruebas siguen superándose, y lo único que ha cambiado es que han dejado de llegar las correcciones del proyecto original para tu versión.
Actualizar a la versión actual sigue siendo el objetivo adecuado. Para lograrlo correctamente, hay que definir el alcance de la auditoría de dependencias, probar el comportamiento del que realmente depende tu código y encajar el trabajo en un calendario de lanzamientos en el que también tienen sus propias prioridades otras personas. Eso es un plan, y los planes requieren tiempo del que no dispones cuando el plazo lo marca otra persona.
El soporte ampliado es lo que te da ese margen de tiempo. No sustituye a la actualización, y nadie debería pretender lo contrario. Mantiene actualizadas las versiones de Commons Lang que admite, te proporciona un argumento sólido que presentar ante un evaluador y permite a tus ingenieros dedicar el trimestre a la hoja de ruta en lugar de a una migración de bibliotecas de emergencia.
Si el fin de la vida útil (EOL) de Apache Commons Lang te preocupa en estos momentos, echa un vistazo al servicio ELS de TuxCare para Apache Commons Lang, que ofrece soporte ampliado para determinadas versiones de Commons Lang y commons-lang3 que ya no cuentan con soporte.
