Entre el 17 y el 22 de octubre de 2026 coincidieron en pocos días un fallo crítico en PHP, otro en GitLab, un paquete malicioso en PyPI y Docker Hub, unas claves de certificados que cualquiera podía adivinar y una intrusión en un proveedor de gestión de TI. La prensa lo bautizó como Black October. Pero detrás del titular hay una historia menos espectacular y bastante más inquietante: buena parte de esto llevaba meses gestándose.
Cuando varios incidentes graves se acumulan en una semana, la tentación es pensar en una gran ofensiva coordinada. Los datos no apuntan a eso. Lo que ocurrió se parece más a un atasco de avisos que llevaban tiempo en la cola y que acabaron saliendo a la vez. Y eso, para quien mantiene un servidor, un proyecto o un simple blog, es una lección mucho más útil que el susto.
La etiqueta Black October se ha extendido por medios y blogs de seguridad y según la entrada de Wikipedia la han usado cabeceras como CNBC, The Guardian o The Washington Post. Su origen, sin embargo, es difuso: Forkast la atribuye a un mensaje en X de la madrugada del 22 de octubre que calificaba las 48 horas anteriores como las peores de la historia de la ciberseguridad y reconoce que no ha conseguido localizar esa publicación.
Ese mismo análisis propone una lectura que merece la pena retener: no fue una ola de ataques, sino una ola de divulgaciones. Los fallos y las exposiciones llevaban meses (o años) ahí; lo que concentró octubre fue el momento en que se hicieron públicos. La etiqueta, dicen, esconde ese reloj.
El 21 de octubre, PHP publicó versiones de emergencia para dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Según el repositorio operativo del NCSC de los Países Bajos, ambas permiten ejecución remota de código sin autenticación: una por corrupción de memoria durante la limpieza de la petición y otra por reutilización de estado global entre peticiones de un mismo worker. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
Lo más revelador no es el fallo, sino su alcance. PHP no solo corre en tu WordPress: viene empaquetado en aplicaciones, paneles de control y dispositivos de red. El propio NCSC-NL seguía a 28 de octubre 757 productos: 144 ya corregidos, 218 vulnerables y 354 todavía en investigación. Según Forkast, además, el fallo se encontró el 19 de agosto y se reportó el 24, es decir, pasaron casi dos meses hasta el parche.
Un matiz de rigor: varios análisis puntúan estas vulnerabilidades con un CVSS de 9,2, pero esa cifra no aparece en el repositorio del NCSC-NL y esa misma fuente no confirma explotación activa. Conviene desconfiar de las cifras llamativas sin fuente que circulan, como la de que afecta «al 70 % de internet».
Ese mismo día, GitLab lanzó parches para CVE-2026-110264. Según el análisis de SecurityOnline, tiene una puntuación CVSS de 10,0, se debe a un desbordamiento de enteros en el compilador de expresiones regulares y permite ejecutar código sin autenticarse. Afecta a las instancias autogestionadas desde la versión 7.0; las alojadas por GitLab ya estaban protegidas. Esa fuente indica que no consta explotación activa ni prueba de concepto pública, aunque otros resúmenes señalan que GitLab no ha detallado las condiciones exactas, así que lo prudente es parchear sin esperar.
Este es probablemente el caso más didáctico. El 21 de octubre, la versión 1.107.0 de LiteLLM, una herramienta muy usada para trabajar con modelos de IA, se publicó con código malicioso. Según el aviso oficial del proyecto, estuvo disponible en PyPI entre las 11:39 y las 13:23 UTC (unos 104 minutos) y en Docker Hub entre las 11:46 y las 14:20 UTC (unas dos horas y media).
¿Cómo llegó ahí? El atacante obtuvo tokens OAuth de la CLI de GitHub de desarrolladores, que se habían filtrado en los registros de una instancia interna expuesta a internet. Con ellos esquivó las protecciones de las ramas, redirigió el flujo de publicación a un repositorio falso de nombre casi idéntico y publicó los artefactos. El código robaba credenciales y cargaba herramientas de ejecución remota al arrancar Python, por lo que el aviso recomienda no limpiar con
Lo importante: el código fuente oficial en GitHub estaba limpio. El problema no estaba en el código, sino en la tubería que lo convierte en paquete.
El 17 de octubre, un investigador detectó que ocho certificados de autoridades intermedias de la empresa india eMudhra tenían claves privadas ridículamente débiles. Según Help Net Security, bastaba probar como máximo 256 valores para encontrarlas, por un script defectuoso en la ceremonia de generación de claves de abril de 2025. Quien las conociera podría fabricar certificados falsos para cualquier dominio y suplantar servidores.
Los navegadores reaccionaron rápido: eMudhra revocó los certificados el 18 de octubre y Chrome, Firefox, Apple y Microsoft retiraron la confianza en cuestión de días. El 22 de octubre la compañía anunció que abandonará el negocio global de certificados SSL/TLS y calcula que unos 30.000 certificados de clientes deberán reemplazarse. El riesgo restante está en lo que no se actualiza: aplicaciones, servidores y dispositivos que no reciben revocaciones. Y no se sabe si alguien aprovechó las claves durante los 17 meses anteriores.
Según el informe de Microsoft del 21 de octubre, un grupo alineado con el Estado chino, Storm-0940, comprometió el servicio Cloud Backup de ConnectWise y reutilizó credenciales de aplicaciones para entrar en entornos de clientes aprovechando la confianza ya establecida. Usó ARTEX, un framework de pentesting multiagente de código abierto que automatiza el proceso de reconocimiento a exfiltración.
Las cifras de Microsoft: intentos de inicio de sesión en más de 2.250 tenants de Microsoft 365 y en algunos casos menos de tres horas desde el objetivo inicial hasta el acceso privilegiado. La compañía subraya que la mayoría de intentos no tuvo éxito y que no hubo vulnerabilidad en sus productos.
A la lista se sumaron plataformas de despliegue. Railway avisó de que un intruso pudo acceder a secretos de clientes y recomendó rotar credenciales, mientras que Zeabur anunció su cierre tras dos brechas seguidas con más de tres millones de registros leídos. Aquí conviene ser prudentes: son relatos de las propias empresas recogidos por la prensa especializada.
Si miramos los cinco casos, ninguno es un «hackeo» clásico a un objetivo final. Son ataques a intermediarios de confianza:
No hace falta ser una gran empresa para aplicar lo esencial. Una lista corta y realista:
Black October no fue un mes extraordinario por lo que ocurrió, sino por lo que dejó a la vista. Las claves de eMudhra llevaban casi un año y medio siendo débiles. El fallo de PHP esperó casi dos meses a su parche. La tubería de LiteLLM se rompió por unos tokens olvidados en unos registros. No hubo un solo golpe maestro: hubo cosas pequeñas que nadie miraba.
Y ahí está la tesis: el perímetro de seguridad ya no está en tu cortafuegos, sino en todo aquello en lo que confías sin revisarlo: el paquete que instalas, el certificado que acepta tu navegador, el proveedor al que delegas el acceso. La IA acelera tanto a quien ataca como a quien defiende y en ese escenario la ventaja la tendrá quien tenga lo básico bien hecho: inventario, parches, secretos rotados y permisos mínimos.
Porque la próxima ola de divulgaciones llegará. La pregunta es si, cuando llegue, sabrás ya qué tienes instalado y en qué confías.
Cuando varios incidentes graves se acumulan en una semana, la tentación es pensar en una gran ofensiva coordinada. Los datos no apuntan a eso. Lo que ocurrió se parece más a un atasco de avisos que llevaban tiempo en la cola y que acabaron saliendo a la vez. Y eso, para quien mantiene un servidor, un proyecto o un simple blog, es una lección mucho más útil que el susto.
De dónde sale el nombre (y por qué conviene tomarlo con cautela)
La etiqueta Black October se ha extendido por medios y blogs de seguridad y según la entrada de Wikipedia la han usado cabeceras como CNBC, The Guardian o The Washington Post. Su origen, sin embargo, es difuso: Forkast la atribuye a un mensaje en X de la madrugada del 22 de octubre que calificaba las 48 horas anteriores como las peores de la historia de la ciberseguridad y reconoce que no ha conseguido localizar esa publicación.
Ese mismo análisis propone una lectura que merece la pena retener: no fue una ola de ataques, sino una ola de divulgaciones. Los fallos y las exposiciones llevaban meses (o años) ahí; lo que concentró octubre fue el momento en que se hicieron públicos. La etiqueta, dicen, esconde ese reloj.
Lo que pasó, incidente a incidente
1. PHP2Shell: dos fallos críticos en el lenguaje que mueve media web
El 21 de octubre, PHP publicó versiones de emergencia para dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Según el repositorio operativo del NCSC de los Países Bajos, ambas permiten ejecución remota de código sin autenticación: una por corrupción de memoria durante la limpieza de la petición y otra por reutilización de estado global entre peticiones de un mismo worker. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
Lo más revelador no es el fallo, sino su alcance. PHP no solo corre en tu WordPress: viene empaquetado en aplicaciones, paneles de control y dispositivos de red. El propio NCSC-NL seguía a 28 de octubre 757 productos: 144 ya corregidos, 218 vulnerables y 354 todavía en investigación. Según Forkast, además, el fallo se encontró el 19 de agosto y se reportó el 24, es decir, pasaron casi dos meses hasta el parche.
Un matiz de rigor: varios análisis puntúan estas vulnerabilidades con un CVSS de 9,2, pero esa cifra no aparece en el repositorio del NCSC-NL y esa misma fuente no confirma explotación activa. Conviene desconfiar de las cifras llamativas sin fuente que circulan, como la de que afecta «al 70 % de internet».
2. GitLab: un 10 sobre 10 en las instalaciones propias
Ese mismo día, GitLab lanzó parches para CVE-2026-110264. Según el análisis de SecurityOnline, tiene una puntuación CVSS de 10,0, se debe a un desbordamiento de enteros en el compilador de expresiones regulares y permite ejecutar código sin autenticarse. Afecta a las instancias autogestionadas desde la versión 7.0; las alojadas por GitLab ya estaban protegidas. Esa fuente indica que no consta explotación activa ni prueba de concepto pública, aunque otros resúmenes señalan que GitLab no ha detallado las condiciones exactas, así que lo prudente es parchear sin esperar.
3. LiteLLM: dos horas con un ladrón de credenciales dentro
Este es probablemente el caso más didáctico. El 21 de octubre, la versión 1.107.0 de LiteLLM, una herramienta muy usada para trabajar con modelos de IA, se publicó con código malicioso. Según el aviso oficial del proyecto, estuvo disponible en PyPI entre las 11:39 y las 13:23 UTC (unos 104 minutos) y en Docker Hub entre las 11:46 y las 14:20 UTC (unas dos horas y media).
¿Cómo llegó ahí? El atacante obtuvo tokens OAuth de la CLI de GitHub de desarrolladores, que se habían filtrado en los registros de una instancia interna expuesta a internet. Con ellos esquivó las protecciones de las ramas, redirigió el flujo de publicación a un repositorio falso de nombre casi idéntico y publicó los artefactos. El código robaba credenciales y cargaba herramientas de ejecución remota al arrancar Python, por lo que el aviso recomienda no limpiar con
pip, sino reconstruir los entornos y las imágenes desde cero.Lo importante: el código fuente oficial en GitHub estaba limpio. El problema no estaba en el código, sino en la tubería que lo convierte en paquete.
4. eMudhra: claves que se adivinan en 256 intentos
El 17 de octubre, un investigador detectó que ocho certificados de autoridades intermedias de la empresa india eMudhra tenían claves privadas ridículamente débiles. Según Help Net Security, bastaba probar como máximo 256 valores para encontrarlas, por un script defectuoso en la ceremonia de generación de claves de abril de 2025. Quien las conociera podría fabricar certificados falsos para cualquier dominio y suplantar servidores.
Los navegadores reaccionaron rápido: eMudhra revocó los certificados el 18 de octubre y Chrome, Firefox, Apple y Microsoft retiraron la confianza en cuestión de días. El 22 de octubre la compañía anunció que abandonará el negocio global de certificados SSL/TLS y calcula que unos 30.000 certificados de clientes deberán reemplazarse. El riesgo restante está en lo que no se actualiza: aplicaciones, servidores y dispositivos que no reciben revocaciones. Y no se sabe si alguien aprovechó las claves durante los 17 meses anteriores.
5. ConnectWise y Storm-0940: agentes de IA llamando a la puerta de 2.250 organizaciones
Según el informe de Microsoft del 21 de octubre, un grupo alineado con el Estado chino, Storm-0940, comprometió el servicio Cloud Backup de ConnectWise y reutilizó credenciales de aplicaciones para entrar en entornos de clientes aprovechando la confianza ya establecida. Usó ARTEX, un framework de pentesting multiagente de código abierto que automatiza el proceso de reconocimiento a exfiltración.
Las cifras de Microsoft: intentos de inicio de sesión en más de 2.250 tenants de Microsoft 365 y en algunos casos menos de tres horas desde el objetivo inicial hasta el acceso privilegiado. La compañía subraya que la mayoría de intentos no tuvo éxito y que no hubo vulnerabilidad en sus productos.
6. Más plataformas, mismo patrón
A la lista se sumaron plataformas de despliegue. Railway avisó de que un intruso pudo acceder a secretos de clientes y recomendó rotar credenciales, mientras que Zeabur anunció su cierre tras dos brechas seguidas con más de tres millones de registros leídos. Aquí conviene ser prudentes: son relatos de las propias empresas recogidos por la prensa especializada.
Qué tienen en común: ya no se ataca la puerta, se ataca la cadena
Si miramos los cinco casos, ninguno es un «hackeo» clásico a un objetivo final. Son ataques a intermediarios de confianza:
- Un lenguaje (PHP) del que dependen miles de productos.
- Una tubería de publicación (LiteLLM) de la que descargan paquetes miles de proyectos.
- Una autoridad de certificación (eMudhra) en la que confían los navegadores.
- Un proveedor de gestión (ConnectWise) con acceso delegado a los entornos de sus clientes.
- Plataformas de despliegue (Railway, Zeabur) que guardan los secretos de quienes alojan ahí sus apps.
Qué puedes hacer tú para protegerte
No hace falta ser una gran empresa para aplicar lo esencial. Una lista corta y realista:
- Haz inventario. No puedes parchear lo que no sabes que tienes. Comprueba la versión de PHP de tus servidores y, si usas hosting compartido, pregunta a tu proveedor si ya ha actualizado.
php -v - Actualiza a una versión corregida: PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 (o el paquete retroportado de tu distribución). Si usas GitLab autogestionado, actualiza a la versión parcheada de tu rama.
- Fija las versiones de tus dependencias y verifica su integridad. Evita etiquetas flotantes como
latesten Docker y usa lockfiles con hashes:pip install --require-hashes -r requirements.txt - Rota los secretos expuestos. Si algún entorno ejecutó la versión afectada de LiteLLM, o usas plataformas que guardan variables de entorno con claves, cámbialas. Mejor aún: usa un gestor de secretos y claves con el mínimo privilegio.
- Revisa las aplicaciones de terceros con acceso delegado. En Microsoft 365 o Entra ID, audita qué integraciones tienen permisos sobre tu organización y quita las que no uses.
- Mantén actualizado el almacén de certificados de sistemas y dispositivos, no solo del navegador, y activa MFA o, mejor, passkeys en las cuentas que gestionan todo lo anterior.
Conclusión: el reloj ya estaba en marcha
Black October no fue un mes extraordinario por lo que ocurrió, sino por lo que dejó a la vista. Las claves de eMudhra llevaban casi un año y medio siendo débiles. El fallo de PHP esperó casi dos meses a su parche. La tubería de LiteLLM se rompió por unos tokens olvidados en unos registros. No hubo un solo golpe maestro: hubo cosas pequeñas que nadie miraba.
Y ahí está la tesis: el perímetro de seguridad ya no está en tu cortafuegos, sino en todo aquello en lo que confías sin revisarlo: el paquete que instalas, el certificado que acepta tu navegador, el proveedor al que delegas el acceso. La IA acelera tanto a quien ataca como a quien defiende y en ese escenario la ventaja la tendrá quien tenga lo básico bien hecho: inventario, parches, secretos rotados y permisos mínimos.
Porque la próxima ola de divulgaciones llegará. La pregunta es si, cuando llegue, sabrás ya qué tienes instalado y en qué confías.
