Un parche crítico deja sin soporte a GitLab 19.2, PostgreSQL empuja su versión 19 a noviembre, una falla de containerd con nota CVSS 9.4 expone contenedores y Docker, un ataque de julio a npm reabre la duda sobre sus controles de seguridad, y GitHub prepara Copilot CLI para su conferencia Universe.
El cierre de la rama llegó seis semanas después de que el proyecto corrigiera una falla de recorrido de rutas en su API de commits, calificada de crítica por la firma surcoreana AhnLab.
GitLab publicó el 10 de setiembre los parches 19.3.2, 19.2.6 y 19.1.8 para sus ramas de código abierto y empresarial, según la página oficial de lanzamientos de GitLab Docs. El boletín de seguridad que acompañó esos parches, revisado por la firma surcoreana AhnLab ASEC, corrige CVE-2026-85706, una falla de recorrido de rutas en la API de commits del repositorio que permitía leer archivos fuera del directorio esperado. Ese parche fue, a la vez, el último que la rama 19.2 recibió: el rastreador externo isitpatched.com —que no es una fuente oficial de GitLab— registra el 20 de octubre como la fecha en que esa versión quedó sin soporte de seguridad, en línea con la política de respaldo de tres versiones menores que la compañía mantiene desde hace años. Cualquier instancia autogestionada que siga corriendo 19.2 deja de recibir parches a partir de esa fecha, aunque el código sigue funcionando con normalidad. Los equipos de DevOps costarricenses que operan GitLab autogestionado —frecuente en bancos y software factories que no usan la nube de GitLab por requisitos de datos— deben confirmar su versión antes de quedar fuera de la ventana de parches; las instancias en GitLab.com, administradas por la compañía, no se ven afectadas por este corte.
Un ataque de julio contra los paquetes de Jscrambler reabre la pregunta de si las medidas de autenticación reforzada que promueve el registro realmente frenan a los atacantes.
Atacantes publicaron en julio versiones maliciosas del paquete jscrambler y de complementos relacionados usando credenciales de publicación robadas, según un informe de la firma de seguridad Rescana fechado el 11 de julio de 2026. El malware buscaba credenciales, secretos y archivos sensibles en proveedores de nube y en asistentes de código instalados en las máquinas comprometidas, de acuerdo con el mismo informe. El caso de Jscrambler no fue aislado dentro del registro de npm: un repaso de la firma PkgPulse sobre el panorama de seguridad de npm en 2026 describe el año como el de los gusanos de autopropagación que usan cuentas de mantenedores comprometidas como vector principal, por encima de vulnerabilidades de código. PkgPulse plantea un ángulo que contrasta con el discurso habitual del registro sobre sus controles: las medidas de autenticación reforzada que npm promueve desde 2025 no han bastado para frenar el patrón, porque el eslabón débil sigue siendo la cuenta individual del mantenedor, no la infraestructura central. Ningún incidente de esta escala se confirmó dentro de la ventana de 24 horas que cubre esta edición, pero el patrón sigue activo para cualquier equipo que instale dependencias sin fijar versiones ni revisar permisos de publicación. En Costa Rica, donde software factories y fintechs locales dependen de paquetes de npm para sus stacks de JavaScript y TypeScript, la auditoría de dependencias de terceros antes de cada despliegue sigue siendo, según reportan desarrolladores en comunidades locales, una práctica desigual entre equipos.
Un aviso de seguridad fechado el 20 de julio y recogido por el medio alemán FameSystems detalla varias fallas en el complemento CRI de containerd, el motor de ejecución de contenedores que usan Docker y Kubernetes por debajo. La más grave, CVE-2026-5348, tiene una puntuación CVSS de 9.4 y permite ejecutar comandos arbitrarios en el servidor anfitrión; una segunda falla relacionada, catalogada como CVE-2026-53488 según la base de datos Vulert, afecta al mismo componente. El proyecto containerd corrigió ambas fallas en las versiones 1.7.33, 2.3.2, 2.2.5, 2.1.9 y 2.0.10, de manera que cualquier clúster de Kubernetes o instalación de Docker que no haya actualizado el motor de contenedores por debajo de esas versiones sigue expuesto. La vulnerabilidad es sensible porque containerd corre con privilegios elevados en la mayoría de los despliegues, lo que convierte una falla de ejecución de comandos en una vía directa hacia el nodo completo, no solo hacia el contenedor afectado. Para equipos de DevOps en Costa Rica que administran sus propios clústeres de Kubernetes o que corren Docker en producción, la recomendación es verificar la versión de containerd instalada por debajo del orquestador, un paso que los proveedores de Kubernetes administrado suelen automatizar pero que las instalaciones autogestionadas no.
El equipo de lanzamientos de PostgreSQL confirmó en un mensaje a la lista de correo de desarrollo, fechado el 10 de octubre, que la disponibilidad general (GA) de PostgreSQL 19 se movió del 29 de octubre al 19 de noviembre, una semana después de la fecha que tenía programada. El proyecto había publicado la primera versión candidata (RC1) el 15 de octubre, tras cuatro betas, según el comunicado oficial publicado en postgresql.org. El motivo declarado es técnico, no de mercadeo: el equipo quiso esperar a una segunda candidata (RC2), prevista para el 12 de noviembre, para incorporar primero una serie de correcciones a varias ramas de soporte que decidió no apurar. Entre las novedades que trae la versión 19 —según las notas de la beta 1— destacan la extensión pg_plan_advice para estabilizar decisiones del planificador de consultas, el ajuste automático de trabajadores de entrada y salida, y comandos nativos de REPACK; la propia beta 4 de septiembre revirtió varias funciones que se habían anunciado antes, lo que explica en parte el calendario más cauteloso. La información proviene principalmente de los comunicados del propio proyecto PostgreSQL, sin cobertura cruzada adicional de medios especializados al cierre de esta edición. Para los equipos de desarrollo costarricenses que corren PostgreSQL en producción —frecuente en banca local y startups que usan servicios gestionados sobre el motor— el nuevo calendario da tres semanas más para planear pruebas de compatibilidad antes de que la versión 19 llegue de forma estable.
La versión 1.0.93, publicada el 7 de octubre, perfecciona el manejo de comandos pocos días antes de que la compañía abra su conferencia anual Universe en San Francisco.
GitHub publicó el 7 de octubre la versión 1.0.93 de GitHub Copilot CLI, que añade sandboxing en tiempo real para todos los usuarios al ejecutar comandos sugeridos por el asistente, según el registro de lanzamientos recopilado por havoptic.com; dos días antes, la versión 1.0.92 había sumado nuevos comandos de configuración a la herramienta de línea de comandos. El ajuste llega mientras GitHub se prepara para su conferencia anual Universe, que se realizará los días 28 y 29 de octubre en el histórico Fort Mason Center de San Francisco, el mismo tipo de evento donde la compañía suele anunciar los cambios más grandes de Copilot del año, como la apertura a múltiples modelos de lenguaje que GitHub viene ejecutando por tandas desde comienzos de octubre. La información sobre estas versiones de la CLI proviene únicamente de havoptic.com, sin confirmación independiente al cierre de esta edición. Para equipos de desarrollo en Costa Rica que ya usan Copilot CLI en flujos de automatización, el sandboxing no debería requerir ajustes manuales porque se activa por defecto; la fecha a vigilar es el 28 de octubre, cuando Universe podría traer anuncios adicionales sobre una herramienta que software factories locales usan a diario.