dependencias
9 artículos con esta etiqueta
Vulnerabilidad de Brotli CVE-2026-111497 (Node2Shell): cómo comprobar Node.js, Python y .NET, y qué actualizar
El 21 de octubre de 2026 (hora de EE. UU.), Google publicó Brotli 1.2.1, 1.1.1 y 1.0.10 para corregir CVE-2026-111497, una escritura fuera de límites en la biblioteca oficial de Brotli. Están afectadas Brotli 1.0.3–1.0.9, 1.1.0 y 1.2.0. Descomprimir datos Brotli manipulados puede corromper la memoria y provocar caídas, revelación de memoria o, potencialmente, ejecución de código arbitrario. Google le asigna 9,2 según CVSS v4.0. Node.js publicó 22.23.4, 24.22.1 y 26.12.1 el mismo día, y el 22 de octubre se corrigieron los paquetes de PyPI en brotli 1.2.1 y brotlicffi 1.2.1.0. Microsoft publicó correcciones para .NET 8, 9 y 10 (8.0.33, 9.0.22, 10.0.14) el 25 de octubre (hora de EE. UU.), y Bun (1.4.4) y Envoy también publicaron correcciones. JPCERT/CC, el equipo de respuesta a emergencias informáticas de Japón, emitió el 26 de octubre una alerta que menciona los apodos Node2Shell y HTTP2Shell. Muchos programas llevan su propia copia de Brotli, por lo que actualizar la biblioteca del sistema operativo no corrige las copias incluidas en las compilaciones oficiales de Node.js, los wheels de Python de PyPI, las imágenes de contenedor ni los ejecutables de un solo archivo. El 27 de octubre (hora de EE. UU.), CISA la añadió a su catálogo de vulnerabilidades explotadas conocidas (KEV), citando pruebas de explotación activa, y dio a las agencias federales de EE. UU. hasta el 10 de noviembre para corregirla. CISA no publicó detalles. Una empresa de inteligencia de amenazas informó de haber observado tráfico de explotación contra Node.js 24.22.0, aunque ese tráfico falló en la prueba de la propia empresa, y Microsoft sigue marcando el fallo como no explotado. Medios de comunicación informan de que se ha publicado código de prueba de concepto. La conclusión de este sitio: si un servicio con Node.js, Bun, Python o .NET descomprime datos recibidos del exterior, actualícelo hoy sin esperar a una ventana de mantenimiento y después reconstruya contenedores y ejecutables. Sitios WordPress y PHP: empresas de seguridad explican el 2 de noviembre que no es un fallo del núcleo de WordPress, de los plugins ni de los temas, así que actualizar WordPress no lo corrige. WordPress no incluye Brotli y usa la biblioteca del sistema operativo, así que actualice el paquete libbrotli del SO, reconstruya los contenedores y reinicie después PHP-FPM o Apache (el reinicio es una adición nuestra). Una empresa reprodujo en laboratorio la ejecución de código mediante pingbacks de XML-RPC, y dice que a 2 de noviembre no encontró ningún informe público de un sitio WordPress realmente comprometido.
Claves de CA intermedias de eMudhra (emSign) comprometidas: qué deben hacer los usuarios de Python con pip, certifi y uv
El 17 de octubre de 2026, un informe mostró que las claves privadas de ocho certificados intermedios de la autoridad de certificación india eMudhra (seis para TLS) se habían generado tan mal que cualquiera podía recuperarlas. eMudhra revocó los ocho el 18 de octubre, y Chrome y Firefox los bloquearon el 17 de octubre mediante sus mecanismos de envío. El 20 de octubre Mozilla decidió una retirada de confianza de emergencia de la raíz superior, emSign ECC Root CA - G3, y Chrome la eliminará el 27 de octubre (hora del Pacífico). Los navegadores están protegidos, pero los clientes TLS fuera del navegador pueden confiar en certificados falsificados hasta que actualicen su propia copia de la lista de CA. En Python, pip siempre carga su certifi incluido, por lo que un pip antiguo sigue expuesto aunque el almacén del sistema operativo se corrija. Los proyectos de Python publicaron un aviso el 20 de octubre (actualizado hasta el 22 de octubre) pidiendo actualizar a certifi 2026.10.19 como mínimo, pip 26.2.2, uv 0.13.4, sigstore 4.5.1, conda 26.9.4 y pixi 0.82.1, y reconstruir las imágenes de contenedor sin la caché de capas. El 21 de octubre publicaron Python 3.15.1, 3.14.9 y 3.13.17 con pip 26.2.2 incluido. No habrá una versión 3.11 ni 3.12 con un pip más nuevo. No se trata de un fallo de ejecución de código en CPython: un atacante en la ruta de red podría redirigir las conexiones a PyPI, python.org y otros sitios a un servidor falso. No se había anunciado ninguna explotación al 24 de octubre. El 22 de octubre eMudhra anunció que abandonará el negocio global de certificados SSL/TLS. La opinión de este sitio: actualice pip a 26.2.2 o posterior y certifi a 2026.10.19 o posterior en todos los entornos, reconstruya las imágenes de Docker sin caché y eleve cualquier fijación de certifi en los lockfiles.
Contaminación de prototipos en Node.js: lo que el runtime no cubre y cómo defenderte en tu propio código
La contaminación de prototipos (prototype pollution) ocurre cuando una clave especial de una entrada externa llega a los prototipos integrados de JavaScript, normalmente a través de un merge recursivo. Dos consecuencias: aparecen por todas partes propiedades que nunca fijaste (rompiendo comprobaciones de autorización y de opciones), o desaparecen métodos integrados y la aplicación se cae en un punto sin relación. Lo que más importa es de quién es la responsabilidad: Node.js declara que no es una vulnerabilidad del núcleo de Node.js y que las defensas corresponden a la aplicación y a las dependencias. Esperar una actualización no lo arreglará.
¿Qué es OpenSSL? La biblioteca que se encarga del cifrado HTTPS y cómo mantenerla segura
OpenSSL = la biblioteca de código abierto que sustenta HTTPS (TLS/SSL) y el cifrado. Casi nadie la escribe directamente: la hereda vía el servidor web, el sistema operativo o el entorno de ejecución del lenguaje. Por eso un solo fallo tiene un impacto enorme (Heartbleed es el caso clásico). Defensa: conoce qué OpenSSL usa tu pila, no ejecutes versiones en fin de soporte (EOL), incluye las bibliotecas fundamentales en la monitorización de CVE y parchea con rapidez. Incluso los certificados que sirve este sitio ejecutan su cifrado por debajo a través de una implementación de la familia OpenSSL.
Corregir CVE de dependencias de verdad: escanear, corregir, aislar y seguir vigilando
El trabajo de vulnerabilidades no termina cuando «lo corriges». Hecho = 1) escanear, 2) corregir, 3) aislar/delegar, 4) monitorear. Hasta que el monitoreo (detección diaria de cambios) esté en marcha, está incompleto — las dependencias vuelven a ser vulnerables mañana. Una corrección perfecta que el siguiente despliegue sobrescribe vale cero. Los equipos pequeños se mantienen seguros con dos disciplinas: detección automatizada de cambios y «local→push→deploy».
Instalar y usar osv-scanner: encuentra automáticamente CVE en tus dependencias
osv-scanner escanea lockfiles y contenedores para sacar a la luz CVE en tus dependencias, gratis. Esto recorre la instalación, la ejecución y la integración en CI, además de cuándo usarlo frente a npm/pnpm audit y Dependabot. La visión de este sitio: qué herramienta encaja depende de tu configuración. Usa osv-scanner en proyectos multiecosistema o sin GitHub, y al pnpm audit incluido para un único árbol npm.
Log4Shell (CVE-2021-44228) — un fallo en una librería de logging, y por qué los equipos no podían saber rápido si la usaban
El fallo de CVSS 10.0 de Log4j. El problema de fondo era la dependencia transitiva: estar afectado a través de una librería que no sabías que usabas. Un camino pasivo de registro de logs se convirtió en vector de ataque. SBOM, monitorización automática, parcheo rápido y seguir los CVE de seguimiento son las lecciones.
La puerta trasera de XZ Utils (CVE-2024-3094) — un ataque a la cadena de suministro de un comantenedor de confianza
Un mantenedor de confianza plantó una puerta trasera en xz: un ataque a la cadena de suministro. Un ingeniero notó que los inicios de sesión iban lentos y lo encontró justo antes de las versiones estables. El objetivo no era el código, sino las personas y la confianza. Minimiza dependencias, fija versiones, compila de forma reproducible, persigue anomalías y apoya a los mantenedores.
Ejecutar Next.js de forma segura: no quedarse atrás con los CVE publicados
El mayor riesgo del framework son los CVE publicados descuidados. Defiende con cuatro prácticas: juzgar por la versión en ejecución, monitorear con Dependabot/osv-scanner, actualizar rápido, y operar con mínimo privilegio. La visión de este sitio: lo que suele faltar a los desarrolladores indie no es conocimiento sino una forma de mantener la operación; un sistema que no pase por alto los CVE importa más que la velocidad.