El ataque a jscrambler prueba que el blindaje de npm 12 tiene un hueco Desarrollo 2026-07-12 https://elpisuika.com/dev/2026-07-12.og.png Desarrollo 2026-07
2026-07-12 · DESARROLLO · Edición del 12 de julio de 2026
Desarrollo

El ataque a jscrambler prueba que el blindaje de npm 12 tiene un hueco

Un paquete de npm usado por miles de equipos para ofuscar código instaló un infostealer en Rust apenas tres días después de que npm bloqueara por defecto los scripts de instalación, Parse Server cerró su cuarta falla de subida de archivos peligrosos en un mes, GitLab parchó ocho vulnerabilidades, GitHub amplió CodeQL a Kotlin 2.4 y Bun sumó procesamiento de imágenes nativo y soporte experimental para HTTP/3.

01
5
Versiones maliciosas de jscrambler publicadas en npm en tres horas el 11 de julio
02
6 minutos
Tiempo que tardó Socket en marcar como sospechosa la primera versión comprometida
03
8
Vulnerabilidades que GitLab corrigió el 8 de julio en sus ediciones Community y Enterprise
6 historias · 12 de julio de 2026 ← volver a portada
01
N.º 01 Cadena de Suministro · npm

El paquete jscrambler de npm instala un infostealer en Rust pese a npm 12

Cinco versiones maliciosas circularon en npm durante tres horas el 11 de julio; las últimas dos evadieron el bloqueo de scripts de instalación que npm 12 había activado apenas tres días antes.

El paquete jscrambler, usado para ofuscar código JavaScript de producción en canalizaciones de integración continua, apareció comprometido en npm el 11 de julio de 2026: un atacante publicó cinco versiones maliciosas —8.14.0, 8.16.0, 8.17.0, 8.18.0 y 8.20.0— en un lapso de tres horas, según documentó la firma de seguridad Socket. Las tres primeras versiones ejecutaban un gancho de instalación previa (preinstall) que descargaba y lanzaba, según el sistema operativo detectado, uno de tres binarios compilados en Rust diseñados para robar credenciales guardadas en los navegadores Chrome, Brave, Edge y Chromium, además de la extensión de Bitwarden y las sesiones activas de Steam, de acuerdo con el análisis técnico de Socket. La firma marcó la primera versión maliciosa como sospechosa seis minutos después de su publicación. El ataque llegó apenas tres días después de que npm 12.0.0 desactivara por defecto los scripts de instalación de las dependencias, el cambio de seguridad más profundo del gestor en 16 años. Pero las versiones 8.18.0 y 8.20.0 de jscrambler abandonaron el gancho de instalación y movieron la misma carga maliciosa a una función que se ejecuta apenas alguien importa (require) el paquete o corre su interfaz de línea de comandos, según documentó la firma StepSecurity —una vía que ni el bloqueo de scripts de npm 12 ni la bandera --ignore-scripts detienen. «Las correcciones que llegan en la v12 no tocan el robo de cuentas, las compilaciones nativas ni la detección de intención maliciosa en el momento de publicar», había advertido a Cybernews un analista de seguridad de cadena de suministro antes del lanzamiento de la versión 12, una lectura que el propio ataque a jscrambler confirma en la práctica. La versión 8.14.0 seguía disponible en el registro de npm al cierre de esta edición —no fue retirada—, por lo que cualquier archivo de bloqueo de dependencias (lockfile) que la referencie directamente sigue instalando el infostealer. Los mantenedores de jscrambler publicaron las versiones limpias 8.15.0 y 8.22.0 para recuperar la etiqueta de «más reciente» del paquete, y recomiendan fijar la versión en 8.13.0 o en 8.22.0 o superior, revisar los cachés locales de npm y rotar cualquier credencial que haya iniciado sesión en un navegador de la máquina afectada. Ningún medio confirmó equipos costarricenses afectados al cierre de esta edición, pero jscrambler es una herramienta común en canalizaciones de integración continua de estudios de software y empresas de exportación de servicios digitales en el país, donde ofuscar el código de producción antes de publicarlo es una práctica extendida.

02
N.º 02 Seguridad · Frameworks

Parse Server cierra una vía de XSS almacenado por archivos mal etiquetados

El proyecto Parse Server, el backend de código abierto para aplicaciones móviles y web que corre sobre Node.js, publicó el 11 de julio de 2026 la corrección para CVE-2026-61448, una falla de subida de archivos con tipo peligroso que habilita un ataque de scripts cruzados (XSS) almacenado, según documentaron los rastreadores de vulnerabilidades OffSeq y ThreatInt sobre el aviso original del proyecto. La falla afecta a las versiones 9.0.0 a 9.10.0-alpha.2 y hasta la 8.6.83: cuando un archivo subido tiene una extensión que el paquete mime no reconoce, Parse Server conserva el encabezado Content-Type que envía el propio cliente en lugar de asignar uno seguro, lo que permite subir un archivo con una extensión no bloqueada mientras se fuerza un tipo MIME como text/html o image/svg+xml. Cuando ese archivo se sirve desde un adaptador de almacenamiento como Amazon S3 o Google Cloud Storage, el navegador de la víctima detecta el tipo por su contenido (MIME-sniffing) y ejecuta el script incrustado dentro del origen de la aplicación. La falla es la cuarta variante del mismo patrón —un archivo subido que el navegador termina ejecutando como código— que el proyecto corrige en poco más de un mes: Parse Server ya había cerrado vulnerabilidades similares por archivos SVG (CVE-2026-30948), por extensiones compuestas como malicious.svg.txt (CVE-2026-55778) y por tipos de contenido no bloqueados como XHTML (CVE-2026-31868). La repetición sugiere que el modelo de lista negra de extensiones y tipos de contenido que usa Parse Server, en lugar de una lista blanca explícita, sigue abriendo huecos nuevos cada vez que alguien encuentra una combinación de extensión y encabezado que el filtro anterior no contempló. Parse Server es una opción común entre equipos de desarrollo costarricenses que arman backends rápidos para aplicaciones móviles sin depender de un proveedor cerrado como Firebase; cualquier proyecto que permita a usuarios subir archivos y los sirva desde almacenamiento en la nube debería actualizar a 9.10.0-alpha.2 o 8.6.84 antes de exponer un formulario de carga de archivos a usuarios no confiables.

Hoja de datos
La falla, identificada como CVE-2026-61448 y corregida el 11 de julio, permitía subir archivos con encabezados Content-Type falsificados que el navegador interpretaba como código ejecutable.
  • Identificador de la falla corregida el 11 de julio de 2026CVE-2026-61448
  • Versiones de Parse Server que corrigen la vulnerabilidad9.10.0-alpha.2 / 8.6.84
03
N.º 03 Herramientas · Análisis de Código

cat /feed/herramientasanlisisdecdigo.md

CodeQL 2.26 suma soporte para Kotlin 2.4 y mejora consultas en Go y C#

La actualización, publicada el 10 de julio por GitHub, añade modelos para el paquete de registro log/slog de Go y detecta fuentes de flujo remoto en los manejadores de páginas Razor de C#.

> GitHub publicó el 10 de julio de 2026 la versión 2.26.0 de CodeQL, el motor de análisis estático que impulsa el escaneo de código de la plataforma, con soporte para Kotlin hasta la versión 2.4.0, según el changelog oficial del proyecto. La actualización agrega modelos de flujo de datos para el paquete log/slog de la biblioteca estándar de Go —introducido en la versión 1.21 del lenguaje—, de modo que las consultas go/log-injection y go/clear-text-logging ahora detectan fallas en código que usa las funciones y métodos de slog.Logger. En C#, la actualización suma los parámetros de los métodos manejadores de Razor Pages (OnGet, OnPost, OnPostAsync) como fuentes de flujo remoto, lo que permite a la consulta cs/sql-injection detectar vulnerabilidades en subclases de PageModel que antes quedaban fuera del análisis.

> CodeQL se despliega de forma automática a todos los usuarios de escaneo de código de GitHub.com apenas se publica cada versión, sin que los equipos deban actualizar nada manualmente, según la documentación del proyecto. El soporte para Kotlin 2.4.0 llega apenas semanas después de que JetBrains publicara esa versión del lenguaje con parámetros de contexto estables y campos de respaldo explícitos, una brecha de actualización más corta que la que CodeQL mantuvo con versiones anteriores de Kotlin. Para equipos que dependen del escaneo automático de GitHub como única capa de revisión de seguridad estática, la cobertura de un lenguaje o una biblioteca nueva no es un detalle menor: es la diferencia entre que una falla de inyección se detecte antes de fusionarse a producción o no se detecte del todo.

> GitHub Advanced Security, que incluye CodeQL, es una de las herramientas de análisis estático más usadas en equipos de desarrollo de bancos y centros de servicios compartidos con sede en Costa Rica que ya centralizan su código en GitHub; para esos equipos la actualización llega sin acción requerida, pero vale la pena revisar si sus proyectos en Kotlin, Go o C# ya quedan dentro del alcance de las consultas nuevas.

04
N.º 04 Seguridad · GitLab

GitLab corrige ocho fallas de seguridad en sus ediciones Community y Enterprise

La más grave, con puntaje CVSS de 8.7, permite a un usuario autenticado con rol de desarrollador ejecutar scripts en la sesión de otro usuario a través de la tabla de evidencia de vulnerabilidades.

GitLab publicó el 8 de julio de 2026 las versiones 19.1.2, 19.0.4 y 18.11.7 para sus ediciones Community (CE) y Enterprise (EE), con parches para ocho vulnerabilidades de severidad alta a baja, según el aviso oficial de la compañía. La falla más grave, identificada como CVE-2026-6896 y con puntaje CVSS de 8.7, es una vulnerabilidad de scripts cruzados (XSS) en el renderizador de la tabla de evidencia de vulnerabilidades de GitLab EE, explotable por cualquier usuario autenticado con rol de desarrollador debido a una sanitización insuficiente de las entradas. Una segunda falla, CVE-2026-13320, con puntaje 7.3, permite inyección de HTML en el renderizado de markup de wikis, y afecta tanto a CE como a EE. El resto del boletín corrige fallas de severidad media y baja: CVE-2026-11827 (puntaje 4.9) exponía credenciales almacenadas durante el espejado de repositorios a usuarios con rol de mantenedor; CVE-2026-8472 (4.3) permitía leer metadatos de elementos de trabajo en proyectos privados de EE con permisos mínimos; y CVE-2026-7492 (4.3) permitía a usuarios sin autenticar detectar la existencia de proyectos privados a través de las páginas de discusión de commits, según el detalle publicado por GitLab. GitLab.com y GitLab Dedicated ya corren las versiones corregidas sin que sus clientes deban actuar; la recomendación de actualizar de inmediato aplica solo a instalaciones autoalojadas (self-managed). GitLab es la plataforma de control de versiones que usan bancos, aseguradoras y empresas de zona franca en Costa Rica que prefieren una instalación autoalojada sobre GitHub por razones de cumplimiento normativo; esos equipos son, precisamente, los que deben aplicar el parche de inmediato, mientras los que usan GitLab.com como servicio administrado ya están protegidos sin ninguna acción de su parte.

CVSS 8.7
Puntaje de la falla más grave corregida por GitLab el 8 de julio de 2026
05
N.º 05 Runtimes · Bun

Bun suma procesamiento de imágenes nativo y soporte experimental para HTTP/3

El equipo de Bun publicó el 8 de julio de 2026 la versión 1.3.14 del runtime de JavaScript, con dos funciones nuevas: Bun.Image, una API de procesamiento de imágenes integrada en el propio binario, sin adición nativa ni paso de recompilación, y soporte experimental para HTTP/3 (QUIC), según el blog oficial del proyecto. Bun.Image decodifica y codifica JPEG con libjpeg-turbo, PNG con spng y WebP y AVIF con libwebp, combinado con núcleos propios de geometría con instrucciones SIMD, y se presenta como reemplazo directo de la biblioteca Sharp que usan los proyectos de Node.js para redimensionar y transformar imágenes en el servidor. La versión corrige, además, 92 reportes de error acumulados en el repositorio del proyecto. El cliente HTTP/3 de fetch(), respaldado por una implementación de QUIC basada en la biblioteca lsquic, corre en paralelo a las rutas existentes de HTTP/1.1 y HTTP/2, y puede activarse de forma automática cuando un servidor anuncia el encabezado Alt-Svc: h3 en una respuesta HTTPS, sin que el código de la aplicación tenga que pedirlo de forma explícita. Bun.serve(), el servidor integrado del runtime, suma el mismo soporte de HTTP/3 del lado servidor. Bun compite de forma directa con Node.js y Deno por adopción en equipos de backend de JavaScript, y cada función que reduce la necesidad de dependencias nativas —como Sharp, que exige compilación específica por plataforma— es un argumento de venta concreto frente a esos dos competidores.

06
N.º 06 Panorama · Julio 2026

El ataque a jscrambler muestra los límites del nuevo blindaje de npm

La semana del 8 al 12 de julio de 2026 deja una lección concreta para la seguridad de la cadena de suministro de software: activar una protección por defecto no basta si el atacante puede mover la carga maliciosa a otro punto del ciclo de vida del paquete. npm 12.0.0 llegó a disponibilidad general el 8 de julio bloqueando por defecto los scripts de instalación, pero apenas tres días después el paquete jscrambler demostró en la práctica que un atacante con acceso a una cuenta de publicación puede trasladar la carga maliciosa de un script preinstall a una función que se ejecuta al importar el paquete, una vía que ningún bloqueo de scripts detiene. En paralelo, GitLab corrigió ocho fallas de seguridad el 8 de julio, Parse Server cerró su cuarta variante del mismo patrón de subida de archivos peligrosos en poco más de un mes el 11 de julio, y GitHub amplió la cobertura de su motor de análisis estático CodeQL a Kotlin 2.4.0 el 10 de julio. El patrón se repite desde que esta sección empezó a cubrir julio: cada capa nueva de seguridad automatizada —bloqueo de scripts, análisis estático, filtros de tipo de archivo— cierra una vía de ataque conocida mientras deja abiertas las que dependen de una cuenta comprometida o de un vector que nadie había anticipado todavía. El propio ataque a jscrambler es el ejemplo más claro de julio: los atacantes leyeron las notas de la versión 12 de npm y ajustaron su código en cuestión de días para esquivarla. Para los equipos de desarrollo en Costa Rica —de los estudios que ofuscan código de producción con jscrambler hasta los bancos que corren GitLab autoalojado— la lista de tareas de esta edición es concreta: fijar la versión de cualquier paquete de npm que use scripts de instalación o funciones ejecutadas al importarse, aplicar el boletín de seguridad de GitLab si la instalación es autoalojada, y revisar si algún proyecto en Parse Server sirve archivos subidos por usuarios desde almacenamiento en la nube sin las cabeceras de seguridad correctas.

5
Versiones maliciosas de jscrambler publicadas en npm en tres horas el 11 de julio
8
Vulnerabilidades que GitLab corrigió el 8 de julio en sus ediciones Community y Enterprise
4
Variante consecutiva del mismo patrón de subida de archivos peligrosos que Parse Server corrige en un mes

En esta fechaDesarrollo

Fuentes.