El plazo que CISA fijó para parchar la falla crítica de GitLab llegó hoy sin cifras de cumplimiento; Cloudflare actualizó su CLI de Workers mientras workerd extendió su racha a 34 días; y avisos de seguridad en PyPI y npm documentaron nuevas campañas de paquetes maliciosos en la cadena de suministro de código abierto.
CISA fijó el 14 de setiembre como fecha límite federal el 11 de setiembre, tras confirmar explotación activa; GitLab y CISA no han publicado cifras de cumplimiento al cierre de esta edición.
El plazo que la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) fijó el 11 de setiembre de 2026 para que las agencias civiles federales parcharan la falla crítica de GitLab, CVE-2026-85706, vence hoy 14 de setiembre sin que CISA ni GitLab hayan publicado cifras propias de cumplimiento al cierre de esta edición. La falla, una vulnerabilidad de recorrido de rutas (CWE-22) en la API de commits del repositorio con la puntuación máxima de severidad —CVSS 10.0—, permite a un atacante sin autenticar leer cualquier archivo accesible para la cuenta de servicio de GitLab mediante una sola solicitud HTTP POST, según la firma de seguridad watchTowr, que detectó sondeos activos desde las 06:00 UTC del 11 de setiembre, aproximadamente 20 horas después de que GitLab liberara el parche el 10 de setiembre. SecurityWeek y watchTowr siguen calculando en más de 20.000 las instancias autoalojadas de GitLab que continúan expuestas en todo el mundo, una cifra que no varió respecto a la reportada esta semana. El mandato de CISA solo obliga legalmente a las agencias civiles federales de Estados Unidos: de esas más de 20.000 instancias, la gran mayoría —bancos, universidades y empresas privadas fuera de la administración federal— no enfrenta ninguna obligación legal de cumplir el plazo de hoy, solo el mismo riesgo técnico que enfrentan las agencias sí obligadas. CISA marcó además el caso bajo la Directiva Operacional Vinculante 26-04, que exige a las agencias afectadas una revisión forense antes de dar el caso por cerrado, precisamente porque un servidor pudo haber sido leído por un atacante entre el 10 y el 14 de setiembre sin que el parche de hoy borre esa exposición previa. Ni CISA ni GitLab han confirmado si las agencias federales cumplieron el plazo al cierre de esta edición, y CISA tampoco ha vinculado la falla a una campaña de ransomware específica hasta ahora. Costa Rica no tiene agencias sujetas al mandato de CISA, pero bancos y empresas de zonas francas tecnológicas que administran GitLab autoalojado comparten el mismo riesgo técnico sin fecha límite legal; watchTowr recomienda revisar los registros de acceso en busca de solicitudes POST hacia /api/v4/projects/{id}/repository/commits/ con el parámetro file.path, la firma concreta del intento de explotación.
cat /feed/devopscloudflareworkers.md
La CLI de Cloudflare Workers suma suscripción a eventos de Workflows en desarrollo local y corrige una regresión de recarga lenta en Vite, mientras workerd extiende su racha diaria a 34 entregas.
> Cloudflare publicó, el 14 de setiembre de 2026, la versión 4.131.2 de Wrangler, la CLI de despliegue de Workers, que actualiza su dependencia de miniflare a v5.20260911.1-alpha, según el registro oficial de versiones del proyecto en GitHub. La misma jornada, el equipo liberó @cloudflare/workflows-shared en su versión 0.14.0, que suma un nuevo método subscribe() con suscripciones RPC desechables a eventos de ciclo de vida de Workflows —históricos y en vivo— en desarrollo local, con soporte para cursores de eventos y filtros por tipo que cubren entradas, transiciones de estado, pasos, salidas, errores, reintentos, esperas y reversiones. @cloudflare/vite-plugin llegó a la versión 1.54.9 con una corrección de rendimiento: el complemento ahora ignora las escrituras del directorio .wrangler/state en el vigilante de archivos de Vite, lo que evitaba que el gancho hotUpdate se disparara en exceso en Linux y Windows y provocara recargas lentas durante el desarrollo.
> En paralelo, Cloudflare publicó a la 01:13 UTC de hoy la versión v1.20260914.1 de workerd, el motor de ejecución de Workers, la trigésimo cuarta entrega consecutiva de su racha diaria sostenida desde el 12 de agosto. A diferencia de la entrega de ayer, que sumó un cambio de arquitectura en el puerto de eventos del motor, la comparación oficial entre ambas versiones en GitHub muestra un solo cambio hoy: una confirmación titulada "Release 2026-09-14" sin modificaciones de código visibles. La sustancia técnica del día se movió hacia las herramientas del Workers SDK —Wrangler y el plugin de Vite— y no hacia el motor de ejecución en sí, lo que confirma que la racha diaria de workerd es un hábito de cadencia de publicación y no garantía de trabajo de función nuevo cada día.
> Cloudflare no ha anunciado fecha para sacar de fase alfa la suscripción a eventos de Workflows, según su registro de cambios. Equipos costarricenses que desarrollan sitios Jamstack con Vite sobre Cloudflare Pages o Workers —un stack común entre agencias digitales locales— se benefician directamente de la corrección del vigilante de archivos, dado que la recarga lenta en máquinas de desarrollo con Linux o Windows era una queja recurrente entre usuarios del plugin.
El catálogo de avisos de seguridad de GitHub, con datos de OpenSSF (Open Source Security Foundation) y del investigador independiente kam193, publicó el 13 de setiembre de 2026 el aviso GHSA-qp4x-pg53-7xh8 sobre chroma-client 0.5.7, un paquete de PyPI que imita el nombre del cliente oficial de la base de datos vectorial ChromaDB. Según el aviso, el paquete forma parte de la campaña identificada como "2026-09-openaii" y "usa exactamente la misma técnica que otros paquetes de la campaña, orientada a engañar a las herramientas de seguridad basadas en LLM"; sus funciones incluyen descarga y ejecución remota de scripts, ofuscación de código, robo de credenciales y llaves SSH, minería de criptomonedas y mecanismos de persistencia. Un día antes, el 12 de setiembre, GitHub publicó otros dos avisos de la misma fuente: platform-telemetry-client 1.0.0 (GHSA-7767-763c-fxp3), que instala un archivo .pth activado en cada inicio del intérprete de Python para intentar descargar una segunda carga útil almacenada en fragmentos dentro de registros DNS —el dominio de mando y control no respondía al momento del análisis—, y python-fork 0.1.0/0.1.1 (GHSA-v8v2-jgrm-w335), cuya sola importación desata una fork bomb capaz de desestabilizar el sistema. El nombre de la campaña de chroma-client remite a una oleada más amplia de paquetes con nombres que imitan bibliotecas populares de inteligencia artificial —openaii, transfomers, langgrap, ollamaa, entre otros catalogados desde el 11 de setiembre—, diseñados según el propio aviso para pasar inadvertidos frente a escáneres de seguridad que usan modelos de lenguaje para evaluar dependencias. Eso convierte en blanco directo a los equipos que delegan la revisión de paquetes únicamente en herramientas automatizadas basadas en IA, sin verificación humana del nombre exacto del paquete. Ninguno de los tres avisos reporta versión corregida ni cifras de descargas o víctimas confirmadas al cierre de esta edición; la recomendación de OpenSSF es desinstalar de inmediato cualquiera de los tres. Costa Rica tiene una comunidad creciente de bootcamps y startups de ciencia de datos que instalan paquetes de Python para proyectos de IA; verificar el nombre exacto de la dependencia —chromadb y no chroma-client, openai y no openaii— sigue siendo la defensa más simple, sin que se conozca impacto local concreto de esta campaña específica.
El catálogo de avisos de seguridad de GitHub marcó, el 13 de setiembre de 2026, al menos ocho paquetes de npm —joko-klanting55-breki, joko-klanting72-miaww, joko-klanting70-riris, joko-klanting57-breki, joko-ketoprak70-breki, joko-klanting28-sluey, joko-keripik64-sluey y joko-keripik88-riris— como código malicioso, identificados mediante el análisis de Amazon Inspector y catalogados por OpenSSF. Según las fichas de cada aviso, los paquetes contienen scripts de autopublicación que modifican el package.json para remover las banderas "private", cambian los números de versión y generan nombres aleatorios de temática indonesia, republicando variantes de forma continua para inundar el registro de npm con paquetes derivados. El objetivo, de acuerdo con la misma fuente, es inflar artificialmente las métricas de reputación y actividad de publicación que el protocolo tea —conocido como tea.xyz— usa para repartir recompensas en su token entre mantenedores de paquetes de código abierto. La técnica no instala cargas maliciosas activas como robo de credenciales, a diferencia de los casos de PyPI documentados en paralelo esta semana, pero degrada la confiabilidad del registro público: cada paquete falso que aparece en búsquedas o listados de dependencias populares complica el trabajo de quienes auditan cadenas de suministro de software y multiplica el ruido que los equipos de seguridad deben filtrar a diario. GitHub no ha publicado un conteo total de paquetes vinculados a esta campaña ni identificado a la cuenta o cuentas detrás de la publicación, más allá de los ocho avisos individuales confirmados al cierre de esta edición. Equipos de desarrollo en Costa Rica que usan npm como registro por defecto no enfrentan impacto directo conocido —estos paquetes no tienen dependientes activos identificados—, pero la campaña es un recordatorio de que revisar el conteo de descargas y la fecha de publicación de una dependencia nueva antes de instalarla sigue siendo la defensa más simple contra este tipo de contaminación de registro.
La base de datos de avisos de RustSec asignó, el 14 de setiembre de 2026, el identificador RUSTSEC-2026-0284 al crate lockfree (versiones 0.5.1 e inferiores) del ecosistema de Rust, tras confirmar dos fallas de solidez de memoria independientes. La primera es un doble liberado (double free) en Map::into_iter: si el método drop de un tipo provisto por quien usa la librería entra en pánico, la llamada mem::forget(self) se salta, y el mecanismo de destrucción del Map libera la misma estructura interna por segunda vez durante el desenrollado de la pila. La segunda escribe memoria sin inicializar en el campo interno de SharedIncin::clear antes de completar su inicialización, un comportamiento indefinido que afecta a cinco estructuras del crate —colas, pilas, mapas y dos variantes de canal, spmc y mpmc—, según el texto del aviso. lockfree no recibe una actualización desde noviembre de 2018 y su mantenedor no respondió al reporte, de acuerdo con RustSec, que no lista versión corregida ni fecha prevista para una. El caso ilustra un riesgo estructural que ningún lenguaje evita por diseño: una dependencia transitiva puede llevar ocho años sin revisión y seguir compilando sin advertencias dentro de un Cargo.lock, hasta que una auditoría de solidez de memoria —no una vulnerabilidad explotada activamente, sino un defecto latente— la saca a la luz. RustSec no recomienda una alternativa concreta en el aviso, y la información de esta nota proviene únicamente de la base de datos de avisos de RustSec, sin cobertura de prensa especializada ni comunicado del mantenedor al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Rust, pero equipos locales de fintech y sistemas embebidos que usan el lenguaje para código concurrente deberían correr cargo-audit contra su Cargo.lock para confirmar si lockfree aparece como dependencia transitiva, en lugar de asumir que un crate sin fallas reportadas en años está libre de riesgo.
— El aviso RUSTSEC-2026-0284, publicado hoy, describe un doble liberado en el iterador del mapa y un Arc sin inicializar en cinco estructuras del crate, que no recibe actualizaciones desde noviembre de 2018.
La jornada del 14 de setiembre de 2026 en desarrollo estuvo marcada por el vencimiento del plazo que CISA fijó para parchar la falla crítica de GitLab, CVE-2026-85706, sin que la agencia ni GitLab hayan publicado cifras de cumplimiento y con más de 20.000 instancias autoalojadas todavía expuestas según SecurityWeek y watchTowr. Cloudflare, por su parte, actualizó las herramientas de Workers —Wrangler 4.131.2 y el plugin de Vite— con correcciones concretas, mientras su motor workerd extendió a 34 días una racha diaria que hoy fue puramente de mantenimiento. En cadena de suministro de código abierto, GitHub y OpenSSF documentaron dos campañas separadas en menos de 48 horas: tres paquetes maliciosos en PyPI que imitan nombres de bibliotecas de inteligencia artificial para evadir escáneres basados en LLM, y ocho paquetes de npm diseñados para farmear recompensas del token del protocolo tea. RustSec cerró el día con un aviso propio: dos fallas de memoria sin parchar en un crate de Rust abandonado desde 2018. El hilo que conecta la edición es la brecha entre el aviso y la verificación: GitLab sigue sin cifras de cumplimiento pese al plazo cumplido, y los registros de paquetes de PyPI y npm siguen dependiendo de que alguien, humano o automatizado, note el nombre equivocado antes de instalar. Todas las historias completas, con sus fuentes primarias, quedan disponibles arriba para decidir qué revisar primero esta semana.