Payload y Backstage destapan fallas reportadas desde agosto, vm2 suma una fuga de sandbox con el puntaje máximo posible y un clúster de typosquats de Hardhat reactiva el rastreo diario de paquetes maliciosos.
El GitHub Advisory Database sumó, entre el 6 y el 7 de octubre de 2026, tres avisos de severidad crítica para dos herramientas de desarrollo ampliamente usadas: dos fallas en payload -el CMS headless de código abierto para Node.js- y una en @backstage/plugin-scaffolder-backend, el complemento de generación de proyectos del portal de desarrollo interno Backstage. La primera falla de Payload, CVE-2026-105859 (GHSA-f7hx-52q9-hcrf), con puntaje CVSS de 9.8, permite actualizar documentos de cualquier colección sin aplicar control de acceso cuando el proyecto configura el campo orderable en true; la segunda, CVE-2026-105863 (GHSA-66wr-7vmr-p5jq), con CVSS de 9.2, puede filtrar valores no previstos dentro del token de autenticación emitido al iniciar sesión, según la descripción oficial de cada aviso. La falla de Backstage, CVE-2026-106501 (GHSA-g2v8-7jhw-pp8p), con CVSS de 9.6, permite que un usuario autenticado que pueda leer la tarea de otro dentro del Scaffolder acceda a datos de ejecución interna, incluidas credenciales de servicios externos. Las tres quedan corregidas en payload 3.90.0 (o 4.0.0-canary.34) y en Backstage 4.1.0, según las propias páginas de aviso. Ninguna de las tres fallas es nueva: el propio registro de GitHub indica que sus fabricantes las reportaron de forma privada el 18 de setiembre -ambas de Payload- y el 28 de agosto -Backstage-, hasta 40 días antes de que la base nacional de vulnerabilidades (NVD) las publicara el 6 de octubre y de que llegaran al listado público de GitHub un día después. Esta sección ya documentó, entre el 1 y el 3 de octubre, un patrón similar de avisos que la base mostraba como recién actualizados pese a tener semanas de antigüedad real; que el mismo fenómeno reaparezca ahora con tres fallas críticas de dos proyectos distintos sugiere que el retraso de ingesta no fue un episodio aislado, sino un rasgo estructural de cómo GitHub alimenta su propia base, antes que una señal de que el ecosistema se volvió más peligroso de un día para otro. Payload recomienda, en el texto de ambos avisos, actualizar a la versión 3.90.0 o revisar si algún campo mapea un nombre reservado del token de autenticación; Backstage ofrece como mitigación temporal restringir el permiso scaffolder.task.read a la condición isTaskOwner mientras se aplica el parche 4.1.0. Agencias digitales y bancos costarricenses que usan Payload como gestor de contenido headless o Backstage como portal interno de desarrollo deberían confirmar su versión antes del próximo despliegue; no se conoce, al cierre de esta edición, un caso costarricense comprometido por alguna de las tres fallas.
El proyecto de código abierto compromised-packages-check registró, en su barrido del 8 de octubre de 2026 (PR 151), 29 entradas nuevas de paquetes maliciosos en npm, sin ninguna en PyPI, según el registro público del proyecto en GitHub. El lote incluye un clúster de cinco paquetes -hardhat-bits, hardhat-deep, hardhat-option, hardhat-pack y hardhat-promised-, identificados bajo los códigos OSV MAL-2026-17658 a MAL-2026-17662, que imitan el nombre de Hardhat, el framework de desarrollo y pruebas más usado para contratos inteligentes de Ethereum; dos paquetes más, function-color y function-flag, se describen en el mismo reporte como "paquetes exfiltradores de credenciales" (MAL-2026-17647 y MAL-2026-17648). El lote suma además cuatro paquetes de polyfills y utilidades CSS -entre ellos css-reading-display-polyfill y wix-ssr-thunderbolt-grid-polyfill- que el registro vincula a "cargadores de C2 de thunderboltRegistry.js", y 14 typosquats y ataques de confusión de dependencias adicionales, incluidos cuatro paquetes marcados como "tombstoned" -retirados de npm bajo un parche de seguridad 0.0.1- que datan de 2022 y 2025. La campaña de typosquatting contra Hardhat no es nueva: Forklog documentó, ya en enero de 2025, más de 20 paquetes falsos que imitaban complementos de Hardhat para robar llaves privadas y frases semilla de desarrolladores de Ethereum, y esta sección registró un paquete adicional de ese mismo patrón -captchetat-angularv8- apenas el 7 de octubre, en el barrido anterior del mismo proyecto (PR 150, con 10 entradas nuevas). Esta edición retoma además el indicador diario de paquetes maliciosos, que había quedado en pausa el 7 de octubre por falta de una cifra verificada esa jornada. La recomendación de siempre para quien use Hardhat sigue siendo confirmar que cualquier paquete relacionado se publique bajo el espacio de nombres oficial @nomicfoundation o el nombre exacto hardhat, sin variantes. Costa Rica tiene una comunidad activa de desarrolladores de contratos inteligentes y aplicaciones Web3 en zonas francas y comunidades cripto locales, varios de los cuales usan Hardhat a diario como entorno de pruebas; no se conoce un caso costarricense afectado por este lote al cierre de esta edición.
CVE-2026-93605 permite ejecutar comandos en el sistema anfitrión desde dentro del sandbox de vm2 porque la lista de módulos prohibidos nunca incluyó a child_process, según el aviso oficial publicado el 7 de octubre.
El GitHub Advisory Database publicó, el 7 de octubre de 2026, CVE-2026-93605 (GHSA-pq68-rvw4-xp4r) para vm2, la biblioteca de aislamiento de código JavaScript en Node.js: la lista de módulos peligrosos (DANGEROUS_BUILTINS) de su componente NodeVM nunca incluyó a child_process, pese a bloquear otros módulos capaces de generar procesos en el sistema anfitrión. Según la descripción oficial del aviso, cuando una configuración de NodeVM permite todos los módulos nativos o habilita child_process de forma explícita, el código que corre dentro del sandbox puede cargar ese módulo y ejecutar comandos directamente sobre la máquina que lo alberga. La falla recibió un puntaje CVSS de 10.0 sobre 10 -el máximo posible en la escala- y queda corregida en la versión 3.12.1. El puntaje máximo llama la atención, pero el propio repositorio de vm2 en GitHub advierte, desde 2023, que el proyecto está obsoleto y recomienda migrar a isolated-vm o al módulo vm nativo de Node.js, porque sus fugas de sandbox resultaron, según esa misma advertencia, estructuralmente imposibles de cerrar por completo. Esta es la sexta falla crítica de vm2 que esta sección documenta en cuatro días -dos el 5 de octubre, una el 6 y otras tres, incluida esta, el 7-, todas sobre un proyecto cuyo propio mantenedor dejó de recomendar su uso hace tres años. El dato pesa más como medida de cuánto código heredado sigue dependiendo de una librería abandonada que como evidencia de que el sandboxing en Node.js se volvió, de un día para otro, más riesgoso. La información de este caso proviene únicamente del aviso oficial de GitHub, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. Costa Rica tiene empresas de zona franca y bancos que ejecutan código de terceros -complementos, scripts de automatización- dentro de sandboxes de Node.js; quienes todavía dependan de vm2 para ese aislamiento deberían planear la migración a isolated-vm antes de que aparezca una séptima falla, sin que se conozca un caso costarricense afectado.
Cloudflare publicó, entre el 6 y el 8 de octubre de 2026, tres versiones consecutivas de workerd, el motor de código abierto que corre Cloudflare Workers, según el registro oficial de versiones del proyecto en GitHub. La v1.20261006.1 (6 de octubre) prohíbe por defecto el código Rust marcado como unsafe y el que puede entrar en pánico (panic) en todos los crates internos del proyecto (PR 7616), además de ajustar la resolución de microtareas; la v1.20261007.1 (7 de octubre) introduce kj-rs-tokio, un entorno en el que el hilo principal (main) de Rust pasa a controlar el bucle de eventos de KJ -la biblioteca interna de E/S asíncrona de Cloudflare- y suma trazas de diagnóstico para Python Workers; la v1.20261008.1 (8 de octubre) corrige un conteo de asignaciones de memoria de cppgc que se reportaba a V8 fuera de su ventana sin recolección de basura. Es la séptima y octava entrega que esta sección documenta en la racha casi diaria de workerd desde finales de setiembre, y la primera vez en esa racha que una versión prohíbe por defecto, en todo el código Rust del proyecto, patrones que antes dependían de la disciplina de quien programaba cada módulo. Endurecer esa regla reduce la superficie de errores de memoria dentro de un runtime que procesa tráfico de producción para miles de aplicaciones sobre Cloudflare Workers. La información de este caso proviene únicamente del registro oficial de versiones de workerd en GitHub, sin cobertura cruzada de un medio especializado al cierre de esta edición. Costa Rica no aloja una región de Cloudflare, pero agencias digitales y startups ticas que despliegan aplicaciones sobre Workers reciben las tres actualizaciones de forma automática en su próximo despliegue, sin que se conozca todavía un caso de uso local de kj-rs-tokio.
El GitHub Advisory Database publicó dos avisos de severidad crítica esta semana: CVE-2026-106102 (GHSA-pq96-jpmf-w254), con un puntaje CVSS de 10.0, para quasar, el framework basado en Vue.js para construir aplicaciones web, móviles y de escritorio desde un mismo código; y CVE-2026-102422 (GHSA-pqg4-j6r4-53mv), con un puntaje CVSS de 9.2, para shell-quote, una utilidad pequeña y muy usada como dependencia transitiva para citar comandos de shell en Node.js. En Quasar, la función getHead() inserta valores de título, meta y enlaces en el HTML renderizado del lado del servidor sin escaparlos, lo que permite inyectar marcado -incluidos scripts- a través de cualquier texto que llegue al composable useMeta(), según la descripción oficial del aviso; el fallo se corrige en la versión 2.22.0. En shell-quote, la función quote() puede ejecutar comandos arbitrarios cuando una cadena con un salto de línea aparece después de un token de tipo comentario, lo que permite que el resto de la cadena se interprete como una nueva instrucción de shell; el fallo, ya reportado parcialmente como CVE-2026-9277, no quedó completamente cerrado hasta la versión 1.11.0. Ambos paquetes funcionan como piezas de infraestructura silenciosa: shell-quote aparece como dependencia transitiva de cientos de herramientas de línea de comandos en Node.js, y Quasar sostiene aplicaciones de producción completas construidas sobre Vue.js. El patrón de la falla de shell-quote -un parche anterior que cerró un vector pero dejó abierta una variante relacionada- repite un problema común en librerías de utilidades de bajo nivel: corregir el caso reportado no siempre cierra la clase completa de error. Quien use quote() de shell-quote junto con parse() sobre cadenas no confiables debería actualizar a la versión 1.11.0 cuanto antes; quien use useMeta() en Quasar con texto que provenga de usuarios -un título de blog, un nombre de perfil- debería hacer lo mismo con la versión 2.22.0. Equipos costarricenses que construyen paneles administrativos o apps multiplataforma sobre Quasar, o que automatizan tareas de shell desde Node.js en sus pipelines de integración continua, deberían revisar sus lockfiles contra ambas versiones; no se conoce un caso costarricense afectado al cierre de esta edición.
— Un fallo de scripting en el renderizador de meta-etiquetas de Quasar y una inyección de comandos en la función quote() de shell-quote recibieron, por separado, el puntaje más alto posible de severidad.
La jornada combina dos arcos que esta sección viene siguiendo desde principios de mes: la base de avisos de GitHub reavivó, con hasta 40 días de atraso, tres fallas críticas de Payload y Backstage reportadas en agosto y setiembre, mientras vm2 sumó una sexta falla crítica en cuatro días -esta con el puntaje máximo posible, CVSS 10.0, sobre un proyecto que su propio mantenedor dejó de recomendar en 2023-. El rastreo diario de paquetes maliciosos retomó su indicador con 29 entradas nuevas en npm, encabezadas por un clúster de cinco typosquats del framework Hardhat para contratos de Ethereum. Por separado, GitHub publicó otras dos fallas críticas en Quasar y shell-quote, y Cloudflare endureció workerd para prohibir código Rust sin verificar por defecto en todos sus crates. Todas las historias completas, con sus fuentes primarias, quedan disponibles arriba para decidir qué actualizar o parchar primero esta semana.