GitHub revive fallas críticas en el motor de plantillas Handlebars y en la librería de tokens fast-jwt que burlan arreglos previos, el conector de MariaDB para Node.js corrige cuatro fallas de inyección SQL, 44 paquetes maliciosos nuevos incluyen un falso Bitwarden y Python llega a la fecha que su propio calendario fijó para la versión 3.15 final.
GitHub publicó tres avisos de severidad crítica y moderada para Handlebars el 8 de octubre: la más grave burla tres arreglos que el proyecto ya había publicado en 2026 para variantes del mismo error.
El GitHub Advisory Database publicó, el 8 de octubre de 2026, tres avisos nuevos de seguridad para handlebars, el motor de plantillas de JavaScript usado en miles de proyectos Node.js: dos de severidad crítica -CVE-2026-106446 (GHSA-8r5x-fm3f-whwj, CVSS 9.8) y CVE-2026-106445 (GHSA-p8wg-vrv2-v86f)- y uno de severidad moderada, CVE-2026-106444 (GHSA-xw65-4hp5-5hc7), según la propia base de avisos. El más grave, CVE-2026-106446, ocurre porque Handlebars.compile() y Handlebars.precompile() aceptan árboles de sintaxis (AST) ya analizados además de cadenas de texto: la validación añadida en la versión 4.7.9 solo revisa algunos valores del árbol, así que el compilador sigue escribiendo otros valores sin verificar dentro del código JavaScript que genera. Quien pueda pasar un objeto no confiable -por ejemplo, el cuerpo de una solicitud HTTP ya convertido a JSON- puede inyectar JavaScript arbitrario, que se ejecuta en el servidor al usar compile() o donde se cargue el resultado al usar precompile(), según la descripción oficial del aviso. Las tres fallas afectan las versiones 4.0.0 a 4.7.9 y quedan corregidas en la 4.7.10. La falla crítica no es nueva del todo: el propio aviso reconoce que CVE-2026-106446 "bypasses the 4.7.9 fixes for GHSA-2w6w-674q-4c4q, GHSA-xhpv-hc6g-r9c6, and GHSA-3mfm-83xf-c92r", es decir, burla tres parches que Handlebars ya había publicado para cerrar variantes relacionadas del mismo problema. El propio texto del aviso también acota el riesgo real: "Applications that only ever pass template strings are not affected", lo que significa que la inmensa mayoría de proyectos que usan Handlebars de la forma documentada -compilando cadenas de texto, no árboles de sintaxis ya analizados- queda fuera del radio de impacto, pese al puntaje máximo de severidad. El hallazgo se acreditó a dieciséis investigadores distintos, entre ellos ndelphit, bhaswanthc y kagebunsher, según el crédito que figura en el propio aviso. La información de este caso proviene únicamente del GitHub Advisory Database, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. Equipos que construyan su propia interfaz de edición de plantillas, o que acepten árboles de sintaxis serializados desde el cliente, deberían actualizar a Handlebars 4.7.10 de inmediato. Handlebars es una dependencia común detrás de generadores de sitios estáticos y de correos transaccionales usados por agencias digitales y bancos costarricenses; no se conoce, al cierre de esta edición, un caso costarricense afectado por alguna de las tres fallas.
El GitHub Advisory Database actualizó, el 8 de octubre de 2026, el aviso GHSA-ww5h-9m49-7xx4 (CVE-2026-107722) para fast-jwt, la librería de tokens JWT mantenida por la firma NearForm: según la descripción oficial, el parche de julio para la falla original -CVE-2026-34950, de confusión entre los algoritmos RSA y HMAC- resultó incompleto. Aquel parche añadió una limpieza de espacios en blanco a la detección de bloques PEM, pero la revisión del encabezado sigue anclada al inicio exacto de la cadena: cualquier carácter previo -de control, de ancho cero, un comentario o un encabezado HTTP- hace que la llave pública RSA del servidor se trate, por error, como un secreto HMAC. Con eso, quien conozca la llave pública del servidor puede forjar tokens válidos mediante el ataque de confusión RS256-a-HS256, según documentaron los investigadores dc-infosec y EchoSkorJjj, acreditados en el propio aviso. La falla recibió un puntaje CVSS de 9.8 sobre 10 y queda corregida en la versión 6.3.0, publicada el mismo día. El puntaje máximo de severidad conviene matizarlo con el propio texto del aviso: "Verifiers with no algorithms allowlist, or one that includes HS256, are vulnerable. Setting algorithms: ['RS256'] protects against it", es decir, cualquier equipo que ya restrinja explícitamente el algoritmo de verificación a RS256 -una práctica recomendada desde hace años en la documentación de JWT- queda fuera del riesgo real sin necesidad de actualizar de inmediato. Es la segunda vez en tres meses que GitHub debe reabrir la misma vulnerabilidad de fast-jwt, un patrón que esta sección documentó esta semana también en Handlebars: un parche que cierra el caso de prueba reportado, pero no la clase completa del error. La información de este caso proviene del aviso oficial de GitHub, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. Quien use fast-jwt para verificar tokens sin fijar explícitamente el algoritmo esperado debería actualizar a la versión 6.3.0 y revisar su configuración de algorithms de inmediato. Fintechs y bancos costarricenses que emiten tokens JWT para sus APIs -una práctica común en la banca digital local- deberían confirmar si restringen el algoritmo de verificación antes de asumir que el riesgo los alcanza; no se conoce un caso costarricense afectado.
cat /feed/cloudflareworkersworkerd.md
Entre el 7 y el 9 de octubre, Cloudflare publicó tres versiones de workerd que miden el costo de cada aislado V8 y reportan asignaciones de memoria con mayor precisión.
> Cloudflare publicó, entre el 7 y el 9 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.20261007.1 (7 de octubre) añadió kj-rs-tokio, un entorno en el que el hilo principal de Rust pasa a controlar el bucle de eventos de KJ -la biblioteca interna de entrada y salida asíncrona de Cloudflare-, además de soporte para tipos RPC de solo lectura y más trazas de diagnóstico para Python Workers. La v1.20261008.1 (8 de octubre) corrigió un conteo de asignaciones de memoria de cppgc que se reportaba a V8 fuera de su ventana sin recolección de basura, y contuvo excepciones que antes escapaban al liberar objetos durante esa recolección. La v1.20261009.1 (9 de octubre) agregó observadores para atribuir el costo de cómputo a cada aislado de V8 por separado, histogramas de V8, un nuevo tramo de diagnóstico ("fetch_setup") y una canalización de instantáneas de arranque ("startup snapshot"), según el changelog oficial.
> Son la novena, décima y undécima entrega que esta sección documenta en la racha casi diaria de workerd desde finales de setiembre -la anterior, del 6 de octubre, prohibió por defecto el código Rust sin verificar en cada crate del proyecto-. La atribución de costo por aislado y la canalización de instantáneas de arranque apuntan a un mismo objetivo: que Cloudflare pueda medir y acelerar el arranque en frío de cada función que corre sobre Workers, el cuello de botella más citado del cómputo serverless frente a los contenedores tradicionales.
> 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 las instantáneas de arranque.
El GitHub Advisory Database publicó, el 8 de octubre de 2026, cuatro avisos de seguridad para mariadb, el conector oficial de Node.js para bases de datos MariaDB, según el propio registro. Tres son de severidad alta: CVE-2026-107385 (GHSA-r3rv-jm3r-62q2, CVSS 7.4) permite inyección SQL cuando el modo de sesión NO_BACKSLASH_ESCAPES está activo, porque el escape de comillas del conector siempre usa barra invertida sin revisar ese modo, lo que cierra el literal de cadena antes de lo previsto; CVE-2026-107384 (GHSA-v6pj-gxxw-phfw) permite una inyección similar a través de las llaves de un objeto usado para expandir cláusulas SET; y CVE-2026-107383 (GHSA-48qf-xh34-q73r) expone memoria sin inicializar cuando el conector recibe un objeto GeoJSON malformado. El cuarto, CVE-2026-107382 (GHSA-cx2f-j9fh-8g68), de severidad moderada, provoca una caída del proceso durante la autenticación ed25519 con configuraciones TLS sin parámetros explícitos. Las cuatro quedan corregidas en las versiones de parche 3.2.5, 3.3.4, 3.4.7 y 3.5.4, según la rama de cada caso. El propio aviso de la falla más grave acota su alcance real: "execute() and batch() are not affected because they send parameters separately", es decir, solo queda expuesto el método de escape de texto plano (escape()) de versiones antiguas del conector, no las dos formas de consulta parametrizada que la documentación de MariaDB recomienda desde hace años para evitar justamente este tipo de falla. La exposición, además, depende de que el modo NO_BACKSLASH_ESCAPES esté activo -a nivel de servidor, de sesión del conector o mediante un SET sql_mode de la propia aplicación-, una configuración minoritaria frente al modo por defecto de MariaDB. La información de este caso proviene del GitHub Advisory Database, sin cobertura cruzada de un medio especializado al cierre de esta edición. Equipos que usen Connection.escape() directamente sobre MariaDB, en lugar de consultas parametrizadas, deberían migrar a execute() o batch() mientras actualizan a la versión de parche correspondiente. Bancos y empresas de zona franca costarricenses que corren bases de datos MariaDB en producción deberían revisar si su capa de acceso a datos todavía depende del método escape() heredado; no se conoce un caso costarricense afectado al cierre de esta edición.
El proyecto de código abierto compromised-packages-check registró, en su barrido del 8 al 9 de octubre de 2026 (PR 152), 44 entradas nuevas de paquetes maliciosos -42 en npm y 2 en PyPI-, según el registro público del proyecto en GitHub. El hallazgo más llamativo es un par de paquetes, @bitwardne/cli 1.0.1 y @bitwardne/jslib 1.1.0, que imitan por un solo carácter el nombre del gestor de contraseñas Bitwarden (identificados como MAL-2026-17693 y MAL-2026-17694). El lote incluye además un clúster de trece paquetes que imitan a Baileys, la librería no oficial más usada para automatizar WhatsApp desde Node.js -entre ellos bails, xbailey, xbails y @itsmee_aizat.id/baileys-, seis paquetes de un "dropper" de CSS disfrazado de utilidades de Tailwind, y dos paquetes de PyPI, kafka-helmsman y kafka-roller, que explotan la técnica de confusión de dependencias contra un paquete interno de Kafka. Entre las entradas misceláneas aparece también @design-system-coopeuch/web, un ataque de confusión de dependencias que usa el nombre de Coopeuch, la cooperativa financiera chilena, según el mismo registro. La cifra de hoy -44- queda por debajo de los dos lotes anteriores de esta semana (59 el 5 y el 6 de octubre, 29 el 8), pero mantiene el mismo patrón de fondo que esta sección documenta desde el 1° de octubre: typosquats de un carácter contra herramientas de uso diario -antes Angular y Hardhat, hoy Bitwarden- y ataques de confusión de dependencias contra espacios de nombres corporativos específicos, como el de Coopeuch hoy. Que el objetivo cambie de semana a semana, sin repetir el mismo nombre dos veces, sugiere un rastrillado amplio y automatizado del registro de npm antes que una campaña dirigida a un solo proyecto. 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. Costa Rica tiene una comunidad amplia de programadores que instalan paquetes de npm y PyPI a diario en zonas francas y startups, varios de los cuales usan Bitwarden como gestor de contraseñas corporativo; revisar el nombre exacto de cualquier paquete relacionado -@bitwarden, no @bitwardne- sigue siendo la defensa más simple disponible, sin que se conozca un caso costarricense afectado por este lote.
— El proyecto compromised-packages-check documentó 44 paquetes maliciosos nuevos entre el 8 y el 9 de octubre, incluidos dos que imitan a Bitwarden y trece dirigidos a usuarios de la librería Baileys para WhatsApp.
El equipo de lanzamiento de Python fijó el 9 de octubre, hoy, como fecha de la versión 3.15.0 final tras publicar una tercera candidata el 2 de octubre.
El equipo de lanzamiento de Python, liderado por Hugo van Kemenade, fijó el 9 de octubre de 2026 como fecha de la versión estable 3.15.0, después de que bloqueos de última hora en la función de importación diferida (PEP 810) obligaran a publicar una tercera candidata, 3.15.0rc3, el 2 de octubre, con 156 correcciones aportadas por 82 personas desde la rc2, según el propio anuncio de esa candidata. La fecha original, fijada por el calendario oficial del proyecto (PEP 790), era el 1° de octubre; la rc3 la movió ocho días. Según una revisión de esta sección a los canales públicos de información sobre el proyecto, no fue posible confirmar al cierre de esta edición si la versión 3.15.0 final ya salió; la última entrada verificable sigue siendo la propia rc3. Entre las novedades que trae 3.15, según el anuncio de la candidata rc2, destacan el tipo incorporado frozendict (PEP 814), el tipo sentinel (PEP 661) y el propio sistema de importación diferida explícita del PEP 810, pensado para acelerar el arranque de programas grandes -la misma función cuyos errores de última hora forzaron el retraso. Esta sección documentó, el 5 y el 6 de octubre, el mismo patrón: la fecha oficial se movía sin que el proyecto publicara una explicación pública adicional más allá del anuncio de cada candidata. Que la fecha fijada por la propia rc3 finalmente llegue hoy cierra, de una forma u otra, un arco de nueve días de atraso acumulado sobre el calendario original del PEP 790. Equipos que planificaban migrar a Python 3.15 este mes deberían confirmar en la página oficial de descargas si la versión estable ya está disponible antes de actualizar entornos de producción. Costa Rica tiene una comunidad amplia de programadores Python en ciencia de datos, automatización y educación, concentrada en zonas francas y universidades, que sigue, como el resto del mundo, pendiente de la versión final; no se conoce un calendario de adopción local distinto al del resto del ecosistema.
La jornada repite un patrón que esta sección viene siguiendo desde el 5 de octubre: parches que cierran el caso reportado pero no la clase completa de error. Handlebars sumó dos CVE críticos que burlan tres arreglos previos de 2026, y fast-jwt necesitó un segundo intento para cerrar la misma confusión de algoritmos RSA-HMAC que decía haber resuelto en julio. El conector de MariaDB para Node.js corrigió cuatro fallas de inyección SQL y memoria, aunque limitadas a configuraciones específicas, y Cloudflare sumó tres versiones de workerd con nuevas métricas de costo por aislado. El rastreo comunitario de paquetes maliciosos halló 44 entradas nuevas en npm y PyPI, encabezadas por un typosquat de Bitwarden. Python, mientras tanto, llegó a la fecha que su propio calendario había fijado para la versión 3.15.0 final, sin que esta sección pudiera confirmar al cierre si la versión ya salió. Todas las historias completas, con sus fuentes primarias, quedan disponibles arriba para decidir qué actualizar o parchar primero esta semana.