Una falla de tres horas y media en AWS CloudFront, la beta 2 de PostgreSQL 19 con consultas nativas de grafos, el debut de Rust en el top 10 del índice TIOBE, una falla de tokens en n8n y las dudas sobre si npm 12 alcanza para frenar la cadena de suministro maliciosa marcan la agenda de desarrollo del 17 de julio.
Una falla en el enrutamiento de tráfico hacia orígenes privados de VPC dejó fuera de línea a clientes como Hugging Face y la Lotería Nacional del Reino Unido durante la madrugada del 16 de julio.
Amazon Web Services confirmó una interrupción en CloudFront, su red de distribución de contenido, entre la 1:45 a.m. y las 5:18 a.m. hora de Costa Rica del 16 de julio de 2026 —12:45 a.m. a 4:18 a.m. hora del Pacífico—, según el propio panel de estado de AWS. El fallo afectó específicamente a los clientes que usan VPC Origins, una función que permite servir aplicaciones detrás de balanceadores de carga privados sin exponer la infraestructura a internet público. Downdetector registró más de 350 reportes de usuarios durante el incidente, según recogió The Register; entre los afectados estuvieron la plataforma de desarrollo de inteligencia artificial Hugging Face y la Lotería Nacional del Reino Unido, que reconoció que sus jugadores no pudieron acceder al sitio ni a la aplicación móvil. AWS explicó que la causa fue un problema en el subsistema que distribuye la configuración de enrutamiento hacia los procesadores de red encargados de conectar CloudFront con los orígenes privados en VPC, un fallo que la compañía rastreó hasta una sola zona de disponibilidad —euc1-az2, en su región de Fráncfort— y describió como una restricción interna en la flota que gestiona esas conexiones, según detalló SDxCentral. El incidente reabre una pregunta recurrente en 2026: VPC Origins se promocionó como una mejora de seguridad frente a exponer balanceadores de carga a internet, pero la falla del 16 de julio muestra que centralizar el enrutamiento en un componente interno de AWS puede convertir esa mejora de seguridad en un punto único de falla, aunque de alcance limitado a una sola zona de disponibilidad. AWS no publicó al cierre de esta edición un informe posterior al incidente con el detalle completo de la corrección aplicada, más allá de confirmar que los clientes que cambiaron temporalmente su tipo de origen ya pueden revertir el cambio con seguridad. Costa Rica no depende directamente de la región de Fráncfort —la mayoría del tráfico local hacia AWS se enruta por la región este de Estados Unidos—, por lo que el impacto directo sobre empresas ticas fue marginal; aun así, cualquier equipo local que use CloudFront con VPC Origins para servicios con presencia europea debería revisar si su configuración quedó expuesta durante la ventana de casi tres horas y media que duró la falla.
La segunda beta, publicada el 16 de julio, congela las funcionalidades de la próxima versión mayor e incorpora comandos SQL/PGQ para modelar grafos en el motor, además de un REPACK unificado sin tiempo de inactividad.
El Grupo Global de Desarrollo de PostgreSQL publicó el 16 de julio de 2026 la beta 2 de PostgreSQL 19, la segunda versión de prueba de la próxima entrega mayor de la base de datos de código abierto, según el anuncio oficial del proyecto. La beta 2 marca el congelamiento de funcionalidades (feature freeze): ninguna capacidad nueva se agregará a partir de aquí, solo correcciones de errores hasta la disponibilidad general, prevista para la segunda mitad de 2026. Entre las novedades más visibles están las consultas nativas de grafos con la sintaxis estándar SQL/PGQ —las funciones GRAPH_TABLE y el comando CREATE PROPERTY GRAPH permiten modelar y consultar datos como grafos directamente en el servidor, sin extensiones de terceros— y un comando REPACK unificado en el núcleo, con soporte para REPACK CONCURRENTLY, que reorganiza tablas sin bloquear las escrituras. PostgreSQL 19 también trae cambios que rompen compatibilidad y que cualquier equipo de administración de bases de datos debe planificar con anticipación: la variable standard_conforming_strings queda forzada a activada, lo que significa que los volcados (dumps) generados con esa variable desactivada en versiones anteriores no cargarán correctamente sin usar las herramientas de PostgreSQL 19 o fijar la variable de forma explícita al importar; y la clase de operador de índice por defecto para los tipos inet y cidr cambia de btree_gist a GiST, al punto de que pg_upgrade rechazará migrar clústeres que todavía tengan índices btree_gist sobre esos tipos, según documentó el sitio especializado LinuxCompatible. El blog de ingeniería de Snowflake, que analizó la beta en detalle, señaló que estos cambios de compatibilidad —más que las funciones nuevas— son los que exigen pruebas cuidadosas antes de actualizar entornos de producción. La disponibilidad general de PostgreSQL 19 todavía no tiene fecha exacta más allá de "segunda mitad de 2026"; entre ahora y entonces solo se esperan correcciones de errores sobre la base ya congelada. Costa Rica no tiene registros públicos de qué motor de base de datos usa cada institución estatal, pero PostgreSQL es una opción extendida entre bancos, cooperativas y desarrolladoras locales que evitan las licencias comerciales de motores propietarios, por lo que los equipos ticos que planeen adoptar la versión 19 deberían iniciar pruebas de migración contra los cambios de compatibilidad desde ya.
cat /feed/seguridadn8n.md
CVE-2026-59208 afecta a instalaciones empresariales de n8n con múltiples proveedores de identidad configurados y ya tiene parche disponible en las versiones 2.27.4 y 2.28.1.
> n8n, la plataforma de automatización de flujos de trabajo de código abierto, corrigió una falla de coincidencia de tokens JWT identificada como CVE-2026-59208, que permitía a un atacante iniciar sesión suplantando a un usuario registrado bajo un proveedor de identidad distinto en instalaciones empresariales configuradas con múltiples emisores (multi-issuer), según reportó The Hacker News el 16 de julio de 2026. La falla afecta a todas las versiones de n8n anteriores a la 2.27.4 y a la versión 2.28.0; el proyecto publicó el parche por primera vez en las versiones 2.27.4 y 2.28.1.
> El error es un problema de validación: cuando una organización configura n8n para aceptar inicios de sesión desde más de un proveedor de identidad —un escenario común en empresas que combinan, por ejemplo, un proveedor para un equipo y otro distinto para otro—, el sistema no verificaba de forma consistente que el token JWT presentado correspondiera al emisor esperado, lo que abría la puerta a que alguien con acceso a un token válido de un proveedor lo usara para autenticarse como un usuario de otro. n8n no reportó evidencia de explotación activa antes de la corrección, según la misma cobertura de The Hacker News.
> La información sobre esta falla proviene únicamente de The Hacker News, sin confirmación independiente adicional al cierre de esta edición. n8n gana terreno entre equipos de operaciones y automatización en Costa Rica como alternativa de código abierto a plataformas comerciales de flujos de trabajo; cualquier equipo local que administre una instancia empresarial propia con configuración multi-emisor debería confirmar que corre la versión 2.27.4, la 2.28.1 o una posterior.
npm 12, la versión más reciente del gestor de paquetes de Node.js, está en producción desde el 8 de julio de 2026 con el rediseño de seguridad más profundo de sus 16 años de historia, según el registro oficial de cambios de GitHub. La actualización desactiva por defecto tres comportamientos que los atacantes explotaron de forma recurrente durante 2025 y 2026: los scripts de ciclo de vida (preinstall, install, postinstall) y las compilaciones implícitas de node-gyp ya no se ejecutan sin autorización explícita; las dependencias de Git, directas o transitivas, dejan de resolverse por defecto; y lo mismo ocurre con las dependencias descargadas desde URL remotas, como archivos .tar.gz alojados fuera del registro. GitHub también anunció la eliminación gradual de los tokens de acceso granular (GAT) que permitían saltarse la verificación en dos pasos. Cybernews tituló su cobertura de la actualización "NPM v12 security overhaul: Experts say it's not enough" —el rediseño de seguridad de npm v12: expertos dicen que no basta—, una duda que esta misma sección viene a confirmar con un caso concreto: el ataque contra los paquetes de AsyncAPI que esta edición documentó el 15 de julio no dependió de ningún script de instalación malicioso —el vector que npm 12 bloquea—, sino del robo de un token de publicación a través de un flujo de trabajo mal configurado de GitHub Actions, un punto de entrada que queda completamente fuera del alcance de este parche. npm 12 cierra una puerta real, pero la cadena de suministro de JavaScript tiene más de una entrada. El cronograma de GitHub contempla dos etapas adicionales: la primera, prevista para inicios de agosto de 2026, endurece aún más las reglas de resolución de dependencias; la segunda, programada para enero de 2027, es la fecha límite final para que los paquetes que dependan de scripts de instalación se adapten al nuevo esquema. Los equipos de desarrollo costarricenses que publican o consumen paquetes de npm —la base de la mayoría de los proyectos de JavaScript y Node.js locales— deberían usar el comando npm approve-scripts para auditar qué scripts necesitan de verdad antes de que la segunda etapa del cronograma los obligue a hacerlo bajo presión.
Rust alcanzó el décimo lugar del índice TIOBE de julio de 2026, con una cuota de 1,34%, su primera aparición en el top 10 desde que la métrica existe, según publicó TIOBE el 5 de julio. Hace apenas un año, en julio de 2025, el lenguaje ocupaba el puesto 18. Python se mantiene en el primer lugar con 18,94%, seguido de C, C++, Java, C# y JavaScript; SQL subió del puesto 13 al 8 y R avanzó del 15 al 9 en el mismo período, según TechRepublic. Paul Jansen, director ejecutivo de TIOBE, atribuyó el ascenso de Rust a su capacidad de prevenir errores de memoria sin sacrificar velocidad de ejecución, según recogió InfoWorld. El repunte coincide con una adopción corporativa creciente: Meta anunció este año la reescritura en Rust de la biblioteca de medios de WhatsApp, y Amazon y Microsoft también ampliaron su uso del lenguaje en proyectos de infraestructura, de acuerdo con la misma cobertura. La edición de julio marca además el aniversario 25 del índice TIOBE, que arrancó en 2001 con C, C++ y Java ya entre los líderes —los mismos tres lenguajes que, un cuarto de siglo después, siguen en el top 5. El índice TIOBE mide la frecuencia de búsquedas y menciones del lenguaje en buscadores, no la cantidad de código en producción, una limitación metodológica que la propia TIOBE reconoce en su sitio y que conviene tener presente antes de leer el ranking como un mapa exacto del mercado laboral. En Costa Rica, la oferta de empleo formal en Rust sigue siendo marginal frente a JavaScript, Python o Java —los tres lenguajes que dominan los centros de desarrollo de zona franca—; el efecto directo de este ascenso en el mercado laboral tico es todavía difuso, sin datos públicos que midan cuántas vacantes locales piden el lenguaje.
GitLab registró el 15 de julio de 2026 un incidente de rendimiento degradado que afectó las descargas de paquetes desde packages.gitlab.com, el registro integrado de la plataforma para paquetes de npm, Maven, PyPI, Conan y otros formatos, según el historial público de estado de la compañía. El incidente se suma a otros dos reportados la misma semana: errores elevados en las verificaciones de estado de la puerta de enlace de IA (AI Gateway) el 14 de julio, y un incidente previo el 1 de julio. GitLab marcó el incidente del 15 de julio como resuelto el mismo día, pero la información disponible al cierre de esta edición proviene únicamente del historial de estado público de la compañía, sin un desglose técnico de la causa raíz ni cifras de usuarios afectados —a diferencia de otros incidentes de infraestructura de esta edición, como la falla de AWS CloudFront, que sí tuvo una explicación técnica pública. GitLab.com es una de las plataformas de control de versiones y CI/CD más usadas por equipos de desarrollo que no quieren administrar su propia instancia, junto con GitHub. Costa Rica tiene una base activa de estudios de software pequeños y proyectos de código abierto que usan el nivel gratuito de GitLab.com para alojar repositorios y ejecutar integración continua; cualquier equipo local cuyos flujos de trabajo dependan de instalar paquetes desde el registro integrado de GitLab durante la ventana del incidente pudo haber visto fallos intermitentes en sus canalizaciones el 15 de julio, aunque no hay reportes específicos de equipos costarricenses afectados al cierre de esta edición.
La jornada del 16 de julio de 2026 combina tres historias que rara vez comparten portada: una interrupción de infraestructura, un hito de lenguaje y una base de datos que avanza según lo previsto. AWS CloudFront falló durante más de tres horas en su región de Fráncfort por un problema en el enrutamiento hacia orígenes privados de VPC, con Hugging Face y la Lotería Nacional del Reino Unido entre los afectados. En paralelo, PostgreSQL alcanzó la beta 2 de su versión 19, con consultas nativas de grafos y un comando REPACK unificado, mientras Rust debutó en el top 10 del índice TIOBE por primera vez en su historia. El hilo que conecta esta edición con las dos anteriores —el ataque a AsyncAPI del 14 de julio y la extensión del blindaje de GitHub Actions— sigue siendo la cadena de suministro de software: npm 12 entró en producción el 8 de julio con el rediseño de seguridad más profundo de sus 16 años, pero Cybernews ya cuestionó si alcanza, y el propio caso de AsyncAPI de esta semana lo confirma, porque ese ataque no pasó por ningún script de instalación. Una falla de coincidencia de tokens en n8n y un incidente menor en el registro de paquetes de GitLab completan un panorama donde ninguna pieza de infraestructura —nube, gestor de paquetes o plataforma de control de versiones— quedó exenta de un sobresalto esta semana. Para los equipos de desarrollo en Costa Rica, la lista de esta edición es concreta: revisar si alguna integración local depende de CloudFront con VPC Origins en la región de Fráncfort, empezar a probar migraciones contra los cambios de compatibilidad de PostgreSQL 19 antes de su disponibilidad general, auditar con npm approve-scripts qué scripts de instalación necesitan de verdad los proyectos de Node.js, y confirmar la versión de n8n en cualquier instancia empresarial con configuración multi-emisor. Ninguna depende de un presupuesto grande; todas dependen de que alguien las revise esta semana.