Tres avisos de seguridad del 21 de octubre: GitLab, Java y Railway, con versiones, comandos y qué hacer si no puedes actualizar hoy

GitLab: una falla de gravedad 10 en el servidor propio

GitLab publicó el 21 de octubre la versión 19.5.1 y otras seis para corregir CVE-2026-110264. Según el registro del CVE, afecta a «all versions from 7.0» anteriores a las corregidas, y «under certain conditions, could have allowed an unauthenticated user to execute arbitrary code»: bajo ciertas condiciones, alguien sin usuario ni contraseña puede ejecutar código en un servidor sin actualizar. La versión 7.0 es de junio de 2014. GitLab.com ya está corregido («GitLab.com is already running the patched version»), y también GitLab Dedicated; el riesgo es para quien lo tiene en su propio servidor.

El parche del 12 de octubre corregía otra falla, CVE-2026-97229. Quien actualizó ese día tiene que volver a hacerlo. El aviso advierte que 19.4.3 y 19.3.6 llevan cambios en la base de datos, y que en una instalación de un solo servidor eso implica tiempo fuera de servicio.

Cómo funciona, en simple. La falla está en el motor de expresiones regulares de Ruby (Onigmo), que GitLab usa por dentro: el aviso la llama «Integer Overflow issue in Regular Expression Compiler». La puerta sin contraseña es un archivo .org (un formato de notas de texto, como Markdown): al mostrarlo, GitLab arma una expresión regular con una línea del archivo, y una línea preparada desborda un contador del motor. Por eso, según las detecciones de GitLab, el ataque necesita un proyecto público con ese archivo.

Qué se sabe de los ataques. En el registro del CVE, consultado el 22 de octubre, CISA la marca con «Exploitation: none» (sin explotación activa ni código de ataque publicado) y «Automatable: yes»: todo el ataque, de buscar servidores vulnerables a explotarlos, se puede automatizar. No está en su catálogo de fallas ya explotadas. El informe completo sale 90 días después del parche, pero las detecciones de GitLab ya describen el mecanismo en público.

Java: confiaba en certificados con llaves débiles

Oracle publicó el 21 de octubre una alerta aparte, CVE-2026-91403, con gravedad 9.1. No es un error en el código de Java, sino en quién confiaba: ocho certificados intermedios de eMudhra, una autoridad certificadora de la India, con llaves generadas «with insufficient randomness» (Google), tan débiles que se podían calcular. Un certificado es lo que le asegura a un programa que habla con el servicio correcto. Mozilla lo resume así: «An attacker who could intercept a user's connection could use those certificates to impersonate websites and potentially read or modify traffic». En Java, eso toca a los programas que se conectan por HTTPS a otros servicios y a la verificación de programas Java firmados (JAR).

Los navegadores ya los bloquean: Firefox y Chrome desde el 17 de octubre, y las plataformas de Microsoft desde el 20 (Apple, desde el 22). Java, no hasta que se actualice.

Son versiones de Oracle Java SE; la alerta también nombra GraalVM. Oracle aclara que las versiones sin soporte no se probaron, pero que «it is likely that earlier versions… are also affected».

Qué se sabe de los ataques. eMudhra: «We are not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed». Desde el aviso, cualquiera puede calcular esas llaves («anyone can recover them», dice el sitio del caso), pero hace falta interceptar la conexión. Los navegadores no pudieron ser atacados porque exigen que cada certificado quede en un registro público (Certificate Transparency); muchos programas fuera del navegador no lo exigen, y quien publicó el caso dice que no se sabe si alguien los atacó. No está en el catálogo de fallas ya explotadas de CISA, cuya última versión es anterior a la publicación de la CVE.

Railway: la falla es del proveedor; la tarea es tuya

Railway es una plataforma para publicar aplicaciones en la nube. El 21 de octubre avisó que «an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents»: alguien pudo acceder a las variables de sus clientes y, en algunos casos, leerlas. Ahí las aplicaciones guardan sus llaves («secrets such as API keys or database and registry credentials»). No es una falla con número (CVE): no se corrige actualizando un programa.

Railway dice que «the impact may be limited to a subset of users», pero pide a todos actuar. No ha dicho cuántos clientes ni la causa, y el incidente sigue abierto; la tarde del 22 anunció un informe preliminar. Lo liga a «a series of attacks recently targeting platform companies with the aim of compromising AI inference providers»: es su explicación, sin pruebas publicadas.

Railway ya invalidó las llaves que controla: las de acceso a su plataforma, las de sus almacenes de archivos y su conexión con GitHub («you need to reconnect GitHub yourself»). También avisó a los proveedores de IA para que revoquen llaves. Pero las llaves de cada cliente pueden seguir sirviendo en el servicio que las dio. Su guía para AWS: «an exposed key works until you deactivate it»; la de GitHub: «Those registry tokens still work on GitHub until you revoke them».

Es lo mismo que contamos el martes 20 en las llaves de la IA son dinero: una llave es acceso y es dinero, y se cambia en el servicio que la dio.

Fuentes

Consultadas el 21 y el 22 de octubre de 2026.

1. GitLab, la versión 19.5.1 y las demás, 21 de octubre de 2026: CVSS 10.0; versiones 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13; «GitLab.com is already running the patched version». Y la del 12 de octubre: «versions 19.4.2, 19.3.5, 19.2.8».
2. Registro del CVE, CVE-2026-110264, 22 de octubre de 2026: «all versions from 7.0 before 18.11.13»; «under certain conditions, could have allowed an unauthenticated user to execute arbitrary code». Con la evaluación de CISA: «Exploitation: none», «Automatable: yes».
3. GitLab Security, la detección de esta falla: «Until patched, reduce public visibility where possible — the unauthenticated path needs a public .org file that GitLab renders».
4. GitLab, documentación: cómo ver la versión, el comando del servidor, la visibilidad de un proyecto y la de toda la instalación.
5. Oracle, la alerta CVE-2026-91403, 21 de octubre de 2026: «distrusts the set of impacted intermediate CA certificates related to eMudhra»; «it is likely that earlier versions… are also affected». Y las notas de 25.0.5.0.2 y de 8u511 b32.
6. Registro del CVE, CVE-2026-91403, 21 de octubre de 2026: CVSS 3.1 de 9.1; «Easily exploitable vulnerability allows unauthenticated attacker with network access».
7. OpenJDK, el aviso del 21 de octubre: «eight compromised intermediate CA certificates»; qué hacer en cada distribución. Y Oracle, ops.java/emudhra, 22 de octubre de 2026: el archivo de certificados bloqueados.
8. Mozilla, la protección de Firefox, y Google, la de Chrome y Android, 20 de octubre de 2026. Y el sitio del caso, 22 de octubre: bloqueados «in Firefox and Chrome since the 17th of October, on Microsoft platforms since the 20th».
9. eMudhra, su declaración, 21 de octubre de 2026: «We are not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed».
10. Railway, el aviso de seguridad, 21 de octubre de 2026, y el estado del incidente, 22 de octubre: «we have invalidated all Railway API tokens»; el incidente sigue en «Identified».
11. Railway, sus guías del 22 de octubre: AWS («an exposed key works until you deactivate it»), GitHub y almacenes («Those registry tokens still work on GitHub until you revoke them»; «containers read variables only at startup»), OpenAI, Stripe y PostgreSQL.
12. TechCrunch, la nota del 22 de octubre (secundaria): Railway no dio la cifra de afectados ni la causa.