El 21 de octubre de 2026 se juntaron en un solo día parches críticos de PHP, Node.js y GitLab, un paquete de Python con malware (LiteLLM) y un incidente en Railway, justo después de la brecha de OpenCode y del problema de certificados de eMudhra, que se destaparon unos días antes. Ninguno de los casos se parece al otro, pero tienen algo en común: casi todos acaban en lo mismo, claves y credenciales que hay que rotar y versiones que hay que actualizar hoy mismo.

Este es el resumen de qué pasó con cada uno, con las versiones y los CVE para que puedas comprobar si te afecta. Los datos salen de los anuncios oficiales (los enlaces están al final); donde algo no está confirmado, lo digo.

OpenCode: un ataque de destilación a gran escala

El 17 de octubre, OpenCode publicó en X que había sufrido una brecha de seguridad relacionada con un ataque de destilación a gran escala que afectó al 1,4 % de los usuarios de OpenCode Console: los que tenían proveedores externos vinculados, es decir, claves de OpenAI, Anthropic o Google guardadas en el servicio. Avisaron por correo a los afectados; en ese correo hablan de acceso no autorizado a un sistema heredado que estaban retirando.

Lo interesante es lo que contó después Dax Raad, uno de sus responsables: llevaban unas 48 horas recibiendo ataques sin parar, necesitaban agentes funcionando las 24 horas para defenderse y los modelos frontera empezaron a negarse a ayudarles. Al final consiguieron acceso a Daybreak Blue, que es un nivel de acceso del programa Daybreak de OpenAI (modelos con salvaguardas ajustadas a defensa), no un modelo aparte.

Qué hacer: si guardabas claves de terceros en OpenCode Console, revócalas y crea otras en cada proveedor, y revisa el uso reciente. La aplicación y la CLI de código abierto no se vieron afectadas.

PHP: dos RCE sin autenticación

El 21 de octubre, el equipo de seguridad de PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades de ejecución remota de código que no necesitan autenticación, ambas con una gravedad de 9,2 sobre 10 (CVSS v4.0):

  • CVE-2026-109618: corrupción de memoria cuando PHP se queda sin memoria al procesar una petición.
  • CVE-2026-109619: estado global obsoleto que otra petición del mismo proceso puede reutilizar.

PHP 8.1 y anteriores no tienen parche oficial: solo hay ramas de backports para compilar desde el código fuente. Si usas WordPress, Magento, Drupal o cualquier proyecto en PHP, actualiza y reinicia PHP-FPM o Apache. Mientras tanto, PHP propone mitigaciones provisionales: memory_limit=-1 (combinado con un límite de memoria del contenedor), bajar post_max_size y desactivar session.upload_progress.enabled.

El nombre PHP2Shell que has visto circular no es oficial: lo difundió un investigador en X. Sobre la explotación, el CTO de Cloudflare contó que en las 10 horas previas al anuncio ya veían «miles» de intentos, «decenas de miles» en los 45 minutos posteriores y «millones» al día siguiente. Cloudflare desplegó reglas en su WAF gratis para todos los planes, pero es un parche provisional: no sustituye a actualizar. Si alguien conoce la IP de tu servidor, puede saltarse el WAF.

Tienes el análisis completo, con comandos para comprobar tu versión y un prompt para tu agente, en el artículo que escribí sobre este fallo: php-cve-2026.

Node.js: RCE en el decodificador Brotli

Node.js publicó el mismo 21 de octubre un lanzamiento de seguridad con 10 CVE. El que permite ejecutar código es CVE-2026-111497: una escritura fuera de límites en el decodificador Brotli, clasificada como alta (no crítica). Lo reportó OpenAI Codex Security.

Las versiones corregidas son v26.12.1, v24.22.1 y v22.23.4. Las versiones que ya no tienen soporte siempre están afectadas, así que además de actualizar, plantéate migrar a una rama vigente.

LiteLLM: un ataque a la cadena de suministro (y no es el de marzo)

LiteLLM, el paquete de Python que unifica el acceso a muchos modelos de IA, sufrió un incidente nuevo. La versión litellm==1.107.0 se publicó con código malicioso: estuvo en PyPI menos de dos horas (de las 11:39 a las 13:23 UTC) y en Docker Hub (v1.107.0, latest, main-latest y main-stable) hasta las 14:20 UTC. Incluía un ladrón de credenciales y un cargador de herramientas de ejecución remota que se ejecuta cada vez que arranca Python.

Cómo entraron: con los tokens de GitHub CLI de tres desarrolladores del proyecto, sacados de los logs tras acceder a un despliegue interno expuesto a internet. Con ellos quitaron las protecciones de rama, aprobaron el release y borraron registros. No es el incidente de marzo, que fue por otra vía (Trivy y un token de PyPI).

Qué hacer: si instalaste o desplegaste LiteLLM el 21 de octubre, fija litellm==1.106.2, elimina los archivos del paquete malicioso, trata ese entorno como comprometido y rota todas las credenciales que estuvieran a su alcance.

GitLab: RCE sin autenticar en instancias autoalojadas

GitLab publicó el 21 de octubre un parche crítico (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13) que corrige, entre otras cosas:

  • CVE-2026-110264 (CVSS 10,0): un usuario sin autenticar puede ejecutar código por un desbordamiento de entero al compilar una expresión regular.
  • CVE-2026-15723 (alta, 8,2): un usuario autenticado puede tomar una cuenta LDAP existente si están activos OmniAuth SAML y el auto-enlace con LDAP.

Solo afecta a instancias autoalojadas: GitLab.com ya está parchado y GitLab Dedicated no necesita ninguna acción. Ojo con un detalle: quien actualizó tras el aviso del 12 de octubre (19.4.2, 19.3.5 o 19.2.8) sigue siendo vulnerable a este nuevo CVE.

Railway: variables de entorno expuestas

El 21 de octubre, Railway detectó actividad anómala en los sistemas que guardan las variables de entorno. Un tercero pudo acceder a variables cifradas y, en algunos casos, obtener su contenido descifrado. Según la empresa, el impacto podría limitarse a un subconjunto de usuarios, sin dar cifras. Pausaron todos los despliegues y avisaron a proveedores de inferencia de IA.

Qué hacer: rota todas las variables y claves de API que tuvieras en Railway (bases de datos, proveedores de LLM, registros privados) y revisa los logs. El 22 de octubre publicaron guías por proveedor para hacerlo.

eMudhra: claves privadas con valor 4

El caso más absurdo. Ocho certificados intermedios de eMudhra (seis para TLS y dos para firma de código) tenían claves privadas P-384 generadas con un número menor que 256; entre ellas, el 4 y el 56. Con una clave así cualquiera puede recuperar la privada al instante, lo que permitiría falsificar certificados de cualquier dominio.

Según eMudhra, el script de la ceremonia generó por error un segundo par de claves débil. Lo reportó un investigador el 17 de octubre; Chrome (CRLSet) y Mozilla (OneCRL) las bloquearon ese mismo día, eMudhra las revocó el 18, y Mozilla retiró de urgencia la raíz emSign ECC Root CA - G3 en Firefox 158.0.1. Según la prensa especializada, Apple y Microsoft también actuaron.

Qué hacer: mantén al día navegador y sistema operativo, y no desactives nunca la verificación de certificados para «arreglar» un error. Si usas Java, OpenJDK publicó el aviso CVE-2026-91403 por estas CA: actualiza el JDK o, si usas el del sistema, actualiza sus certificados.

¿Ataque coordinado?

Railway cree que su incidente forma parte de una serie de ataques contra empresas de plataformas para comprometer a proveedores de inferencia de IA, algo parecido a lo que le pasó a OpenCode. Es una creencia de Railway: no nombra empresas ni aporta pruebas, y las pérdidas en criptomonedas que circulan en X no están verificadas. Lo que sí es verificable es que varios incidentes de la semana tienen el mismo objetivo: las claves de los modelos de IA.

Qué hacer hoy

  1. PHP: actualiza a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 y reinicia el servicio.
  2. Node.js: v26.12.1, v24.22.1 o v22.23.4.
  3. GitLab autoalojado: parchea a una de las versiones corregidas.
  4. LiteLLM: evita 1.107.0, fija 1.106.2 y rota credenciales si lo instalaste ese día.
  5. Railway y OpenCode: rota claves de API y variables.
  6. Navegador, sistema y JDK: al día, por lo de eMudhra.
  7. Si trabajas con un agente de IA, pídele que revise las versiones que usa tu proyecto: ahora se genera mucho código y es fácil no saber qué versión corre en producción.

Un matiz sobre lo que conté en el video

Mientras grababa y escribía esto contrasté los datos con las fuentes oficiales y hay detalles que conviene precisar:

  • PHP: fueron cuatro versiones para dos CVE, y el aviso previo se publicó el 20 de octubre, unas 18 horas antes del lanzamiento, no con dos días de antelación.
  • Node.js: su lanzamiento salió antes que el de PHP (por la mañana del 21), no unas horas después.
  • Java: el CVE de Java con CVSS 9,1 que circuló esa noche es el CVE-2026-91403, y viene de los certificados de eMudhra (el JDK confiaba en esas ocho CA). No he encontrado ninguna ejecución remota de código nueva en Java.
  • GitLab: el RCE sin autenticar es real, pero la toma de cuentas exige un usuario autenticado y una configuración concreta.
  • eMudhra: son certificados intermedios, no raíces, y el hallazgo es del 17 de octubre. No he podido verificar que sea «la mayor autoridad certificadora de la India».

¿Qué te toca actualizar a ti?

Cuéntame en los comentarios qué usas en producción y si ya parchaste, y qué otro incidente de la semana te gustaría que analizara con más calma.

Fuentes