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 herramientas de compilación suponen un riesgo para la producción, incluso aunque nunca se distribuyan como código de ejecución de la aplicación.
- Webpack no publica ramas LTS, y las correcciones se incorporan a la línea 5.x activa, en lugar de a versiones menores anteriores.
- El código de compilación se ejecuta con cualquier código fuente, credenciales y tokens a los que pueda acceder el proceso de compilación.
- Volver a compilar con el mismo Webpack vulnerable no cambia nada, ya que el fallo se vuelve a generar cada vez.
La mayoría de los programas de detección de vulnerabilidades excluyen silenciosamente la cadena de compilación. Se encuentra en «devDependencies», nunca se ejecuta en un servidor de producción y, cuando aparece en un informe de análisis, solo provoca un encogimiento de hombros y queda relegada al final de la cola. Esa lógica parece razonable cuando una dependencia nunca llega a producción. Sin embargo, en el caso de webpack, esta lógica se desmorona de dos formas concretas.
En esta entrada se explica en qué consiste realmente el modelo de soporte de Webpack, por qué una versión menor 5.x «fijada» es, en la práctica, código sin soporte, y cómo tratar la cadena de compilación como una superficie de ataque sin retrasar cada lanzamiento.
La compilación sigue funcionando, así que nadie la toca
La configuración de Webpack en un repositorio heredado se considera intocable porque sigue funcionando, y nadie quiere ser el responsable de que deje de hacerlo. Los sistemas de compilación estables tienden a convertirse en el software más antiguo de la empresa: nunca hay nada que obligue a nadie a volver sobre ellos y revisarlos.
Entonces se celebra una reunión de triaje. Un escáner detecta un CVE de Webpack, alguien le echa un vistazo, dice «eso solo afecta al tiempo de compilación» y el ticket va bajando en la cola, quedando por detrás de todo lo que parece suponer un riesgo real para la producción. El razonamiento parece lógico. Pero es erróneo por partida doble.
El primer error es considerar el resultado de Webpack como algo independiente del propio empaquetador. Webpack inyecta su propio código de ejecución en el paquete, por lo que cualquier fallo en ese código de ejecución se convierte en un fallo en la aplicación que distribuyes.
La segunda es dar por sentado que solo se puede acceder a una herramienta de compilación en el momento de la compilación. El servidor de desarrollo tiene su propio tipo de vulnerabilidades dirigidas directamente a los ingenieros que lo gestionan. Y el problema más profundo es considerar las «devDependencies» como una clasificación de riesgo en sí mismas. Se trata de una etiqueta de empaquetado, no de un límite de seguridad. Un empaquetador simplemente lo hace más evidente de lo habitual, porque parte de lo que genera acaba en producción.
Webpack 4 ya está listo y Webpack 5 no tiene versión LTS
Webpack no publica un calendario de LTS, una matriz de compatibilidad ni un calendario de fin de soporte. Las correcciones se incorporan a la línea 5.x, que se encuentra en desarrollo activo, en lugar de a las ramas más antiguas que se mantienen, por lo que una versión menor a la que te mantengas anclado puede quedar obsoleta en el momento en que se corrija algo en el código fuente.
Webpack 4 se lanzó en febrero de 2018, Webpack 5 llegó en octubre de 2020 y la línea 4.x concluyó con la versión 4.47.0 en septiembre de 2023. La migración de la versión 4 a la 5 llevó años al ecosistema, y muchos equipos nunca la completaron. Si todavía utilizas la versión 4, estás ejecutando código que no recibe ninguna corrección del desarrollador original.
Webpack 5 funciona mejor, pero solo en la punta. La versión actual es la 5.110.3, publicada en septiembre de 2026, y las dos correcciones que se indican a continuación ponen de manifiesto el problema práctico, ya que cada una de ellas se incluyó en una versión más reciente de la serie 5.x, en lugar de como una adaptación hacia atrás para las versiones menores anteriores afectadas. El proyecto Hoja de ruta para 2026 se sentaron las bases para la gestión nativa de CSS, un destino de compilación universal, TypeScript sin cargadores y los cimientos para Webpack 6, y el ciclo de lanzamientos ha avanzado rápidamente en todos estos aspectos. La compatibilidad experimental con TypeScript llegó en la versión 5.107, y en la versión 5.110 se marcaron como obsoletas css-loader, style-loader, y mini-css-extract-plugin a favor de la compatibilidad con CSS integrada en webpack. En otras palabras, la versión parcheada del proyecto original es también la que va cambiando sin que te des cuenta.
¿Sabías que...? El hecho de estar «en Webpack 5» no dice prácticamente nada sobre el estado de las actualizaciones de seguridad. Un repositorio bloqueado en la versión 5.76.1 va más de treinta versiones menores por detrás de la línea actual con parches, aunque Webpack 5 siga siendo la versión principal actual del proyecto.
Esa brecha entre la «versión principal compatible» y la «versión parcheada» es donde las auditorías se complican. Imagina una interfaz de usuario de un banco fijada a una versión menor de la 5.x porque el proceso de desarrollo está certificado y cualquier cambio en la cadena de herramientas obliga a volver a pasar por todo el proceso de recertificación. Cambiar el empaquetador implica volver a ejecutar ese proceso, por lo que la fijación se mantiene, y con ella el código sin soporte. Esta es precisamente la situación para la que se ha diseñado el soporte ampliado, que permite a un equipo seguir recibiendo parches en una rama de la que no puede salirse fácilmente.
Algunos errores del empaquetador acaban en el navegador
Algunas vulnerabilidades de Webpack no se encuentran en absoluto en la fase de compilación. Se encuentran en el código que Webpack escribe en tu paquete, por lo que este empaquetador debe incluirse en tu superficie de ataque de producción y no solo en tu lista de comprobación de la fase de compilación.
43788 Es el ejemplo más sencillo. Se trata de un gadget que altera el DOM en webpack’s AutoPublicPathRuntimeModule, y se aplica cuando output.publicPath no está definido o está establecido en auto. El aviso del desarrollador indica que las versiones anteriores a la 5.93.0 se ven afectadas y que la 5.94.0 y posteriores están corregidas; además, el NVD le asigna un nivel de riesgo «medio» con una puntuación de 6,4. Conviene saber que auto es el valor predeterminado efectivo para los destinos «web» y «web-worker» cuando nadie lo establece publicPath, así que no se trata de una configuración poco habitual.
La etiqueta «Medium» subestima la gravedad de la situación. El informe de seguridad señala que se han producido casos reales de explotación en el sistema de gestión del aprendizaje (LMS) Canvas, y que el código vulnerable se genera en el paquete, en lugar de limitarse a un ejecutor de CI. Sin embargo, la explotación no es automática. Requiere una página que incluya archivos generados por Webpack y que permita a un atacante inyectar HTML sin scripts con datos insuficientemente depurados name o id atributos. Cuando se dan esas condiciones, el gadget puede influir en el origen desde el que se cargan tus scripts, lo que supone una vía de «cross-site scripting» que se ejecuta en los navegadores de tus usuarios, iniciada por tu herramienta de compilación.
28154 Es un contraste interesante, porque nunca sale de la compilación. Se trata de un problema de acceso a objetos entre reinos en ImportParserPlugin Gestión incorrecta de comentarios, que afecta a las versiones de Webpack 5 anteriores a la 5.76.0. Durante la compilación, un atacante capaz de manipular el objeto no fiable en cuestión podría hacer que Webpack accediera al objeto global del ámbito del host. El NVD le otorga una calificación de «Crítica» con una puntuación de 9,8, mientras que Red Hat le asigna a esta misma vulnerabilidad una puntuación de 9,1.
Recompilar con el mismo Webpack vulnerable no sirve de nada en ninguno de los dos casos, por diferentes motivos. El código de tiempo de ejecución que hay detrás de CVE-2024-43788 se vuelve a incluir en todos los paquetes hasta que se aplique el parche al propio Webpack, y CVE-2023-28154 se encuentra en el propio análisis de comentarios de Webpack, por lo que persiste mientras esa versión se encargue de la compilación. Ambas correcciones llevan años disponibles en el código fuente original.
Cuidado: Antes de que alguien discuta sobre las puntuaciones de gravedad, comprueba la versión y la configuración. El aviso indica que las versiones de Webpack anteriores a la 5.93.0 se ven afectadas, mientras que la 5.94.0 y posteriores están parcheadas, por lo que hay que revisar cualquier versión anterior a la 5.94.0, y output.publicPath sin configurar o activado auto es lo que incluye el entorno de ejecución afectado en tu paquete. A continuación, comprueba si tu aplicación permite a los usuarios insertar código HTML sin depurar name o id atributos, ya que esas condiciones son fundamentales para la explotabilidad.
La dependencia del desarrollo no implica un riesgo bajo
Ni siquiera las vulnerabilidades que se producen durante la compilación son de bajo riesgo, debido a todo aquello a lo que puede acceder el código en ese momento. Un empaquetador se ejecuta con todo lo que el proceso de compilación tiene a su disposición, lo que suele incluir el código fuente, las variables de entorno, las credenciales y, en muchos procesos de compilación, los tokens de publicación. Se trata de un objetivo muy atractivo.
30359 y los relacionados con ello 30360 Ambos casos se traducen en el robo de código fuente de webpack-dev-server, y ambos se solucionaron en la versión 5.2.1, aunque de forma diferente. El primero se aprovecha del hecho de que una solicitud de script clásica procedente de un <script> La etiqueta no está sujeta a la política de mismo origen, por lo que una página maliciosa puede extraer un paquete de un servidor de desarrollo en ejecución y, con un poco de «contaminación de prototipos», volver a leer el código fuente de __webpack_modules__ utilizando Function::toString. La segunda es el secuestro de WebSocket entre sitios, en el que la comprobación de origen permitía el paso de orígenes con direcciones IP, lo que ponía en riesgo a los desarrolladores que utilizan navegadores que no se basan en Chromium; este problema afecta a las versiones hasta la 5.2.0.
Lo más importante ahora es que la versión 5.2.1 no fue el final de la historia. Esa corrección se basó en el Sec-Fetch-Mode y Sec-Fetch-Site encabezados, que los navegadores solo envían para orígenes potencialmente fiables, por lo que, a través de HTTP sin cifrar, los encabezados no están presentes y la comprobación se omite por completo. Esta vulnerabilidad, CVE-2026-6402, afecta a webpack-dev-server hasta la versión 5.2.3, y la versión 5.2.4 la corrige estableciendo Cross-Origin-Resource-Policy: same-origin. Servir el servidor de desarrollo a través de HTTPS es una solución alternativa documentada, más que un sustituto de la actualización. Posteriormente, la versión 5.2.5 corrigió el CVE-2026-9595, en el que un proxy de usuario de amplio alcance con ws: true capturaría el propio WebSocket HMR del servidor de desarrollo y lo reenviaría al proxy de destino, incluyendo las cookies y el encabezado «Origin». Posteriormente, la versión 5.2.6 corrigió una vulnerabilidad de falsificación de solicitudes entre sitios (CSRF) a través del editor abierto interno y los puntos finales de invalidación, junto con un ataque de denegación de servicio provocado por un encabezado «Host» u «Origin» malformado, y el propio paquete ha pasado desde entonces a la versión 6.0.0. Esa serie de correcciones es un argumento de peso para no considerar los hallazgos del servidor de desarrollo como meros ruidos de fondo.
Piensa en a quién afecta esto. El ataque publicado para CVE-2025-30359 incluye una página maliciosa que solicita un paquete desde un servidor de desarrollo en localhost, por lo que basta con que un desarrollador navegue por la web con un servidor de desarrollo en funcionamiento. El atacante necesita el puerto y la ruta del punto de entrada de salida, y ambos suelen estar configurados por defecto. Esto afecta a los contratistas que utilizan equipos que no controlas y a cualquiera que deje un servidor de desarrollo en marcha todo el día mientras navega, y nada de esto aparece en un análisis centrado en el entorno de producción.
Desde las trincheras: Alguien establece host a 0.0.0.0 para probarlo en un móvil y luego se olvida de volver a cambiarlo. Esa única modificación convierte una herramienta que solo funciona en localhost en una que escucha en la red, lo cual es importante para los errores que requieren acceso a la red, como la denegación de servicio por encabezado mal formado. Sin embargo, eso no es lo que provoca el robo de código de origen cruzado. Eso funciona bien contra localhost.
Así pues, la cuestión del triaje nunca se redujo a «localhost frente a todo lo demás». Se trata de la versión exacta que estés utilizando, de si los desarrolladores mantienen un servidor de desarrollo en funcionamiento mientras navegan, de si este sirve contenido a través de HTTP sin cifrar y de lo fáciles que sean de adivinar el puerto y la ruta de salida.
Un equipo que utilice la versión 5.2.3 con la configuración predeterminada presenta una vulnerabilidad real, independientemente de lo que indique la dirección de enlace. El protocolo HTTPS mitiga la ruta de exposición del origen en CVE-2026-6402, pero no retira los avisos de seguridad posteriores a este, por lo que la versión 5.2.4 no constituye una línea de seguridad general. Las correcciones de la serie 5.x se extienden hasta la versión 5.2.6, y cada aviso aplicable debe analizarse por separado, en lugar de aplicarse una norma general.
La migración oculta es mayor que la de Webpack
La razón por la que estos pines persisten no es la pereza. Migrar una configuración madura de Webpack es un proyecto en toda regla, y los equipos se quedan donde están por motivos de peso, empezando por los cargadores y complementos personalizados, los sistemas de compilación específicos de cada marco de trabajo superpuestos, la configuración acumulada a lo largo de años de parches, el almacenamiento en caché sensible a los resultados, las versiones de Node sin soporte que aún persisten en la integración continua (CI) y el simple miedo a cambiar un proceso que nadie entiende del todo.
Una modificación importante tampoco deja las cosas como están. Puede alterar la agrupación en bloques, la resolución de módulos, el comportamiento de los polyfills, la gestión de recursos y el formato del resultado. Eso implica tener dos planes de pruebas en lugar de uno, ya que es necesario validar tanto el proceso de compilación como la aplicación resultante.
Lo más útil es dejar de tratar «webpack» como un único elemento y dividirlo según el lugar en el que se ejecute realmente cada parte. Ese es el tipo de contexto de explotabilidad que debe reflejar un documento del Vulnerability Exploitability eXchange (VEX), en el que se indique que un cargador en un ejecutor de integración continua (CI) y el código en tiempo de ejecución dentro de un paquete distribuido no suponen el mismo riesgo.
| Componente | Dónde se ejecuta | Alcanza el volumen de producción | Prioridad de triaje |
|---|---|---|---|
| código de ejecución generado por Webpack | Tiempo de compilación y, a continuación, en el navegador | Sí, cuando el módulo de tiempo de ejecución afectado se encuentra en el paquete | Alta |
| webpack-dev-server | Los equipos de los desarrolladores, además de la red local cuando está expuesta | No | Depende de la versión y la configuración; el nivel más alto se da en las versiones para las que existen avisos pertinentes. |
| Cargadores y complementos | Tiempo de compilación, en CI o en desarrollo | A veces, depende del cargador | Caso por caso |
| Utilidades de compilación transitivas | Tiempo de compilación | Rara vez | Bajo, salvo que sea accesible |
Un marco de toma de decisiones para una compilación heredada
Avanzar en la versión 5.x
Si la configuración está documentada y se mantienen las dependencias relacionadas, pasa a la versión 5.x actual. Es la opción más económica y te permite recuperar el suministro de parches. Hazlo en este sprint en lugar de dejarlo para el próximo trimestre.
Reconstruir el gasoducto
Si la complejidad histórica ha superado su valor, merece la pena considerar seriamente Rspack, Vite y esbuild. Sin embargo, hay que ser sinceros en cuanto al coste. Son más rápidos, pero reescribir una configuración consolidada con cargadores personalizados, Module Federation o una división cuidadosa del código es un proyecto en toda regla que, al final, no aporta ningún resultado visible para el usuario.
Aplica el parche a la versión fijada y procura que la migración sea mínima
Si el proceso está certificado, este año no se va a eliminar el empaquetador. Aquí es donde el soporte ampliado demuestra su utilidad, manteniendo la rama fijada actualizada con los parches mientras planificas el cambio más amplio según tu propio calendario, en lugar de hacerlo de forma urgente. El soporte de ciclo de vida ilimitado de TuxCare cubre las versiones 5.50.0, 5.55.0, 5.76.1, 5.88.2 y 5.94.0 de webpack, además de las versiones de webpack-dev-server desde la 2.7.1 hasta la 5.2.2, distribuidas a través de npm.
Sin embargo, hay que tener claro qué es lo que conserva un «backport». Mantiene intactas la versión de Webpack, la configuración y la superficie de la API, lo que puede reducir considerablemente el alcance de la recertificación en comparación con una migración completa de la cadena de herramientas. Lo que no puede hacer es dejar el paquete generado byte a byte idéntico, ya que corregir el código de ejecución generado implica modificarlo.
Cómo aborda TuxCare la compatibilidad ampliada con Webpack
El soporte ampliado para una herramienta de compilación implica mucho más que mantener viva una versión antigua. El verdadero trabajo está en los detalles, y la mayor parte de él es de tal naturaleza que un equipo interno no puede repetirlo mes tras mes.
El proceso comienza con la supervisión de Webpack y sus dependencias transitivas cubiertas, para luego evaluar si un problema detectado afecta realmente a la rama heredada, en lugar de basarse únicamente en un rango de versiones publicado. Esa visión contextual, que tiene en cuenta el estado de fin de vida útil (EOL) y el riesgo de las dependencias transitivas, es lo que permite a un equipo dar prioridad a los riesgos reales en lugar de dedicarse a revisar cada línea de un informe de análisis.
A partir de ahí, las correcciones se retroportan sin incorporar los cambios arquitectónicos que traen consigo las versiones posteriores. Cada versión parcheada se valida en cuanto a compatibilidad y regresiones para que los procesos de compilación establecidos sigan funcionando, lo que suele ser el verdadero motivo de objeción a la hora de aplicar parches en una pila certificada. TuxCare no pretende sustituir al webpack original. Su labor consiste en la gestión a largo plazo de las versiones que el proyecto ya ha dejado atrás, con las pruebas de regresión y el trabajo de compatibilidad que los sistemas de producción realmente necesitan. Cada versión parcheada se distribuye con una lista de materiales de software (SBOM) y un documento VEX, y los artefactos incluyen firmas GPG independientes procedentes del propio registro de TuxCare.
OpenJS y la larga vida útil de las herramientas esenciales
Webpack es un proyecto de OpenJS Impact, y el Programa de Sostenibilidad del Ecosistema de OpenJS ( ESP) permite que las versiones archivadas, en fin de vida útil (EOL) y antiguas puedan contar con cobertura de seguridad comercial, con una parte de los ingresos que se destina a los proyectos y a la Fundación. TuxCare es miembro Gold y socio del ESP, y dado que el programa no es exclusivo, los mantenedores tienen total libertad para ofrecer soporte a cualquier versión que deseen.
Tu proceso de compilación forma parte del producto, aunque los clientes nunca lo vean. Un proceso de compilación heredado merece el mismo plan de ciclo de vida que la aplicación que genera, y no una exención permanente del que ya aplicas en el resto de casos.
