Ruby on Rails repara una vulnerabilidad de ejecución remota con puntuación CVSS 9,5 en Active Storage, Node.js cierra fallas de TLS en sus tres ramas activas, Kubernetes confirma que la versión 1.37 del 26 de agosto retirará el soporte a cgroup v1, Kotlin 2.3.0 suma soporte para Java 25, y el ranking DB-Engines de julio muestra a PostgreSQL ampliando su ventaja sobre MySQL.
El equipo de Ruby on Rails publicó el 29 de julio de 2026 un aviso de seguridad para CVE-2026-66066, una falla de inicialización insegura de recursos en Active Storage que afecta a las aplicaciones que usan la librería libvips —el procesador de variantes de imagen por defecto desde Rails 7.0— y aceptan cargas de imágenes de usuarios no autenticados, según el aviso oficial publicado en el repositorio de GitHub (GHSA-xr9x-r78c-5hrm). La falla recibió una puntuación CVSSv4 de 9,5: un atacante sin credenciales puede subir una imagen manipulada que fuerza al analizador de Vips a leer archivos arbitrarios del sistema, incluidas variables de entorno del proceso que suelen contener el secret_key_base, credenciales de base de datos y llaves de almacenamiento en la nube, según el análisis técnico de Rapid7, que bautizó la falla como «KindaRails2Shell». El equipo de Rails había programado la divulgación técnica completa para el 28 de agosto, pero adelantó la publicación después de que empezaron a circular exploits de prueba de concepto en público, según reportó BleepingComputer el 1 de agosto. La compañía liberó parches coordinados en las versiones 7.2.3.2, 8.0.5.1 y 8.1.3.1, que bloquean los cargadores no confiables de libvips al arrancar la aplicación; los investigadores de Ethiack y de GMO Flatt Security Inc., que reportaron la falla de forma responsable, advirtieron que la lectura de archivos puede escalar a ejecución remota de código en configuraciones donde el atacante logra leer credenciales que le dan acceso a sistemas conectados, según recogió The Hacker News. Rails no ha confirmado, al cierre de esta edición, cuántas aplicaciones activas siguen sin el parche, aunque HeroDevs estimó que la exposición potencial supera medio millón de sitios que usan Active Storage con libvips. Costa Rica no publica cifras propias de aplicaciones locales construidas sobre Ruby on Rails, pero el framework sigue siendo una opción común entre startups y agencias de desarrollo web ticas que aceptan cargas de imágenes de usuarios; esos equipos deberían actualizar de inmediato a la versión parchada de su rama, sin esperar confirmación de explotación activa en el país.
Las versiones de seguridad publicadas el 29 de julio cierran, entre otras fallas, un error que permitía reutilizar identidades de cliente mTLS entre solicitudes configuradas con certificados distintos.
El proyecto Node.js publicó el 29 de julio de 2026 actualizaciones de seguridad para sus tres líneas de lanzamiento activas —26.x, 24.x y 22.x—, según el aviso oficial de vulnerabilidades del propio sitio de Node.js. La falla de mayor severidad afecta el manejo interno de conexiones del HTTPS Agent: una colisión de claves en el arreglo de objetos PFX permite que una identidad de cliente mTLS (autenticación mutua por TLS) se reutilice entre solicitudes configuradas con certificados de cliente distintos, lo que puede hacer que una aplicación presente credenciales equivocadas a un servidor remoto sin que el desarrollador lo note, según el aviso del equipo de seguridad de Node.js. El mismo lote de parches corrige un segundo problema del HTTPS Agent —la reutilización de sesión TLS puede saltarse la verificación de nombre de host entre distintas políticas de identidad— y un error en el módulo node:sqlite, donde un StatementSyncIterator obsoleto puede seguir ejecutando una sentencia preparada en caché después de que esta ya fue reiniciada y reconfigurada con nuevos parámetros, según describió NodeSource en su resumen semanal del ciclo de julio. Node.js clasificó la severidad más alta del lote como «alta», sin llegar a crítica, pero las tres fallas comparten un mismo patrón: código de red o de base de datos que reutiliza estado interno de forma insegura entre operaciones que el desarrollador asume aisladas entre sí, según el repaso de DigitalApplied sobre lo que efectivamente incluyó el parche. Node.js no ha reportado, en su aviso oficial, evidencia de explotación activa de ninguna de las fallas corregidas. Costa Rica no publica cifras propias de aplicaciones locales construidas sobre Node.js, pero el entorno de ejecución es la base de la mayoría de los backends de JavaScript en agencias y zonas francas tecnológicas del país; los equipos que usen autenticación mutua por TLS entre microservicios o que dependan de node:sqlite deberían actualizar a la versión parchada de su rama sin esperar una ventana de mantenimiento programada.
El proyecto Kubernetes confirmó, en la documentación oficial de su ciclo de lanzamiento, que la versión 1.37 —programada para el 26 de agosto de 2026— completará el retiro del soporte a cgroup v1: los nodos que corran ese modo sin declarar explícitamente failCgroupV1: false en la configuración del kubelet rechazarán arrancar por completo, según Kubernetes Contributors. La bandera FailCgroupV1 viene activada por defecto desde la versión 1.35, pero hasta ahora solo generaba advertencias; la versión 1.37 la convierte en un bloqueo duro. El cambio llega junto con otro requisito de infraestructura: 1.37 exige containerd 2.0 o superior, alineado con el fin del soporte de containerd 1.7, según el análisis de byteiota sobre la guía de actualización. Para los equipos que administran clústeres propios —no gestionados por un proveedor de nube que ya migró la capa de containerd por ellos—, la combinación de ambos requisitos obliga a verificar dos capas de la infraestructura a la vez: el runtime de contenedores y el modo de cgroups del sistema operativo del nodo, antes de que termine agosto. El proyecto Kubernetes no ha publicado, a la fecha, cifras de cuántos clústeres en producción siguen corriendo cgroup v1. Costa Rica no publica cifras propias de adopción de Kubernetes, pero la herramienta es la opción dominante de orquestación de contenedores entre bancos, telecomunicaciones y empresas de desarrollo que operan en zonas francas tecnológicas del país; los equipos que administren clústeres autoadministrados deberían confirmar el modo de cgroups de sus nodos y la versión de containerd antes del 26 de agosto, para no toparse con un kubelet que se niega a arrancar en plena ventana de actualización.
JetBrains publicó el 27 de julio de 2026 la versión estable de Kotlin 2.3.0, con soporte oficial para Java 25, según la documentación de novedades del propio lenguaje. La actualización mejora los tiempos de compilación en Kotlin/Native, añade nombres completamente calificados y un manejo de excepciones renovado en Kotlin/Wasm, y suma exportación experimental de funciones suspendidas (suspend) en Kotlin/JS, de acuerdo con el registro oficial de cambios publicado en el repositorio del lenguaje. El lanzamiento confirma el ritmo trimestral que JetBrains sostiene para las versiones menores del lenguaje: la compañía ya trabaja en Kotlin 2.4.20, planeada para setiembre de 2026, y en Kotlin 2.5.0, prevista para diciembre, según el calendario de versiones de la documentación oficial. Java 25, la versión de la plataforma que Kotlin 2.3.0 ahora soporta de forma oficial, llegó como versión de soporte a largo plazo de Oracle a mediados de este año, lo que hace que la compatibilidad declarada de Kotlin importe para equipos empresariales que recién evalúan migrar a esa versión de Java. JetBrains no ha detallado, en el registro de cambios, cifras de adopción de Kotlin 2.3.0 desde su publicación. Costa Rica no publica cifras propias de adopción de Kotlin, pero el lenguaje es una opción común entre equipos de desarrollo móvil Android y de backend en agencias y bancos locales que ya trabajan sobre la máquina virtual de Java; esos equipos pueden actualizar hoy mismo a la versión 2.3.0 sin esperar la ventana de Kotlin 2.4.20 de setiembre.
— La versión estable, publicada el 27 de julio, llega con mejoras de tiempo de compilación en Kotlin/Native y cambios en el manejo de excepciones de Kotlin/Wasm, mientras JetBrains ya trabaja en la versión 2.4.20 para setiembre.
PostgreSQL fue la única base de datos entre las cuatro más usadas que ganó puntaje en el ranking de DB-Engines de julio de 2026, mientras MySQL perdió 94 puntos en medio de recortes de personal en Oracle.
El ranking de popularidad de bases de datos DB-Engines, actualizado en julio de 2026, mostró a PostgreSQL como la única base de datos entre las cuatro más populares que ganó puntaje interanual, con un alza de 6,92 puntos, mientras MySQL cayó 94 puntos en el mismo período, según el análisis de esos datos publicado por Kunal Ganglani. La encuesta anual de Stack Overflow de 2026 ya había ubicado a PostgreSQL como la base de datos «más deseada» por los desarrolladores encuestados, con una adopción que creció 12% interanual. La caída de MySQL coincide con recortes de personal en el equipo que Oracle dedica a su desarrollo: hasta 70 ingenieros senior de MySQL perdieron su puesto en setiembre de 2025, según recogió el análisis comparativo de Vonng sobre ambos motores, lo que alimentó dudas en parte de la comunidad sobre el ritmo futuro de desarrollo del proyecto bajo Oracle. DB-Engines, sin embargo, explica en su propia metodología que el ranking mide menciones en buscadores, foros técnicos y ofertas de empleo, no instalaciones activas ni ingresos por licencias —una limitación que el propio sitio reconoce y que hace que una caída de puntaje no equivalga necesariamente a una migración masiva de aplicaciones ya en producción fuera de MySQL. Ni Oracle ni DB-Engines han publicado cifras que permitan verificar de forma independiente cuántas instalaciones activas de MySQL migraron a otro motor en 2026. Costa Rica no publica cifras propias de adopción de motores de bases de datos, pero tanto PostgreSQL como MySQL son opciones comunes entre bancos, aseguradoras y agencias de desarrollo que operan en el país; los equipos ticos que evalúen su motor de base de datos deberían pesar el ranking de popularidad como una señal más, no como sustituto de una evaluación técnica propia de rendimiento y soporte.