Appium corrige un segundo Zip Slip que el parche de marzo no cerró, JavaCV repara un desbordamiento de enteros que congela grabadores de cámaras IP, Cloudflare suma a Ryan Dahl como autor de su primer parche en workerd mientras actualiza el motor a V8 15.7, JupyterLab cierra una condición de carrera en su aviso de confianza, Borg corrige una vía de extracción fuera de directorio, GitHub revisa fallas menores en un servidor MCP de CKAN y en ClickMigrate, y el rastreo comunitario de paquetes maliciosos halla 19 entradas nuevas en npm y PyPI.
Una semana después de que Cloudflare anunciara la incorporación de todo el equipo de Deno, Ryan Dahl firmó su primera contribución a workerd -el mismo lanzamiento que actualiza el motor V8 a la versión 15.7.
Cloudflare publicó, el 17 de octubre de 2026, la versión v1.20261017.1 de workerd, el motor de código abierto que corre Cloudflare Workers, con 17 cambios fusionados según el registro oficial de versiones del proyecto en GitHub. La entrega suma la primera actualización del motor V8 desde que el servidor pasó a Rust -a la versión 15.7, en un parche de csjh (PR #7776)-, además de una política de reintentos configurable por stub para Durable Objects (PR #7672, ticket interno STOR-5615, de apeacock1991). El cambio que más llama la atención, sin embargo, no es técnico sino de autoría: el PR #7747, que corrige una condición de carrera donde una excepción lanzada por una llamada RPC de un actor podía llegarle a quien la invocó antes de que su escritura de estado quedara confirmada por la compuerta de salida del propio workerd, lo firma la cuenta de GitHub ry -marcada por la plataforma como su primera contribución al repositorio-. Esa cuenta pertenece a Ryan Dahl, creador de Node.js y de Deno: su perfil público de GitHub lo lista bajo las organizaciones Cloudflare y denoland. El desarrollador jasnell revisó el parche en varias rondas junto con Kenton Varda, el arquitecto principal de workerd, y lo fusionó el 16 de octubre. La llegada de Dahl a workerd ocurre apenas una semana después de que Cloudflare anunciara, el 9 de octubre, la incorporación de todo el equipo de Deno -la empresa que Dahl fundó tras crear Node.js-, según reportó The New Stack citando el anuncio conjunto de ambas compañías. El acuerdo deja al runtime de Deno con un año de parches de seguridad y corrección de errores antes de que el desarrollo propio se detenga, cierra Deno Deploy en unos seis meses, y reorienta al equipo hacia hacer que Workers y los Durable Objects distribuidos sean prácticos de auto-alojar, de acuerdo con la misma cobertura. Que el propio Dahl aparezca, siete días después, corrigiendo directamente el motor de producción de Cloudflare -y no solo opinando sobre la transición- convierte la integración técnica del fichaje en un hecho verificable y no solo en un anuncio corporativo. La información sobre el parche proviene del registro oficial de versiones de workerd y de la discusión de código en GitHub; los detalles sobre la incorporación del equipo de Deno provienen de la cobertura de The New Stack, sin que Cloudflare o Deno hayan publicado los términos financieros del acuerdo. Costa Rica no aloja una región de Cloudflare, pero agencias digitales y startups ticas que apostaron por Deno como runtime, en vez de Node.js, deberían empezar a planear una ruta de migración hacia Cloudflare Workers antes de que se cierre la ventana de mantenimiento de un año que ambas empresas anunciaron, sin que se conozca un caso costarricense afectado al cierre de esta edición.
Un enlace simbólico dentro de un archivo comprimido permite escribir fuera del directorio de extracción en @appium/support, pese a que Appium ya había cerrado un Zip Slip similar en marzo.
El GitHub Advisory Database revisó y actualizó, el 15 de octubre de 2026, el aviso GHSA-qfxx-c367-67f8 (CVE-2026-103975, CVSS 3.1 de 6.5, severidad moderada) para @appium/support, el paquete de npm que maneja archivos y extracción de ZIP dentro de Appium, el framework de código abierto de automatización de pruebas móviles. Según la descripción oficial, el verificador de contención del extractor es puramente léxico y nunca resuelve enlaces simbólicos: un archivo comprimido puede crear primero un symlink cuyo destino apunta fuera del directorio de extracción y luego incluir un archivo regular cuyo nombre se resuelve a través de ese symlink, lo que permite escribir fuera de la carpeta prevista -el propio destino del enlace también se escribe sin validar-. La falla, clasificada bajo CWE-59 (resolución incorrecta de enlaces antes de acceder a un archivo), afecta a todas las versiones hasta la 7.2.5 y fue reportada por el investigador nikkoenggaliano. La versión 7.2.6 corrige el problema. Es la segunda vez en el año que @appium/support recibe un aviso de Zip Slip: el propio texto del aviso aclara que esta falla es distinta de CVE-2026-30973, corregida en la versión 7.0.6 publicada en marzo de 2026, y que el nuevo vector seguía siendo explotable incluso en la 7.2.5, la versión vigente hasta esta corrección. Que un primer parche contra Zip Slip -la clase de ataque que usa rutas de archivo manipuladas para escapar del directorio de extracción- dejara abierta una variante basada en enlaces simbólicos durante siete meses más complica cualquier lectura de que la corrección de marzo había cerrado el problema de fondo. Appium se usa de forma rutinaria en integración continua para extraer binarios de controladores y artefactos de prueba que la propia herramienta descarga, lo que vuelve relevante cualquier servidor de pruebas que procese archivos comprimidos de origen externo o de terceros. La información de este caso proviene únicamente de los avisos oficiales de GitHub, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. Appium es la herramienta de automatización de pruebas móviles más usada entre equipos de control de calidad de software costarricenses que trabajan para clientes internacionales desde zonas francas; esos equipos deberían confirmar que corren @appium/support 7.2.6 o posterior antes de su próxima corrida de integración continua, sin que se conozca un caso costarricense afectado al cierre de esta edición.
El GitHub Advisory Database revisó y actualizó, el 16 de octubre de 2026, el aviso GHSA-rxjv-24xq-76wc (CVE-2026-102834, CVSS 3.1 de 7.5, severidad alta) para org.bytedeco:javacv, el paquete de Maven que envuelve OpenCV, FFmpeg y otras librerías de visión por computadora para Java. Según la descripción oficial, la clase IPCameraFrameGrabber lee el valor de Content-Length de una transmisión MJPEG multiparte sin verificar límites; un valor entre 1.073.741.825 y 2.147.483.647 desborda el entero de 32 bits que usa internamente ensureBufferCapacity y produce un bucle infinito que ni los tiempos de espera ni las interrupciones de hilo logran detener, de acuerdo con el aviso. La falla, clasificada bajo CWE-190 (desbordamiento de enteros), fue reportada por el investigador tinyb0y y publicada por saudet, el mantenedor del proyecto. La versión 1.5.14, publicada el 10 de agosto de 2026 según las notas de la propia versión, corrige el problema. El aviso precisa que un atacante de red que pueda manipular una transmisión MJPEG sin cifrar -el transporte habitual de cámaras IP de consumo e industriales que no terminan TLS- puede activar la falla sin autenticación ni interacción del usuario; un servidor que corra un hilo de captura por cámara, la arquitectura típica de una plataforma de videovigilancia construida sobre JavaCV, puede quedar agotado por completo si el ataque se repite contra cada cámara que vigila. Que la falla tardara casi tres meses entre su corrección, en agosto, y su incorporación al catálogo de avisos de GitHub, el 16 de octubre, muestra que las correcciones de seguridad en herramientas de visión por computadora circulan más lento que en los frameworks web convencionales. La información de este caso proviene únicamente del aviso oficial de GitHub y de las notas de la versión 1.5.14 del proyecto, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. JavaCV es una librería de nicho dentro del ecosistema Java, usada sobre todo en proyectos académicos y de visión por computadora; no hay evidencia pública de integradores de cámaras IP costarricenses que dependan de ella, por lo que el impacto local es marginal al cierre de esta edición.
El proyecto de código abierto compromised-packages-check registró, en su PR 160 -fusionado el 17 de octubre de 2026, con un barrido fechado el 16 y 17 de octubre-, 19 entradas nuevas de paquetes maliciosos: 17 en npm y 2 en PyPI, según el registro público del proyecto en GitHub. El lote más grande es una campaña de confusión de dependencias contra el dominio realwbx.com, que agrupa cuatro paquetes -buyerdashboard, idlive-face-capture-web-development, web-pixels-manager y xapi-lib-, con números de versión inflados y un script de preinstalación que ejecuta node index.js para enviar la identidad del equipo infectado a https://realwbx.com/ip.php. El registro suma, además, dos paquetes nuevos bajo el espacio @flexmr (survey-client y survey-conversation) que repiten la misma baliza que ya documentaron @flexmr/ui y @flexmr/utils el 15 y el 16 de octubre, y un clúster de siete paquetes bajo el espacio @beloved-lenora -descrito en el propio PR como "attacker-controlled scope masquerading as opencode sub-packages"- que imitan subpaquetes de la herramienta de terminal opencode, el mismo blanco que esta sección cubrió por primera vez el 14 de octubre bajo el nombre opencode2. En PyPI, el lote documenta dos infostealers: fromthehotel-poems, que esconde ejecución remota de código detrás de una función con apariencia inocua, y marocolor, que arranca un hilo en segundo plano al importarse para contactar un servidor remoto de comando y control. El PR también documenta un caso distinto al patrón habitual de typosquatting: dos paquetes reales y ya establecidos del proyecto itsa-react (itsa-react-focuscontainer e itsa-react-maskedinput) reciben versiones nuevas maliciosas publicadas directamente sobre el paquete legítimo, lo que el propio registro describe como "legitimate itsa-react component packages with malicious releases" -no una imitación con nombre parecido, sino una cuenta de publicación comprometida que sube código malicioso a un paquete que los usuarios ya tenían instalado-. Ese tipo de compromiso es más difícil de detectar que un typosquat porque no depende de que la víctima escriba mal un nombre: basta con que ya use el paquete y acepte una actualización de rutina. La cifra de hoy -19- se mantiene en el rango bajo de las últimas dos semanas, pero la reaparición del blanco @flexmr por tercer día consecutivo y la ampliación del ataque contra opencode a un nuevo espacio de nombres confirman que ambas campañas siguen activas. La información de este caso proviene únicamente del registro del proyecto compromised-packages-check en GitHub, sin confirmación cruzada de Socket.dev, Phylum o Sonatype al cierre de esta edición. Cualquier organización costarricense con su propio scope de npm, o que dependa de paquetes de interfaz de terceros como itsa-react, enfrenta el mismo tipo de riesgo que documenta este lote, sin que se conozca un caso costarricense afectado.
El GitHub Advisory Database revisó y actualizó, el 15 de octubre de 2026, el aviso GHSA-jwrc-gm9j-263p (CVE-2026-102832, CVSS 3.1 de 4.2, severidad moderada) para jupyterlab, jupyterlite-core y notebook, las interfaces de código abierto para cuadernos interactivos más usadas en ciencia de datos con Python. Desde la versión 4.5.7, un archivo Markdown o la salida de un cuaderno pueden incluir un botón que ejecuta un comando de JupyterLab; el primer clic abre un aviso con tres opciones -Cancel, Run Once y Trust-, según la descripción oficial. El problema es que cuál documento queda marcado como confiable se decide en el momento en que el usuario responde el aviso, no en el momento en que hizo clic: si otro documento se vuelve la pestaña activa mientras el aviso sigue abierto, es ese otro documento el que queda marcado como confiable. Si el documento marcado por error es un cuaderno, el cambio se guarda de inmediato en disco -y ese guardado arrastra también cualquier edición sin guardar que el usuario tuviera pendiente en él-. La falla, clasificada bajo CWE-367 (condición de carrera) y CWE-863 (autorización incorrecta), fue reportada por el investigador rexpository; MUFFANUJ construyó la corrección y krassowski coordinó el proceso. Las versiones corregidas son jupyterlab 4.6.4 y 4.5.11, jupyterlite-core 0.8.4 y notebook 7.6.3. Confiar en un cuaderno de JupyterLab es, por diseño, una decisión estrecha y deliberada: un cuaderno confiable ejecuta sin más avisos su HTML y JavaScript incrustados y los botones ligados a comandos, de modo que todo el modelo de seguridad depende de que esa confianza quede atada al documento que el usuario realmente miró. Una condición de carrera capaz de atar esa confianza a un documento distinto -y que además la persiste en disco sin que el usuario lo note- debilita una protección que Jupyter ofrece desde el diseño original de "cuaderno confiable", pensado específicamente para salidas de origen no confiable que circulan por correo o repositorios de código. 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. JupyterLab es una herramienta común entre equipos de ciencia de datos y cursos universitarios de programación en Costa Rica que comparten cuadernos por correo o repositorios; mientras se actualiza, el propio aviso recomienda usar "Run Once" en vez de "Trust" al abrir un documento de origen externo, sin que se conozca un caso costarricense afectado al cierre de esta edición.
El GitHub Advisory Database revisó y actualizó, el 15 de octubre de 2026, el aviso GHSA-gfp8-w835-v44j (CVE-2026-62268, CVSS 4.0 de 5.3, severidad moderada) para borgbackup, la herramienta de código abierto de respaldo con deduplicación y cifrado más usada en línea de comandos sobre Linux y macOS. Según la descripción oficial, un archivo de respaldo manipulado puede incluir un enlace simbólico seguido de un elemento colocado debajo de él, o una ruta que contenga ".."; al extraerlo, Borg sigue el symlink o resuelve el segmento "..", lo que le permite escribir, sobrescribir o borrar archivos fuera del directorio de extracción previsto -un hardlink manipulado que apunte fuera de ese directorio produce el mismo efecto-. La falla, clasificada bajo CWE-59, la encontró primero Thomas Waldmann, mantenedor del proyecto, durante una revisión interna de seguridad de código asistida por IA, y la reportaron de forma independiente los investigadores Michael Head y Chinnapak Charoensiri. Las versiones corregidas son 1.4.5 y 2.0.0b22; la rama de mantenimiento 1.2.x recibió la corrección sin una nueva versión etiquetada. El propio aviso es explícito sobre los requisitos del ataque: explotarlo exige que el atacante ya tenga acceso al repositorio de respaldo y, si está cifrado, también la llave y la frase de paso de Borg -no un atacante remoto que simplemente extrae un archivo descargado de cualquier lado-. Ese alcance limita el radio de impacto práctico a escenarios donde el acceso al repositorio ya está comprometido o compartido con alguien que no debería tenerlo, el mismo límite de confianza que la propia documentación de Borg ya trataba como frontera de seguridad; la falla importa menos como un vector de ataque nuevo que como recordatorio de que la ruta de extracción de Borg confiaba en enlaces simbólicos y rutas relativas dentro del archivo más de lo que su propio modelo de amenazas asumía. La información de este caso proviene únicamente del aviso oficial del proyecto borgbackup y de GitHub, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. BorgBackup es una herramienta común entre administradores de sistemas y equipos de DevOps costarricenses que respaldan servidores Linux propios en vez de depender de un servicio administrado; esos equipos deberían confirmar que no comparten la frase de paso de un repositorio con nadie fuera de su control antes de aplicar la versión 1.4.5, sin que se conozca un caso costarricense afectado al cierre de esta edición.
— Un symlink o una ruta con puntos dobles dentro de un archivo de respaldo manipulado permite que Borg sobrescriba o borre archivos fuera del directorio de extracción, si el atacante ya tiene acceso al repositorio.
El GitHub Advisory Database revisó y actualizó, el 16 de octubre de 2026, dos avisos de severidad baja para herramientas de nicho en Python. El primero, GHSA-vqff-r82h-9crc (CVE-2026-76894, CVSS 3.1 de 3.1), afecta a @aborruso/ckan-mcp-server, un servidor de Protocolo de Contexto de Modelo que expone catálogos de datos abiertos de CKAN: su recurso de tabla interactiva se comunica con la ventana que lo aloja mediante postMessage, pero el listener de entrada no valida event.origin y los mensajes de salida usan '*' como destino, según la descripción oficial, lo que permite que cualquier marco capaz de alcanzar el documento inyecte filas falsas en la tabla o interfiera con el protocolo de inicialización de la interfaz. El propio aviso aclara que el impacto se limita a una suplantación visual -los valores ya vienen escapados en HTML, no hay scripting entre sitios- y que la gravedad real depende de cómo cada operador incruste el recurso; la corrección llegó en la versión 0.4.112. El segundo, GHSA-vgf9-9mxx-hq54 (CVE-2026-68549, CVSS 3.1 de 3.3), afecta a ClickMigrate: el nombre de migración que un usuario pasa al parámetro -m del comando revision puede escapar del directorio de migraciones previsto y crear un archivo .sql en cualquier ubicación donde el proceso tenga permisos de escritura, un riesgo que solo se materializa si un atacante controla ese nombre -por ejemplo, a través de una canalización de integración continua que reenvía datos sin validar-. La versión 1.0.3 corrige la falla. Ninguna de las dos fallas exige privilegios previos más allá de lograr que la víctima interactúe con el componente vulnerable, y ninguna reporta explotación activa conocida según sus propios avisos. Ambas comparten el mismo patrón de fondo que esta sección ya documentó esta semana en Appium y JavaCV: una pieza de software confía en una entrada -un origen de mensaje, un nombre de migración- sin validar que de verdad se mantiene dentro del límite que el propio diseño da por sentado. Que una de las dos fallas afecte justamente a un servidor del Protocolo de Contexto de Modelo -la capa que conecta modelos de lenguaje con fuentes de datos externas como CKAN- muestra que las mismas categorías clásicas de error web, validación de origen y escape de rutas, siguen apareciendo en la nueva generación de herramientas construidas alrededor de agentes de IA, aunque el error en sí no tenga nada de específico de inteligencia artificial. La información de estos dos casos proviene únicamente de los avisos oficiales de GitHub, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. Ambas son herramientas de nicho -un conector de datos abiertos y una utilidad de migraciones de base de datos-, sin adopción reportada públicamente entre empresas costarricenses; equipos locales que las usen deberían confirmar su versión en el próximo inventario de dependencias, sin que se conozca un caso costarricense afectado por ninguna de las dos.
La jornada del 17 de octubre combina, por primera vez en esta sección, el nombre de un creador de lenguajes y runtimes de JavaScript firmando una corrección directa en el motor de producción de Cloudflare con una nueva ronda de avisos de severidad moderada y baja en varias herramientas de nicho. Cloudflare publicó la versión v1.20261017.1 de workerd con la primera contribución de Ryan Dahl, creador de Node.js y Deno, apenas una semana después de que Cloudflare anunciara la incorporación de todo el equipo de Deno; la misma entrega actualiza el motor V8 a la versión 15.7. Appium corrigió un segundo Zip Slip basado en enlaces simbólicos que el parche de marzo contra la primera variante no alcanzó a cerrar, y JavaCV reparó un desbordamiento de enteros que puede congelar indefinidamente cualquier grabador de cámaras IP construido sobre su librería. JupyterLab cerró una condición de carrera que podía marcar como confiable un documento distinto al que el usuario intentó aprobar, y BorgBackup corrigió una vía de extracción que permitía escribir fuera del directorio de respaldo. GitHub, además, revisó avisos de severidad baja en el servidor MCP de CKAN y en la utilidad de migraciones ClickMigrate, y el rastreo comunitario de paquetes maliciosos sumó 19 entradas nuevas en npm y PyPI, encabezadas por una campaña de confusión de dependencias contra el dominio realwbx.com. Todas las historias completas, con sus fuentes primarias, quedan disponibles arriba para decidir qué parchar o revisar primero esta semana.