JetBrains corrige un RCE sin autenticación con CVSS 9,8 en TeamCity, Node.js publica parches de severidad alta para sus tres ramas activas sin revelar aún los CVE, GitHub activa por defecto una espera de tres días en Dependabot para frenar dependencias envenenadas, y el catálogo global de GitHub Advisory Database suma apenas hoy una falla de Bouncy Castle documentada desde 2024.
El aviso, publicado el 28 de julio, detalla cómo cualquier atacante con acceso HTTP a un servidor TeamCity On-Premises puede ejecutar comandos del sistema sin ingresar una sola credencial.
JetBrains publicó el 28 de julio de 2026 un aviso de seguridad crítico para CVE-2026-63077, con una puntuación CVSS de 9,8, que afecta a todas las versiones On-Premises de TeamCity, su servidor de integración y entrega continua, según el comunicado oficial de la compañía y la cobertura de The Hacker News. La falla vive en el protocolo de sondeo (polling) que los agentes de compilación usan para comunicarse con el servidor: una deserialización insegura de datos no confiables (CWE-502) permite que un atacante sin autenticar, con acceso HTTP o HTTPS al servidor, ejecute comandos arbitrarios del sistema operativo con los privilegios del proceso de TeamCity, según documentó IONIX. El investigador identificado como Antoni Tremblay reportó la falla de forma privada a JetBrains el 10 de julio, bajo el proceso de divulgación coordinada de la compañía. La corrección llega en las versiones 2025.11.7 y 2026.1.3, y JetBrains también publicó un complemento de parche de seguridad instalable desde la versión 2017.1 en adelante para instancias que no puedan actualizar de inmediato. TeamCity es uno de los servidores de integración continua más usados por equipos de desarrollo empresarial como alternativa a Jenkins o a GitHub Actions autoalojado, y suele correr con acceso directo a credenciales de despliegue, repositorios de código y llaves de firma; una ejecución remota de comandos sin necesidad de autenticación en ese servidor equivale a entregarle a un atacante el control del pipeline completo de una organización, desde el código fuente hasta el entorno de producción. Cybersecuritynews reportó que el mismo lote de parches de JetBrains corrigió, además, una falla crítica de ejecución de código en el IDE IntelliJ IDEA y otras tres vulnerabilidades adicionales en TeamCity, lo que sugiere una revisión de seguridad más amplia dentro de la compañía en las semanas previas a esta publicación. JetBrains no ha confirmado, al cierre de esta edición, si existe explotación activa de la falla fuera del reporte original de Tremblay, y tampoco ha publicado cifras de cuántas instancias On-Premises siguen sin actualizar. Costa Rica no tiene cifras propias de adopción de TeamCity, pero la herramienta figura entre las opciones de integración continua que bancos, aseguradoras y estudios de software locales evalúan junto a Jenkins y GitHub Actions; cualquier equipo tico que la use en modalidad autoalojada debería aplicar el parche 2025.11.7 o 2026.1.3, o el complemento de seguridad, antes de exponer el servidor a redes no confiables.
El equipo de Node.js publicó el 27 de julio de 2026 nuevas versiones de sus tres líneas de lanzamiento activas —26.x, 24.x y 22.x— para corregir vulnerabilidades de seguridad, según el anuncio oficial en el blog de nodejs.org. La entrada identifica la severidad más alta del lote como "alta" en las tres ramas, pero, siguiendo la práctica habitual del proyecto de no adelantar detalles técnicos antes de que el parche esté disponible, no incluye identificadores CVE, los componentes afectados ni el número total de fallas corregidas al momento de esta edición. El propio anuncio advierte que las versiones ya llegadas a su fin de vida (End-of-Life) también se consideran afectadas por las vulnerabilidades corregidas, un recordatorio de que dejar de recibir soporte no significa dejar de ser vulnerable. El proyecto siguió un patrón similar en su aviso de seguridad del 18 de junio de 2026, publicado también con una severidad preliminar "alta" antes del lanzamiento y que, una vez liberado, terminó agrupando varias fallas adicionales detalladas solo ese mismo día, según el propio archivo de avisos de nodejs.org; nada garantiza que julio repita ese patrón, pero el historial reciente sugiere que la cifra final probablemente supere el aviso preliminar. La información de esta nota proviene únicamente del propio blog de Node.js, sin cobertura cruzada de medios especializados en seguridad, dado que el proyecto no ha publicado detalles técnicos al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Node.js, pero el entorno de ejecución es el estándar de facto para desarrollo de backend en JavaScript entre agencias, bancos y startups locales; los equipos que corran servicios en producción sobre cualquiera de las tres ramas —incluidos los que ya migraron a versiones sin soporte— deberían revisar el anuncio y aplicar la actualización correspondiente esta semana.
GitHub anunció el 27 de julio de 2026 que Dependabot, su herramienta de actualización automática de dependencias, ahora espera por defecto al menos tres días desde que una nueva versión de un paquete queda disponible antes de abrir una solicitud de actualización, según el anuncio publicado originalmente en el registro de cambios de la compañía y la cobertura de The Hacker News y Help Net Security. La espera aplica únicamente a las actualizaciones de versión rutinarias; las actualizaciones de seguridad —los parches que corrigen una vulnerabilidad ya conocida— se siguen abriendo de inmediato, sin ningún retraso. Los equipos pueden ajustar la ventana o desactivarla por completo con la opción cooldown en su archivo .github/dependabot.yml, y el cambio llegará también a GitHub Enterprise Server en su versión 3.23. GitHub explicó en la entrada de su blog de seguridad, firmada por Carlin Cherry y publicada el 23 de julio, que revisó 21 incidentes de cadena de suministro ampliamente reportados y encontró que, en la mayoría de los casos, la comunidad detectó y retiró la versión maliciosa dentro de las primeras horas tras su publicación —el ejemplo que cita es el ataque de setiembre de 2025 contra las librerías de npm chalk y debug, descargadas más de 2.000 millones de veces por semana, cuyas versiones envenenadas circularon por apenas dos horas antes de ser detectadas—; una espera de tres días habría filtrado, según su propio análisis, la mayoría de esas publicaciones antes de que cualquier proyecto llegara a instalarlas. El sitio especializado TECHi, sin embargo, señaló lo que llamó un "hueco en la capa de instalación": el retraso solo protege a los proyectos que dependen exclusivamente de las actualizaciones automáticas de Dependabot, pero no impide que un desarrollador o un pipeline de integración continua ejecute directamente npm install o su equivalente contra una versión recién publicada y maliciosa, por fuera del flujo que Dependabot controla. GitHub no ha publicado, al cierre de esta edición, cifras de cuántos repositorios ya operan bajo el nuevo comportamiento por defecto ni de cuántos han desactivado la espera. Costa Rica no tiene cifras propias de cuántos equipos locales usan Dependabot, pero la herramienta viene activada por defecto en cualquier repositorio de GitHub con el sistema habilitado, lo que incluye a buena parte de las agencias, bancos y startups costarricenses que alojan su código en la plataforma; para esos equipos, el cambio reduce en automático la ventana de exposición a una dependencia envenenada, sin que nadie tenga que configurar nada.
El aviso, publicado el 28 de julio con CVSS de 8,2, corrige una fuga de clave privada en Bouncy Castle para Java, una falla de 2024 que recién entra al catálogo de GitHub.
GitHub Advisory Database publicó el 28 de julio de 2026 un aviso de severidad alta, con puntuación CVSS de 8,2, para tres rutinas de la implementación del algoritmo criptográfico post-cuántico ML-KEM (CRYSTALS-Kyber) en Bouncy Castle para Java, la librería criptográfica de código abierto que numerosas aplicaciones empresariales en ese lenguaje usan para cifrado y firmas digitales. El problema, catalogado como CVE-2024-14041 y conocido en la comunidad de seguridad como "KyberSlash", afecta a la función Poly.toMsg (la variante llamada KyberSlash1) y a las rutinas de compresión de texto cifrado Poly.compressPoly y PolyVec.compressPolyVec (KyberSlash2), que dividen coeficientes de un polinomio derivado de la llave secreta entre el módulo q sin tiempo constante, según describe el propio aviso: un atacante capaz de medir el tiempo que tarda un número suficiente de operaciones de descifrado realizadas con la misma llave privada de largo plazo puede reconstruir esa llave a partir de esas diferencias de tiempo. Las versiones de Bouncy Castle entre la 1.73 y anteriores a la 1.78 quedan afectadas; la 1.78 corrige el problema. Lo llamativo del caso no es la falla en sí —reportada y corregida hace casi dos años— sino que recién apareciera en el catálogo global de GitHub Advisory Database esta semana, el mismo catálogo que Dependabot usa para generar alertas automáticas a millones de repositorios. El caso no es aislado: un ingeniero identificado como bribrothers reportó el 15 de julio de 2026, en el propio repositorio de GitHub Advisory Database, que los 17 boletines de seguridad de .NET publicados en el Patch Tuesday de julio nunca se ingirieron al catálogo global, dejando sin alerta de Dependabot a los paquetes NuGet afectados. GitHub reconoció en su propio blog, en mayo de 2026, que el volumen de reportes que procesa alcanzó un récord histórico de 1.560 avisos revisados en un solo mes, cinco veces su ritmo habitual, lo que ayuda a explicar por qué una falla de hace dos años y un boletín completo de un proveedor pueden quedar represados durante semanas antes de aparecer —o de no aparecer— donde las herramientas automatizadas los buscan. Ni GitHub ni Microsoft han respondido públicamente, al cierre de esta edición, sobre cuándo se resolverá el vacío de ingesta de los boletines de .NET ni cuántas otras fallas antiguas esperan turno para entrar al catálogo. Costa Rica no publica cifras propias de cuántas aplicaciones locales dependen de Bouncy Castle o de paquetes NuGet de .NET, pero ambos ecosistemas son comunes en desarrollo bancario y de gobierno digital costarricense; los equipos que dependan de alertas automáticas de Dependabot para su higiene de seguridad deberían recordar que el catálogo que las alimenta tiene, por admisión de la propia GitHub, un rezago de semanas.
Entre el 27 y el 28 de julio, JetBrains, Node.js y GitHub sumaron un nuevo capítulo a un mes marcado por fallas críticas y por esfuerzos, a veces incompletos, para ponerse al día.
Esta edición documentó, entre el 27 y el 28 de julio de 2026, cuatro desarrollos distintos que ilustran el mismo patrón que esta sección ha seguido durante julio: JetBrains corrigió una falla crítica sin autenticación (CVE-2026-63077, CVSS 9,8) en TeamCity; Node.js publicó parches de severidad alta para sus tres ramas activas sin revelar aún los identificadores CVE; GitHub activó por defecto una espera de tres días en Dependabot para frenar dependencias envenenadas recién publicadas; y el catálogo global de GitHub Advisory Database sumó, apenas hoy, un aviso de 2024 sobre Bouncy Castle que había quedado fuera de su radar durante casi dos años. Ninguno de los cuatro comparte atacante ni vector técnico, pero los cuatro tocan la misma infraestructura: las herramientas que los equipos de desarrollo dan por sentadas para compilar, desplegar y mantener seguro su código. El contraste más claro de la semana está entre el segundo y el cuarto desarrollo: mientras GitHub construye mecanismos nuevos —el retraso de Dependabot— para anticiparse a las próximas amenazas, su propio catálogo de vulnerabilidades sigue arrastrando un rezago de semanas que ni el volumen récord reconocido por la compañía en mayo ni la reestructuración de su programa de recompensas, anunciada la semana pasada, han resuelto todavía. Ese rezago no es un detalle menor para cualquier equipo que confíe en las alertas automáticas de Dependabot como su primera línea de defensa: una alerta que tarda dos años en aparecer no protege a nadie durante esos dos años. Para equipos de desarrollo en Costa Rica, la lista de esta edición es concreta: actualizar TeamCity On-Premises a la 2025.11.7 o la 2026.1.3 si algún pipeline de integración continua corre autoalojado; revisar el anuncio de Node.js y aplicar el parche correspondiente a la rama 26.x, 24.x o 22.x que esté en producción; confirmar que Dependabot, si se usa, está corriendo con la nueva ventana de espera de tres días; y no asumir que la ausencia de una alerta automática significa la ausencia de una falla —el caso de Bouncy Castle demuestra lo contrario.