Synacktiv documenta año y medio sin respuesta del proyecto de GitOps más usado del mundo, npm se alista para bloquear scripts y dependencias remotas por defecto en julio, una segunda campaña norcoreana golpea paquetes de Rollup y Oracle estrena versión CalVer para MySQL.
La firma francesa Synacktiv publicó los detalles técnicos el 1 de julio, año y medio después de reportar la falla a los mantenedores del proyecto de GitOps más usado del mundo sin recibir una corrección.
La firma de ciberseguridad Synacktiv publicó el 1 de julio de 2026 un análisis técnico titulado "Caught in the Octopus Trap", que documenta una cadena de ataque no autenticada contra el componente repo-server de Argo CD, la herramienta de entrega continua GitOps más usada para desplegar aplicaciones en Kubernetes. Según Synacktiv, el servicio interno gRPC del repo-server no exige autenticación: cualquier pod que pueda alcanzarlo —una aplicación comprometida, un service mesh mal configurado, una carga de trabajo vecina con ejecución de código local— puede enviar una petición manipulada y ejecutar comandos como si fuera un atacante autenticado. A partir de ahí, Synacktiv demostró que es posible leer la contraseña de Redis del clúster desde una variable de entorno, conectarse a la caché de Redis de Argo CD y envenenar los datos de despliegue almacenados; en la siguiente sincronización automática, Argo CD despliega la carga de trabajo que el atacante inyectó. Synacktiv probó la cadena completa contra Argo CD v2.13.3 y no reportó ninguna versión con parche disponible. Synacktiv reportó la falla a los mantenedores de Argo CD en enero de 2025 y, según su propio relato, insistió por GitHub y correo electrónico durante año y medio sin lograr coordinar una corrección; al no existir parche ni identificador CVE asignado, la firma decidió publicar los detalles para que los equipos se protejan por su cuenta, de acuerdo con la cobertura de The Hacker News y CSO Online. Argo CD, mantenido bajo el paraguas de la Cloud Native Computing Foundation, es la herramienta de referencia para GitOps: miles de equipos la usan para que cualquier cambio fusionado a un repositorio Git se refleje automáticamente en producción, lo que convierte una falla de autenticación interna en una vía directa hacia el clúster completo. La firma matiza, sin embargo, que el proyecto no ha estado inactivo en seguridad: en junio de 2026 lanzó Argo CD 3.5 con mTLS interno y verificación de integridad de fuente, según reportó InfoQ, aunque esas mejoras no cubren la falla del repo-server. La mitigación disponible mientras no exista parche es exclusivamente de red: activar las políticas de Kubernetes (NetworkPolicy) que limitan qué componentes pueden alcanzar los puertos del repo-server y de Redis. Argo CD distribuye esos archivos de política, pero el chart oficial de Helm los deja desactivados por defecto, así que cada equipo debe habilitarlos manualmente. Ningún medio ha confirmado clústeres costarricenses comprometidos al cierre de esta edición, pero Argo CD y Kubernetes son piezas estándar en los centros de servicios compartidos y las operaciones de DevOps que multinacionales como IBM, Amazon y VMware mantienen en zonas francas del país, lo que vuelve la revisión de esas políticas de red una tarea urgente para sus equipos de plataforma.
GitHub anunció el 9 de junio que la próxima versión mayor del gestor de paquetes de JavaScript exigirá aprobación explícita para ejecutar scripts, resolver dependencias de Git o descargar tarballs remotos.
GitHub anunció el 9 de junio de 2026, a través del changelog oficial de npm, tres cambios de seguridad que rompen compatibilidad en la próxima versión mayor del gestor de paquetes: npm v12, con lanzamiento estimado para julio de 2026. A partir de esa versión, `npm install` dejará de ejecutar automáticamente los scripts `preinstall`, `install` y `postinstall` de las dependencias, a menos que el proyecto los autorice explícitamente; dejará de resolver dependencias de Git salvo que se use la bandera `--allow-git`; y dejará de descargar dependencias desde URLs remotas —tarballs directos o transitivos— salvo que se habilite con `--allow-remote`. Los tres cambios ya están disponibles con advertencias desde npm 11.16.0, según el propio changelog, para que los equipos puedan prepararse antes del salto de versión. El cambio responde directamente a la ola de ataques a la cadena de suministro de código abierto que ha golpeado a npm durante el último año, todos apoyados en scripts de instalación que se ejecutan sin que el desarrollador lo note. La recepción inicial fue, según reportó DevOps.com, más de alivio que de queja: en los foros de la comunidad, desarrolladores señalaron que la ejecución de código arbitrario por defecto durante años era, en retrospectiva, difícil de justificar. Pero no todos coinciden en que el cambio resuelva el problema de fondo: NodeSource publicó un análisis titulado "Blocking Install Scripts Is Not a Silver Bullet", y la investigadora identificada como Krell, de Suzu Labs, advirtió —según recogió Cybernews— que un proyecto npm promedio arrastra 79 dependencias transitivas, y que los equipos que aprueben scripts en bloque para evitar fricción "no obtienen ningún beneficio de seguridad real"; el cambio tampoco ataca directamente el problema de cuentas de mantenedores comprometidas, la vía de entrada más común en los ataques recientes. Los equipos que dependan de paquetes con módulos nativos (que usan `node-gyp` o un archivo `binding.gyp`), dependencias fijadas a Git o tarballs remotos deberán auditar y aprobar cada caso antes de actualizar, usando la herramienta `npm approve-scripts --allow-scripts-pending` que GitHub incluyó para facilitar la transición. En Costa Rica, donde buena parte del desarrollo de software para clientes en Estados Unidos corre sobre pipelines de CI/CD basados en npm, el cambio obliga a un inventario previo de scripts de instalación antes de que la versión 12 llegue por defecto a los registros de dependencias.
Investigadores de JFrog identificaron seis paquetes que copian el nombre y los metadatos de una herramienta legítima de compatibilidad para Rollup e instalan, en cadena, un ladrón de credenciales y una puerta trasera de control remoto completo.
JFrog Security Research publicó el 1 de julio de 2026 un análisis sobre seis paquetes maliciosos de npm —encabezados por `rollup-packages-polyfill-core` y `rollup-runtime-polyfill-core`— que imitan el nombre, el README y los metadatos del proyecto legítimo `rollup-plugin-polyfill-node`, la herramienta de compatibilidad para el empaquetador Rollup. Según JFrog, la campaña está vinculada al grupo norcoreano Lazarus y despliega una cadena de varias etapas: un primer módulo roba datos del navegador y de billeteras de criptomonedas, un segundo rastrea el sistema de archivos en busca de secretos y variables de entorno, un tercero monitorea el portapapeles, y un componente final de acceso remoto permite ejecutar comandos, abrir terminales, iniciar sesiones SSH, capturar pantallas y controlar el mouse y el teclado de la máquina infectada. JFrog confirmó que la carga maliciosa seguía activa en un análisis del 30 de junio, y los seis paquetes ya fueron retirados del registro de npm, según reportó The Hacker News. La campaña llega apenas días después de que investigadores documentaran la operación PolinRider, también atribuida a actores norcoreanos, contra npm, Packagist y Go —la segunda campaña de este tipo vinculada a Corea del Norte que sale a la luz en una semana—, un patrón que la firma Socket describe como una ola sostenida en la que "siguen apareciendo paquetes nuevos" mientras los atacantes retengan acceso a cuentas de mantenedores comprometidas. Ningún medio reportó infecciones confirmadas en Costa Rica a partir de esta campaña específica al cierre de esta edición. El riesgo estructural, sin embargo, es el mismo que enfrentan los equipos ticos de desarrollo con cualquier dependencia de Rollup o Vite —empaquetadores de uso común en proyectos de JavaScript modernos—: verificar el nombre exacto del paquete antes de instalarlo, ya que la suplantación de nombres parecidos sigue siendo la puerta de entrada más barata para estas operaciones.
cat /feed/basesdedatosmysql.md
La primera versión bajo el nuevo esquema —MySQL Community Server 26.7, publicada en acceso anticipado el 3 de julio— reemplaza la numeración tradicional por un formato basado en año y mes.
> Oracle anunció en su blog oficial de MySQL un nuevo modelo de versionado basado en fecha calendario (CalVer) para las llamadas versiones Innovation del motor de base de datos, y publicó el 3 de julio de 2026 la primera bajo ese esquema: MySQL Community Server 26.7, en acceso anticipado ("early access"). El formato usa los dos últimos dígitos del año seguidos del mes sin cero inicial —enero es 1, julio es 7, octubre es 10—, de modo que una futura versión 26.10.0 identifica de inmediato el lanzamiento Innovation programado para octubre de 2026. La 26.7 llega inmediatamente después de MySQL 9.7, publicada en mayo de 2026 como la primera versión LTS (soporte de largo plazo) desde la 8.4, según documentó InfoQ.
> Oracle dijo que el cambio busca responder una pregunta práctica que hoy exige explicación: en qué línea de soporte corre cada base de datos, algo que la numeración secuencial anterior —8.0, 8.4, 9.0, 9.7— no comunicaba con claridad a administradores de bases de datos, desarrolladores, distribuciones de Linux y plataformas de nube. Según Oracle, el formato final —basado en el mes en vez del trimestre— surgió de comentarios de la comunidad de MySQL Rockstars y de los Oracle ACE durante el proceso de diseño. Las líneas Innovation (funciones nuevas, soporte corto) y LTS (estabilidad, soporte largo) se mantienen como pistas separadas, con el ciclo trimestral de parches de seguridad (CPU) sin cambios.
> Para equipos de desarrollo en Costa Rica, donde MySQL es motor común en banca y en centros de servicios compartidos junto a PostgreSQL, el cambio de nomenclatura no altera el comportamiento del motor, pero sí obliga a actualizar scripts de automatización y documentación interna que hoy asumen el viejo esquema de versiones al planificar sus próximas actualizaciones.
GitHub anunció el 12 de junio de 2026, a través de su changelog oficial, que retoma la exigencia de versión mínima para los runners autoalojados (self-hosted) de GitHub Actions en github.com y en GitHub Enterprise Cloud con residencia de datos, como parte de un esfuerzo más amplio para reconstruir el núcleo de Actions y mejorar su confiabilidad y disponibilidad. La aplicación completa de la regla comienza el 31 de julio de 2026 para las organizaciones con residencia de datos, y el 25 de setiembre de 2026 para el resto de clientes de GitHub Enterprise Cloud. En paralelo, GitHub confirmó que Code Quality —su producto de análisis estático integrado a pull requests— pasa de vista previa pública a disponibilidad general el 20 de julio de 2026, con un precio de USD 10 por colaborador activo al mes en los repositorios donde se habilite, más consumo adicional para sus capacidades basadas en IA. Ambos anuncios llegan mientras GitHub endurece por separado la seguridad de npm con la versión 12 del gestor de paquetes, en lo que empieza a leerse como una reconstrucción general de la plataforma tras una serie de fallas de disponibilidad que la propia empresa reconoció a comienzos de año. Los equipos costarricenses que operan runners autoalojados —una práctica común entre empresas de servicios compartidos que buscan evitar los minutos pagos de Actions— deberán auditar la versión de su software de runner antes de las fechas límite, o sus flujos de integración continua dejarán de aceptar trabajos sin previo aviso.
— La medida, que exigirá versiones mínimas del software de los runners antes de aceptar trabajos, llega junto con la salida general de GitHub Code Quality el 20 de julio.
La primera semana de julio de 2026 deja dos frentes abiertos para el desarrollo de software: la infraestructura de despliegue automatizado (GitOps) y el ecosistema de paquetes de JavaScript. Argo CD, la herramienta de GitOps más usada para Kubernetes, sigue sin parche año y medio después de que Synacktiv reportara una falla que permite tomar control de clústeres completos; y npm se prepara para julio con su cambio de seguridad más profundo en años, mientras una segunda campaña de paquetes maliciosos vinculada a Corea del Norte —esta vez imitando herramientas de Rollup— se suma a la ya reportada operación PolinRider de días atrás. Ninguno de los dos frentes tiene una solución definitiva a la vista: la mitigación de Argo CD depende de que cada equipo active manualmente políticas de red que Helm no habilita por defecto, y los propios críticos del cambio en npm —como la investigadora Krell, de Suzu Labs— advierten que aprobar scripts en bloque para evitar fricción anula el beneficio de seguridad que la medida busca ofrecer. En paralelo, la infraestructura de más bajo perfil sigue moviéndose: Oracle estrena un esquema de versiones más predecible para MySQL y GitHub reorganiza el control de versiones de sus runners autoalojados de Actions, dos cambios que no hacen titulares por sí solos pero que los equipos de plataforma deben calendarizar igual. Para los equipos de desarrollo en Costa Rica —desde los centros de servicios compartidos que corren GitOps y CI/CD para clientes en Estados Unidos hasta las cooperativas y pequeñas consultoras que administran su propia infraestructura de Kubernetes— julio llega con la misma lección de las últimas semanas: revisar cada política de red, cada script de instalación y cada paquete antes de confiar en que alguien más ya lo hizo por ustedes.