José Zegarra“Black October”: revisemos en profundidad la masiva oleada de fallos y ataques ultra avanzados que golpeó Internet desde el 21 de octubre del 2026
Lima Perú, 23 de octubre de 2026.— En apenas 48-72 horas a partir del 21 de octubre de 2026, la infraestructura web y las plataformas de desarrollo vivieron una concentración inusual de vulnerabilidades críticas, compromisos de cadena de suministro y fallos de confianza que recordaron episodios como Heartbleed o Log4Shell. Informes de las agencias de ciberseguridad (NSA, CISA y la ASD australiana), medios y conversaciones en la red social X describieron el periodo como uno de los más intensos para la ciberseguridad reciente, con avisos de “tomar sistemas offline” y rotación masiva de secretos. Fuente:X
El incidente de mayor potencial alcance fue el PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Durante el 20 al 21 de octubre, el equipo de PHP anunció y publicó parches de emergencia (versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12, más backports para ramas antiguas). Se trata de dos fallos de corrupción de memoria (use-after-free y manejo incorrecto de condiciones out-of-memory) en el núcleo de PHP, vinculados al mecanismo session.upload_progress y al parsing de peticiones multipart. Como sabemos, estos permiten ejecución remota de código no autenticada en el proceso del servidor web (mod_php es especialmente afectado; también FPM y otros). PHP es el lenguaje detrás de una gran parte de los sitios web a nivel global (WordPress, Drupal, Laravel, etc.). La NSA y la CISA emitieron alertas urgentes recomendando parcheo inmediato o desconexión temporal. Hubo filtraciones previas a la divulgación coordinada y reportes de intentos de explotación (incluido antes de que muchos administradores pudieran actualizar). No se trató de un fallo de aplicación, sino del motor PHP escrito en el lenguaje C. Fuente: Research.jfrog
El mismo 21 de octubre, GitLab publicó parches para CVE-2026-110264 (CVSS 10.0). Es un desbordamiento de entero en el compilador de expresiones regulares (Onigmo, motor de Ruby integrado en GitLab) que, bajo ciertas condiciones, permite a un usuario no autenticado ejecutar código arbitrario en instancias self-managed. Afecta a todas las versiones desde GitLab 7.0 (2014). Se aplicaron backports inusuales a ramas antiguas. No hay, hasta el momento de estos reportes, confirmación de explotación masiva en la naturaleza, pero la severidad y el alcance histórico la convierten en prioritaria para entornos autoalojados. Fuente: Cve
En paralelo, la autoridad de certificación hindú eMudhra sufrió un fallo grave en la generación de claves. Ocho certificados intermedios (TLS y code-signing) tenían claves privadas débiles —enteros pequeños, uno de ellos literalmente el número 4—, recuperables en milisegundos. El origen fue un error en una ceremonia de generación de claves (KGC) de abril de 2025 con HSMs, que produjo claves débiles publicadas por error. No hubo compromiso de infraestructura ni robo clásico: las claves eran efectivamente públicas. Chrome, Firefox, Apple y Microsoft las bloquearon rápidamente. eMudhra anunció su salida del negocio TLS global. El impacto potencial era la posibilidad de emitir certificados falsos para sitios web o firmar código, erosionando la confianza en HTTPS. Fuente: Ars Technica
La cadena de suministro de plataformas de desarrollo y herramientas de IA también fue golpeada:
- LiteLLM (proxy/gateway popular de modelos de lenguaje): el 21 de octubre se publicó una versión maliciosa 1.107.0 en PyPI y Docker con malware que robaba credenciales y cargaba herramientas de ejecución remota. El pipeline de releases fue comprometido (tokens de GitHub robados, posiblemente vía logs o herramientas de desarrollo). Se retiró en horas; se recomendó rotar secretos a quienes la instalaran. Fuente: Docs.litellm
- Railway: divulgó acceso no autorizado a sistemas que almacenan variables de entorno de clientes (API keys, contraseñas de bases de datos, etc.), con posible descifrado en algunos casos. Recomendó rotación general. La empresa lo vinculó a una serie de ataques contra plataformas orientadas a proveedores de inferencia de IA.
- Zeabur: brecha que expuso datos de ~321.810 cuentas y más de 3,2 millones de registros de variables de entorno. El atacante usó credenciales administrativas de larga vida almacenadas en texto plano y interfaces de gestión accesibles. La plataforma anunció el cierre a finales de 2026.
Otros elementos reportados incluyen alertas críticas en productos Fortinet, malware en servidores de Onamae Desktop Cloud (hasta ~27,000 clientes en Japón), interrupciones en Ahold Delhaize (cadenas de supermercados) y el uso de frameworks de agentes de IA (como ARTEX por el actor alineado con China Storm-0940 en el incidente de ConnectWise Cloud Backup, o herramientas como Cairn en campañas de intrusión automatizada).
Table of Contents
¿Qué es CVE-2026-109618 y CVE-2026-109619?
CVE-2026-109618 y CVE-2026-109619 (conocidos conjuntamente como PHP2Shell) son dos vulnerabilidades críticas de ejecución remota de código (RCE) no autenticada en el núcleo de PHP. Fuente: Research.jfrog
Se divulgaron y parchearon el 21 de octubre de 2026. Ambas tienen una puntuación CVSS aproximada de 9.2 (crítica) y permiten a un atacante remoto, sin autenticación, ejecutar código arbitrario en el proceso del servidor web que ejecuta PHP. Fuente: Exploitr
Detalles técnicos
- CVE-2026-109618: Corrupción de memoria relacionada con el manejo de errores out-of-memory (OOM). PHP usa
longjmp()para abortar el procesamiento de una petición cuando se agota la memoria. En ciertas condiciones (durante el parsing de peticiones multipart/form-data), esto deja el estado de la petición en una condición inválida que puede aprovecharse para RCE.Censys - CVE-2026-109619: Use-after-free por estado global obsoleto (stale global state). PHP mantiene referencias a memoria propiedad de una petición anterior que ya fue liberada. Una petición posterior atendida por el mismo worker puede usar esas referencias antes de que se reinicialice el estado, provocando corrupción de memoria y posible RCE. Está ligado al mecanismo
session.upload_progress(activado por defecto) y, en PHP 8.5, también a backtraces de errores fatales. Fuente: Threatwire
Ambas son fallos de seguridad de memoria en el motor de PHP (escrito en lenguaje C), no en el código de las aplicaciones que corren encima. Por eso afectan a cualquier aplicación PHP expuesta a la red (WordPress, Drupal, Laravel, Joomla, etc.), independientemente de que el código de la aplicación esté actualizado.
Versiones afectadas y solución
Afectan a múltiples ramas de PHP (desde versiones antiguas hasta las 8.x). Las versiones corregidas oficiales son:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
También se publicaron backports para ramas más antiguas (7.4, 8.0, 8.1). El parche debe aplicarse a nivel del runtime de PHP y se recomienda reiniciar los workers (mod_php, PHP-FPM, etc.) para que surta efecto. Fuente: Fossa
Patrones objetivos
En estos ataques ultra avanzados predominan objetivos con fallos de memoria y lógica en lenguajes y motores ampliamente desplegados (PHP/C, Ruby/Onigmo), errores de proceso en generación de claves criptográficas y compromisos de pipelines de publicación (supply chain). Las atribuciones concretas a actores estatales o criminales son limitadas en estos días (excepto referencias a Storm-0940); muchos son bugs de software o fallos operativos que cualquier atacante puede explotar una vez divulgados. El uso de la Inteligencia Artificial aparece tanto en el descubrimiento de vulnerabilidades como en la aceleración de ataques (agentes autónomos, password spraying a alta velocidad).
Para un artículo periodístico, la cobertura debe distinguir claramente: vulnerabilidades de software (con parches disponibles), fallos de proceso (eMudhra), brechas confirmadas por los proveedores y reportes de explotación en curso. Las recomendaciones prácticas de las agencias son el parcheo urgente de PHP y GitLab self-managed, la rotación de secretos en plataformas afectadas y la vigilancia de intentos de explotación. La oleada ilustra la dependencia continua de componentes críticos (motores web, certificados, pipelines de distribución) y la velocidad con la que un fallo se convierte en superficie de ataque global.
¿Qué significa CVE?
CVE significa Common Vulnerabilities and Exposures (en español: Vulnerabilidades y Exposiciones Comunes). Es un sistema de identificación estandarizado y público de vulnerabilidades de ciberseguridad. Cada CVE es un identificador único (como CVE-2026-109618) que permite referirse a un fallo de seguridad concreto de forma consistente en todo el mundo, independientemente del fabricante, la base de datos o el idioma.
Cómo funciona
-
Formato:
CVE-AAAA-NNNNNAAAA= año en que se asignó el identificador (no necesariamente el año en que se descubrió o se parcheó).NNNNN= número secuencial único.
- Quién lo gestiona: La organización MITRE, bajo el programa patrocinado por el Departamento de Seguridad Nacional de Estados Unidos (DHS) y la CISA.
-
Para qué sirve:
- Unificar el nombre de una vulnerabilidad entre diferentes bases de datos (NVD, vendor advisories, etc.).
- Facilitar el intercambio de información entre investigadores, empresas y administradores.
- Asociar la vulnerabilidad a una puntuación de gravedad (normalmente mediante CVSS).
Ejemplo concreto
Cuando hablamos de CVE-2026-109618 y CVE-2026-109619 (PHP2Shell), esos identificadores apuntan a dos fallos específicos de ejecución remota de código en el núcleo de PHP. Cualquier persona o sistema puede buscar exactamente esa vulnerabilidad usando el número CVE, sin ambigüedades. En resumen: un CVE viene a ser el “número de serie” oficial y público de una vulnerabilidad conocida.
Conclusión
La oleada de incidentes detectada a partir del 21 de octubre de 2026 —con PHP2Shell (CVE-2026-109618 y CVE-2026-109619) como caso más grave— evidencia una vez más la fragilidad de componentes fundamentales de Internet. Se trata de fallos de corrupción de memoria en el núcleo de PHP, un lenguaje que sigue sustentando una porción muy significativa de la web, y que permiten ejecución remota de código sin autenticación.
Aunque los parches se publicaron el mismo día de la divulgación, la naturaleza de estas vulnerabilidades (bugs de seguridad de memoria en un runtime escrito en C), su amplia superficie de ataque y la velocidad con la que se observaron intentos de explotación demuestran que el tiempo entre la revelación y la aplicación efectiva del parche sigue siendo una ventana crítica. El episodio se inserta en un patrón más amplio de fallos en software de uso masivo, bibliotecas críticas y cadenas de suministro, donde un solo error en un componente de infraestructura puede tener consecuencias sistémicas.
Al tratarse de una noticia en desarrollo, es probable que en los próximos días aparezcan nuevas pruebas de explotación, variantes o vulnerabilidades relacionadas. La situación ilustra tanto la madurez de los mecanismos de divulgación coordinada como los límites prácticos de la aplicación de parches a escala global.
Recomendaciones
- Actualización prioritaria de PHP Aplicar de inmediato las versiones corregidas (8.5.12, 8.4.27, 8.3.36, 8.2.35 o los backports correspondientes para ramas anteriores). Reiniciar los procesos (PHP-FPM, mod_php, etc.) tras la actualización. Si no es posible actualizar de forma inmediata, valorar el aislamiento o la desconexión temporal de los servicios expuestos a Internet.
- Monitorización activa Revisar logs de acceso y de errores en busca de patrones anómalos de peticiones multipart/form-data, intentos de explotación conocidos y actividad inusual en workers de PHP. Considerar el uso de herramientas de detección de comportamiento o WAF con reglas actualizadas para estas CVE.
- Inventario y reducción de superficie Identificar todos los sistemas que ejecutan PHP (incluyendo contenedores, entornos de desarrollo y servicios de terceros). Eliminar o desactivar funcionalidades innecesarias (por ejemplo,
session.upload_progresssi no se utiliza) y restringir el acceso a interfaces administrativas. - Preparación y respuesta Disponer de planes de respuesta a incidentes actualizados y de copias de seguridad verificadas. En entornos críticos, aplicar el principio de mínimo privilegio a los procesos de PHP y segmentar la red para limitar el movimiento lateral en caso de compromiso.
- Seguimiento de fuentes oficiales Consultar de forma continua los avisos de los mantenedores de PHP, NVD, CISA y los proveedores de distribución (Linux, paneles de hosting, etc.). Dado que la noticia sigue en evolución, evitar basar decisiones únicamente en informes no oficiales o en información preliminar de redes sociales.
- Reflexión a medio plazo Las organizaciones que dependen fuertemente de PHP deberían evaluar estrategias de diversificación tecnológica, adopción de lenguajes con mejores garantías de seguridad de memoria en componentes críticos, y mejoras en los procesos de gestión de dependencias y actualización continua.
Estas medidas no eliminan el riesgo, pero reducen de forma significativa la probabilidad de compromiso mientras la situación continúa desarrollándose. La prioridad inmediata sigue siendo la aplicación de los parches disponibles y la vigilancia activa de los sistemas expuestos.
- PHP2Shell (CVE-2026-109618 y CVE-2026-109619) evidencia la fragilidad de componentes centrales de Internet: fallos de corrupción de memoria en el núcleo de PHP permiten ejecución remota de código sin autenticación y afectan a una gran parte de la web.
- Aunque los parches se publicaron el 21 de octubre, la ventana entre la divulgación y la aplicación efectiva sigue siendo crítica, con intentos de explotación ya observados; se trata de una noticia en desarrollo en la que pueden surgir nuevas variantes o pruebas de compromiso.
- Actualizar de inmediato a las versiones corregidas de PHP (8.5.12, 8.4.27, 8.3.36, 8.2.35 o backports) y reiniciar los workers es la medida prioritaria; si no es posible, aislar o desconectar temporalmente los servicios expuestos.
- Monitorizar logs en busca de actividad anómala, realizar un inventario de todos los sistemas que ejecutan PHP y restringir funcionalidades innecesarias para reducir la superficie de ataque.
- Mantener vigilancia continua de fuentes oficiales (PHP, NVD, CISA) y reforzar planes de respuesta a incidentes, mientras se evalúan a medio plazo estrategias de actualización continua y diversificación tecnológica.
Tu Opinión Nos Importa
Como responsable de ciberseguridad qué opinas de este tipo de ataque ultra avanzados, ¿consideras que tu organización está preparada para este tipos de contingencias? Comenta siempre con nuestros hashtags #itusersawards2026 y #superfan
Apoya al Periodismo Independiente
¿Te sirvió en algo este contenido?, ayúdanos a combatir la Desinformación, dona desde S/ 1.00 a nuestro PLIN 943-438-457
