watchTowr confirmó robo de archivos de configuración y llaves SSH en servidores GitLab vulnerables durante el fin de semana, sin que CISA ni GitLab hayan publicado cifras de cumplimiento del plazo que venció ayer; OpenSSF documentó una nueva campaña de paquetes maliciosos en npm que roba datos del portapapeles y credenciales de n8n; ZITADEL corrigió dos fallas de control de acceso, una de severidad alta; RustSec marcó una falla de bajo impacto en rustls; y Cloudflare workerd extendió a 35 días su racha de lanzamientos diarios.
La firma watchTowr documentó que la explotación de la falla CVSS 10.0 escaló de sondeos a exfiltración real de archivos de configuración y llaves SSH durante el fin de semana previo al plazo de CISA.
La firma de gestión de superficie de ataque watchTowr actualizó, el 15 de setiembre de 2026, su análisis de la falla crítica de GitLab CVE-2026-85706 (CVSS 10.0) para confirmar que la explotación escaló de sondeos automatizados a robo efectivo de datos: durante el fin de semana del 12 y 13 de setiembre, atacantes extrajeron archivos de configuración con secretos y las configuraciones SSH completas de instancias autoalojadas vulnerables, según reportó Cyber Daily con base en el aviso actualizado de la firma. La escalada —de identificar servidores expuestos a exfiltrar archivos reales— ocurrió antes de que venciera, el 14 de setiembre, el plazo que la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) había fijado a las agencias civiles federales para aplicar el parche que GitLab liberó el 10 de setiembre. Ni CISA ni GitLab han publicado cifras de cumplimiento del plazo del 14 de setiembre al cierre de esta edición, la misma laguna de información que esta sección reportó ayer; la diferencia es que ahora existe evidencia concreta de daño, no solo de riesgo. CISA, además, no limitó su actividad de esta semana a GitLab: el catálogo de Vulnerabilidades Explotadas Conocidas (KEV) sumó también dos fallas de JFrog Artifactory (CVE-2026-42016 y CVE-2026-42018) y una de ConnectWise ScreenConnect (CVE-2026-84869, CVSS 9.9), con plazos de cumplimiento entre el 13 y el 25 de setiembre, según The Hacker News —una señal de que la agencia enfrenta simultáneamente varios frentes de explotación activa contra herramientas de infraestructura de desarrollo, no un caso aislado de GitLab. watchTowr recomienda a cualquier organización con GitLab autoalojado tratar el incidente como una posible vulneración ya consumada —rotar credenciales, revisar llaves SSH y auditar accesos— en lugar de asumir que instalar el parche cierra el caso. Costa Rica no tiene agencias sujetas al mandato de CISA, pero bancos y empresas de zonas francas tecnológicas que administran GitLab autoalojado enfrentan el mismo riesgo técnico sin ninguna fecha límite legal que las obligue siquiera a reportar si ya fueron comprometidas.
El catálogo de avisos de seguridad de GitHub, con datos del proyecto de paquetes maliciosos de OpenSSF (Open Source Security Foundation), documentó el 15 de setiembre de 2026 al menos nueve paquetes de npm ligados a una misma cuenta identificada como biz44 —entre ellos @biz44/runtime-utils, @biz44/process-runtime-utils y una serie con nombres como @biz44/id79-client, @biz44/id10-client e @biz44/id99-client—, catalogados bajo avisos como GHSA-fc79-g66m-pjph. Según el texto, el paquete lanza al importarse un cargador de JavaScript independiente que descarga y ejecuta código adicional desde npoint.io, capaz de comunicarse con servidores de comando y control, capturar el contenido del portapapeles, registrar eventos de teclado y mouse, examinar el sistema de archivos y robar los datos almacenados por extensiones de Chrome. Ninguna de las versiones afectadas —1.1.11, 1.1.13, 1.1.81, 1.1.96 y 1.1.100— tiene corrección disponible, porque el paquete es malicioso desde su publicación. Un día antes, el 14 de setiembre, GitHub publicó el aviso GHSA-mfvv-xhj7-524c sobre n8n-nodes-sysdiag, un paquete que se presenta como nodo de diagnóstico de salud para n8n —la herramienta de automatización de flujos de trabajo de código abierto— pero que en realidad enumera las variables de entorno del sistema al ser importado, busca patrones de llaves de cifrado de n8n, contraseñas de base de datos y credenciales de Redis, y envía esos valores codificados en base64 a la dirección 121.127.33.228 disfrazando el tráfico como "telemetría" y "verificación de compatibilidad de versión", según el propio aviso. El 15 de setiembre, GitHub catalogó una segunda versión del mismo paquete, n8n-nodes-sysdiag2, con el aviso GHSA-mx46-3mx3-r66x y el mismo patrón de comportamiento malicioso detectado por el proyecto de análisis de paquetes de OpenSSF. Ninguno de los avisos reporta cifras de descargas ni víctimas confirmadas al cierre de esta edición, y ambas campañas siguen el mismo patrón que esta sección documentó ayer con chroma-client en PyPI y los ocho paquetes de la granja de recompensas de tea.xyz en npm: nombres que imitan herramientas legítimas —un nodo de n8n, utilidades de runtime— para pasar inadvertidos en instalaciones automatizadas. Equipos costarricenses que usan n8n para automatizar flujos internos, una herramienta de adopción creciente entre agencias digitales y startups locales por su modelo de autoalojamiento, deberían revisar el listado de nodos comunitarios instalados antes de confiar en cualquiera que prometa diagnóstico o telemetría, en lugar de asumir que el ecosistema npm filtra paquetes maliciosos antes de la publicación.
La base de datos de avisos de RustSec asignó, el 14 de setiembre de 2026, el identificador RUSTSEC-2026-0285 a rustls, la biblioteca de TLS más usada del ecosistema Rust, tras confirmar que las versiones 0.23.13 a 0.23.44 aceptaban mensajes de protocolo de TLS 1.3 en el nivel de cifrado equivocado cuando llegaban empacados en el mismo registro que un mensaje de cambio de llaves —por ejemplo, un ServerHello seguido, sin cifrar, de un EncryptedExtensions que debía ir cifrado—, según el aviso GHSA-2mjx-qc3c-rqvc de GitHub. La falla, reportada por el investigador identificado como randombit mediante una nueva suite de pruebas de TLS y DTLS, viola el requisito de la sección 5.1 del estándar RFC 8446, que exige que los mensajes de protocolo nunca crucen un cambio de llaves. La corrección llegó en la versión 0.23.45. El propio aviso limita el alcance real del problema, y ahí está el matiz que distingue esta falla de las demás de la edición de hoy: como la transcripción completa del protocolo de enlace sigue autenticada criptográficamente, un atacante en la ruta de red puede inyectar mensajes fuera de orden, pero no puede alterar el contenido de la sesión ni completar una conexión falsa, según GitHub. RustSec y GitHub incluso discrepan en la puntuación exacta —3.1 en la base de RustSec, 5.3 en el aviso de GitHub—, ambas dentro del rango bajo a moderado, muy lejos del CVSS 10.0 de la falla de GitLab que domina la edición de hoy. El caso es equivalente al identificado como GO-2026-4340 en la biblioteca TLS de Go (CVE-2025-61730); implementaciones como Botan, OpenSSL, BoringSSL y wolfSSL ya rechazaban correctamente este patrón, según el aviso, lo que sugiere que el ecosistema Rust llegó tarde a una comprobación que otros stacks de TLS ya tenían resuelta. RustSec no reporta explotación activa ni prueba de concepto pública al cierre de esta edición. rustls es la dependencia de TLS detrás de gran parte del ecosistema asíncrono de Rust —tokio, reqwest y hyper la usan como opción por defecto o alternativa a OpenSSL—, así que conviene aplicar la corrección en el próximo ciclo de dependencias aunque no haya urgencia de parche de emergencia. Equipos costarricenses de fintech y sistemas embebidos que ya revisaron su Cargo.lock por el aviso de lockfree de ayer pueden aprovechar la misma auditoría para confirmar la versión de rustls, sin que exista evidencia de explotación que justifique una alerta mayor.
— El aviso RUSTSEC-2026-0285, publicado ayer, señala que rustls aceptaba mensajes de protocolo en el nivel de cifrado equivocado, aunque el propio hallazgo aclara que la sesión queda autenticada y nadie puede alterarla.
El catálogo de avisos de seguridad de GitHub publicó, el 14 de setiembre de 2026, dos fallas independientes en ZITADEL, la plataforma de identidad y gestión de accesos de código abierto escrita en Go. La primera, CVE-2026-56668 (GHSA-vrh8-c9cm-wh8v, CVSS 8.1, CWE-862 de autorización faltante), está en el punto de intercambio de tokens de OAuth2: el sistema no valida si el token de acceso entrante pertenece o está autorizado para la aplicación que inicia el intercambio, ni aplica límites de alcance (scope), según el aviso. Eso permite a un usuario autenticado con acceso legítimo pero de bajo privilegio en una aplicación obtener tokens de administrador para otra aplicación distinta del mismo entorno, un riesgo mayor en clientes públicos que no requieren autenticación adicional. La falla afecta las versiones 4.0.0 a 4.15.2 y toda la rama 3.x, y se corrige en la 4.15.3. La segunda, CVE-2026-76081 (GHSA-v859-c572-qh5p, CVSS 5.5), es un error de iteración en la lógica que procesa el borrado de roles de proyecto: según el aviso, eliminar dos o más roles a la vez "podría" hacer que el sistema saltara alguno sin revocarlo, un problema limitado a los permisos de usuario en Proyectos Compartidos entre organizaciones. Afecta las mismas versiones que la falla de tokens y se corrige en la 4.16.0, que incluye una migración automática de base de datos para detectar y corregir los permisos huérfanos que haya dejado el error. Ambas fallas son errores de lógica de autorización, no de memoria —el mismo tipo de defecto que RustSec documentó hoy en rustls, aunque con consecuencias potenciales más serias porque tocan directamente el mecanismo de confianza entre aplicaciones. GitHub no reporta explotación activa confirmada de ninguna de las dos fallas al cierre de esta edición; los créditos de descubrimiento van para AyushParkara, IAM-marco y livio-a en el caso de los roles, y para thesecguy45, cipher-creator y wim07101993 en el caso del intercambio de tokens. ZITADEL se promociona como alternativa autoalojada a servicios de identidad como Auth0 u Okta, una opción que bancos y fintechs costarricenses interesados en mantener el control de sus datos de autenticación podrían evaluar; no hay registro de adopción local conocida de la plataforma, así que el impacto directo en Costa Rica es indeterminado al cierre de esta edición.
cat /feed/devopscloudflareworkers.md
La versión v1.20260915.1, publicada esta madrugada, expone la IP y el puerto del cliente en el manejador TCP connect(), mientras Wrangler sostiene las herramientas de Workflows publicadas ayer.
> Cloudflare publicó, el 15 de setiembre de 2026, la versión v1.20260915.1 de workerd, el motor de ejecución de Cloudflare Workers, la trigésimo quinta entrega consecutiva de la racha diaria sostenida desde el 12 de agosto, según el registro oficial de versiones del proyecto en GitHub. La entrega suma la capacidad de exponer la dirección IP y el puerto del cliente como remoteAddress dentro del manejador connect() del módulo de redes TCP, además de ajustes internos de compilación, parches para el soporte de Python en Workers y una refactorización del sistema de envoltura de tipos JSG (JSG TypeWrapper). Siete personas contribuyeron a la entrega, entre ellas ThomasRubini, quien aparece por primera vez en el registro de cambios del proyecto.
> La entrega de hoy contrasta con la de ayer, que el propio registro de GitHub describió como una confirmación titulada "Release 2026-09-14" sin cambios de código visibles: remoteAddress es una función que los scripts de Workers pueden usar de inmediato para lógica de bloqueo, registro o enrutamiento basada en la IP real del cliente en conexiones TCP, algo que antes requería depender de encabezados HTTP como CF-Connecting-IP y que ahora está disponible también fuera del contexto HTTP. Cloudflare no ha explicado públicamente por qué sostiene una cadencia de publicación diaria de workerd desde hace 35 días, ni si es una política deliberada de entrega continua o simplemente el resultado de un volumen constante de cambios internos.
> La suscripción a eventos de Workflows que Cloudflare presentó ayer sigue marcada como experimental, sin fecha de graduación a estable, según el registro de cambios. Empresas costarricenses de zonas francas tecnológicas y agencias digitales que despliegan sobre Cloudflare Workers o Pages —un stack común para comercio electrónico y portales de servicios en el país— pueden adoptar remoteAddress para reglas de geolocalización o control de acceso a nivel de conexión sin necesidad de reescribir su lógica basada en encabezados HTTP existente.
La jornada del 15 de setiembre de 2026 en desarrollo estuvo marcada por la confirmación de watchTowr de que la explotación de la falla crítica de GitLab, CVE-2026-85706, escaló durante el fin de semana a robo efectivo de archivos de configuración y llaves SSH, sin que CISA ni GitLab hayan publicado cifras de cumplimiento del plazo que venció ayer. La misma semana, CISA sumó a su catálogo KEV fallas de JFrog Artifactory y ConnectWise ScreenConnect, ampliando el frente de explotación activa más allá de GitLab. En cadena de suministro de código abierto, OpenSSF documentó dos campañas nuevas en npm: un infostealer ligado a la cuenta biz44 que roba portapapeles y datos de Chrome, y dos versiones de un nodo falso de n8n que exfiltran llaves de cifrado y credenciales de bases de datos. En herramientas de desarrollo, ZITADEL corrigió una falla de intercambio de tokens OAuth2 de severidad alta y un error de roles sin revocar, RustSec marcó una falla de bajo impacto en rustls con matices que la propia base de datos se encargó de aclarar, y Cloudflare workerd extendió a 35 días su racha de lanzamientos diarios con una función nueva de direccionamiento TCP. El hilo que conecta la edición es la distancia entre el aviso y la certeza: GitLab pasó de sospecha de riesgo a exfiltración confirmada, mientras rustls y ZITADEL muestran que no toda falla publicada implica el mismo nivel de urgencia. Todas las historias completas, con sus fuentes primarias, quedan disponibles arriba para decidir qué revisar primero esta semana.