Una fuga de sandbox con CVSS 10 en la librería vm2 de Node.js permite ejecutar código en el equipo anfitrión, kcp corrige una suplantación total de administrador con CVSS 9.9 en su proxy de control, GitHub Copilot resuelve automáticamente comentarios de revisión de código atendidos, pnpm 12.5 gestiona proyectos Python dentro del mismo monorepo, Swift 6.4 adopta Swift Build como sistema de compilación por defecto y genera reportes SBOM nativos, Homebrew sigue destacando por su nuevo escáner de vulnerabilidades brew vulns, y un rastreo comunitario documenta un nuevo paquete malicioso en PyPI.
El fallo, catalogado como CVE-2026-93603 y corregido en la versión 3.12.1, deja que código no confiable ejecutado dentro de la librería de aislamiento vm2 obtenga acceso completo al proceso anfitrión de Node.js.
La firma de amenazas VulnCheck publicó el 18 de setiembre de 2026 el aviso técnico de CVE-2026-93603, una falla crítica (CVSS 10) en vm2, la librería de Node.js usada durante años para ejecutar código JavaScript no confiable dentro de un entorno aislado. Según el aviso, el problema está en cómo el puente de vm2 (lib/bridge.js) maneja un receptor this nulo dentro de la trampa apply: cuando el código en el sandbox llama a una función del anfitrión definida en modo no estricto sin especificar un receptor, el motor V8 sustituye ese valor por el objeto global del anfitrión, y vm2 envuelve y devuelve ese objeto al sandbox, entregándole una vía directa hacia process y, desde ahí, hacia la ejecución de comandos del sistema mediante child_process.execSync. El aviso de VulnCheck señala un límite importante que esta edición destaca frente a la alarma que suele acompañar un CVSS de 10: la explotación exige que la aplicación que incrusta vm2 exponga al menos una función del anfitrión en modo no estricto (sloppy mode); las funciones en modo estricto y los módulos ES no quedan expuestos a este vector. Ese matiz no reduce la gravedad de fondo, porque vm2 sigue empaquetado dentro de numerosas herramientas que ejecutan código generado o recibido de terceros de forma automatizada, un uso que la firma de seguridad Kodem describió como particularmente extendido en sistemas que corren fragmentos de código sin supervisión humana directa, según su análisis publicado esta semana. TheHackerWire, que confirmó el aviso, no reportó explotación activa documentada al cierre de esta edición. Costa Rica tiene una comunidad de desarrollo en JavaScript y Node.js amplia entre agencias digitales y empresas de zona franca tecnológica, algunas de las cuales ejecutan flujos de automatización con código dinámico; cualquier equipo tico que incruste vm2 en un servicio propio debería confirmar hoy mismo si actualizó a la versión 3.12.1, sin que se conozca ningún caso costarricense afectado.
El catálogo de avisos de GitLab Advisory Database publicó, el 19 de setiembre de 2026, la falla CVE-2026-61682 sobre kcp, un proyecto de la comunidad de Kubernetes que implementa un plano de control multiquilino al estilo Kubernetes-as-a-Service. Según el aviso, el proxy frontal (front-proxy) de kcp no eliminaba las cabeceras de identidad entrantes X-Remote-User, X-Remote-Group y X-Remote-Extra-* antes de reenviar las solicitudes a los fragmentos (shards) del clúster, así que cualquier inquilino autenticado podía fabricar sus propias cabeceras de grupo y el fragmento las aceptaba como una identidad ya verificada. Eso permitía a un usuario de bajos privilegios escalar hasta convertirse en administrador del clúster (system:masters) y leer, escribir o borrar recursos, secretos y datos de control de acceso en cualquier espacio de trabajo del mismo fragmento, con severidad crítica de CVSS 9.9. El riesgo real depende de un factor que limita el alcance de la falla frente a otras vulnerabilidades de la semana: kcp está diseñado específicamente para operar planos de control multiquilino, un patrón de despliegue con varios inquilinos compartiendo la misma instancia, bastante menos común que un clúster de Kubernetes convencional de un solo inquilino, que es como corre la mayoría de las cargas de trabajo empresariales hoy. OSV.dev, que replicó el aviso, no reporta explotación activa confirmada al cierre de esta edición. CVE Brief ubicó esta falla y la de vm2 como las dos de mayor puntaje del boletín de CVE del 19 de setiembre, con 31 fallas críticas y 91 de severidad alta documentadas ese día. La adopción de kcp en Costa Rica es todavía marginal frente a Kubernetes estándar, concentrada como mucho en proyectos experimentales de plataformas internas de algún equipo de infraestructura de zona franca; no hay reporte de instalaciones costarricenses afectadas, y el efecto directo sobre el país es, con la información disponible, marginal.
GitHub publicó, el 18 de setiembre de 2026 en su blog de cambios (GitHub Changelog), el resumen semanal de actualizaciones de Copilot correspondiente a la semana del 14 de setiembre. La revisión de código de Copilot ahora resuelve automáticamente, en revisiones posteriores del mismo cambio, los comentarios que ya señaló y que el desarrollador corrigió, dejando visibles únicamente los señalamientos pendientes, según el propio anuncio. La actualización también suma niveles de eficiencia, equilibrio e inteligencia a la selección automática de modelo, que permiten a quien programa decidir si Copilot prioriza el costo, la calidad de la respuesta o la velocidad. Esta sección reportó ayer el recorte de hasta 44,3% en la asignación mensual incluida de Copilot Enterprise y de 36,7% en Copilot Business, vigente desde el 1° de setiembre; el cambio de hoy es de funcionalidad, no de facturación, pero llega en la misma semana en que GitHub confirmó que reactivó, desde el 1° de setiembre, el alta de nuevos clientes de Business y Enterprise que pagan con tarjeta de crédito o PayPal, según recogió Developers Digest. GitHub no ha publicado, en las fuentes consultadas, cifras de cuántos equipos usan ya los nuevos niveles de selección de modelo. GitHub Copilot es una de las herramientas de asistencia de código de mayor adopción entre programadores costarricenses de empresas de zona franca; los niveles de selección por costo permiten a esos equipos ajustar su consumo de créditos tras el recorte de cuota reportado ayer, sin que se conozca todavía cuántas empresas ticas migraron a los nuevos niveles.
El equipo de pnpm publicó esta semana la versión 12.5 del gestor de paquetes de JavaScript, según el anuncio oficial en el blog de pnpm.io y el resumen semanal de lanzamientos del ingeniero de software Andrew Nesbitt, publicado hoy. La nueva versión instala en modo editable el propio paquete Python de un proyecto cuando este declara una sección [build-system], de forma que sus importaciones y comandos de [project.scripts] funcionan de inmediato; además, pnpm install elige automáticamente el intérprete que satisface el requires-python de cada proyecto, con preferencia por el archivo .python-version cuando existe, y descarga un intérprete compartido de python-build-standalone si ninguno instalado calza. Para monorepos con varios proyectos, pnpm 12.5 resuelve todos los miembros en un único archivo pylock.toml y un solo entorno virtual (.venv) en la raíz del área de trabajo, y genera un error que nombra a los proyectos en conflicto cuando las dependencias de Python son incompatibles entre sí. La versión también admite bloqueos para varias plataformas y versiones de Python a la vez, acepta identificadores Package URL en pnpm add y suma un comando pnpm cache prune para limpiar metadatos de registro obsoletos. La función amplía el soporte de Python que pnpm sumó en su versión 12.4, en un movimiento que lo acerca a herramientas especializadas como uv o Rye para equipos que combinan JavaScript y Python en un mismo repositorio. Costa Rica tiene una comunidad de desarrollo activa en Node.js dentro de agencias digitales y empresas de zona franca que cada vez combinan más servicios en JavaScript con scripts de automatización o análisis de datos en Python; una gestión unificada de dependencias de ambos lenguajes en una sola herramienta simplifica ese flujo de trabajo, sin que se conozca todavía adopción documentada de esta versión específica en el país.
— La nueva versión instala paquetes Python en modo editable, descarga automáticamente el intérprete que cada proyecto necesita y comparte un mismo archivo de bloqueo para todo el flujo de trabajo, según el anuncio oficial.
cat /feed/swiftherramientasdev.md
La nueva versión unifica cómo se compilan los paquetes en Linux, macOS y Windows y suma generación nativa de reportes de inventario de software (SBOM) en los formatos SPDX y CycloneDX.
> El proyecto Swift publicó, en su blog oficial swift.org, el anuncio de la versión 6.4 del lenguaje, en el que Swift Build pasa a ser el sistema de compilación por defecto del gestor de paquetes de Swift (SwiftPM), en reemplazo del sistema de compilación heredado, con el objetivo de que un mismo paquete se compile de forma idéntica en Linux, macOS y Windows. La versión también implementa la propuesta de evolución del lenguaje SE-0509, que agrega generación nativa de reportes de inventario de software (SBOM, por sus siglas en inglés) directamente desde SwiftPM, en los formatos SPDX 3.0 y CycloneDX 1.7, según documenta la propuesta publicada en el repositorio swift-evolution de GitHub.
> El sitio especializado en Windows WindowsForum.com destacó que la novedad completa la paridad de Swift Build entre las tres plataformas, un objetivo que el proyecto persiguió durante buena parte de 2026 después de que el sistema de compilación heredado tratara a Windows como una plataforma de segunda categoría en varios flujos de trabajo. La generación nativa de SBOM llega la misma semana en que esta sección documentó fallas de cadena de suministro en npm, JFrog Artifactory y el ecosistema de Rust, aunque el anuncio de Swift no vincula ambos hechos ni los presenta como una respuesta directa a esos incidentes.
> Costa Rica tiene un ecosistema de desarrollo Swift comparativamente pequeño, concentrado en equipos de aplicaciones móviles iOS de algunas agencias digitales y startups; la generación nativa de SBOM facilita a esos equipos responder a clientes internacionales que ya exigen un inventario de dependencias por contrato, sin que se conozca adopción documentada todavía en el país.
Homebrew publicó, el 13 de setiembre de 2026 en su blog oficial brew.sh, la versión 7.0.0 del gestor de paquetes más usado en macOS, con el nuevo comando brew vulns como novedad central: permite escanear las fórmulas instaladas contra una base de datos de avisos propia de Homebrew, con licencia CC0 y formato OSV, combinada con datos de OSV.dev, sin necesitar un tap adicional ni una gema de Ruby aparte, según recogió Help Net Security. Esta edición recupera hoy la noticia porque el resumen semanal de lanzamientos de Andrew Nesbitt, publicado ayer, la mantiene como uno de los cambios de mayor comentario en la comunidad de gestión de paquetes. La versión también endurece el aislamiento de las operaciones de instalación: en Linux, Homebrew sustituyó el marco de sandboxing Bubblewrap por Landlock, una función a nivel de kernel que elimina la dependencia de Docker o de permisos elevados, mientras que en macOS bloquea por defecto las lecturas desde el directorio personal del usuario durante la instalación de fórmulas y casks, según documentó BleepingComputer. El cambio corrige además dos fallas de las propias herramientas de Homebrew: una de severidad alta (GHSA-rg9r-ppxp-87hm), corregida en la versión 6.0.12, en la que metadatos de eliminación de casks sin firmar podían ejecutar comandos con sudo, y una moderada (GHSA-5263-whxq-77hp) en la que un cask malicioso podía ejecutar código fuera del sandbox de instalación de macOS a través de LaunchServices. Costa Rica tiene una base amplia de programadores que usan macOS y Homebrew como gestor de paquetes por defecto en agencias digitales y empresas de zona franca tecnológica; el cambio de sandboxing en Linux beneficia en particular a equipos ticos que corren Homebrew dentro de contenedores de integración continua sin privilegios de administrador, sin que se conozca todavía qué proporción de esos equipos ya actualizó a la versión 7.0.0.
El proyecto de código abierto compromised-packages-check, que rastrea a diario las exportaciones masivas en formato OSV del catálogo de paquetes maliciosos de OpenSSF, registró en su reporte del 19 al 20 de setiembre de 2026 el paquete de PyPI urc, identificado como MAL-2026-16298, publicado con el número de versión 99.99.99, según el registro público del proyecto en GitHub. El paquete sobrescribe el comando de instalación en su archivo setup.py para exfiltrar información básica del equipo -dirección IP y nombre de usuario- hacia un servidor remoto en el momento de la instalación, y su número de versión inusualmente alto sigue el mismo patrón de confusión de dependencias que esta sección documentó ayer con los paquetes de prueba "test89-auth" y sus variantes. compromised-packages-check es un proyecto independiente que consume el feed público de OpenSSF; no es un canal oficial de PyPI ni de GitHub, y la información de este caso proviene únicamente de ese rastreo automatizado, sin confirmación cruzada de un aviso oficial ni de cobertura de un medio especializado al cierre de esta edición. El lote de hoy es más pequeño que el de los últimos cuatro días consecutivos que esta sección reportó, lo que no permite concluir si el ritmo de publicación de paquetes maliciosos bajó o si el rastreo simplemente capturó menos actividad en esta ventana puntual. Costa Rica tiene desarrolladores que instalan paquetes de PyPI a diario en pipelines de automatización y ciencia de datos entre agencias digitales y equipos de zona franca; confirmar el nombre exacto y el número de versión de cualquier paquete antes de instalarlo sigue siendo la defensa más simple frente a este tipo de sondeo, sin que se conozca impacto local confirmado de este caso.
La jornada del 20 de setiembre de 2026 en desarrollo estuvo marcada por dos fallas críticas en piezas fundamentales de la infraestructura de código: una fuga total de sandbox con CVSS 10 en vm2, la librería de aislamiento de Node.js que todavía usan varias herramientas de ejecución automatizada de código, y una suplantación completa de administrador con CVSS 9.9 en kcp, el plano de control multiquilino de Kubernetes. En herramientas de desarrollo, GitHub Copilot sumó una función que resuelve automáticamente comentarios de revisión de código ya atendidos, pnpm 12.5 unificó la gestión de proyectos Python y JavaScript dentro de un mismo monorepo, Swift 6.4 adoptó Swift Build como sistema de compilación por defecto con generación nativa de reportes SBOM, Homebrew sigue destacando por su nuevo escáner de vulnerabilidades brew vulns, y un rastreo comunitario documentó un nuevo paquete malicioso en PyPI. El hilo que conecta la mayoría de las historias de hoy es el control de acceso: quién puede hacerse pasar por quién, ya sea una función del anfitrión que vm2 confunde con el objeto global, una cabecera HTTP que kcp acepta sin verificar, o un paquete con un número de versión fabricado para saltarse una dependencia legítima. Ninguna de las dos fallas críticas de hoy tiene, según las fuentes consultadas, explotación activa confirmada, pero ambas afectan piezas que numerosos sistemas dan por sentadas en su cadena de confianza. Todas las historias completas, con sus fuentes primarias, quedan disponibles arriba para decidir qué revisar primero la próxima semana.