«Octubre negro»: fuimos a los informes originales y casi ningún número coincide

Durante la segunda quincena de octubre circuló la idea de que la ciberseguridad vivía sus peores días y que una ofensiva de agentes de inteligencia artificial estaba golpeando Internet. Fuimos a leer los avisos oficiales y los informes originales de quienes investigaron cada caso. La mayoría de las cifras que se repitieron no está en ellos.

Conviene decir de entrada que sí ocurrieron cosas serias, y que hay una acción concreta que atender. Pero lo que se contó y lo que los documentos sostienen no son lo mismo, y la diferencia cambia qué debería hacer una empresa esta semana.

De dónde salió el nombre

"Octubre negro" no es una denominación oficial. No la emitió ninguna agencia de ciberseguridad. Es una etiqueta que se popularizó en redes sociales a partir del 22 de octubre, cuando varios incidentes independientes coincidieron en las noticias.

El origen importa porque fija el tono de todo lo que vino después. Una etiqueta nacida de la coincidencia periodística terminó leyéndose como si describiera una campaña única y orquestada.

La vulnerabilidad de PHP: lo que sí está confirmado

El 21 de octubre el proyecto PHP publicó versiones que corrigen dos vulnerabilidades críticas: CVE-2026-109618 y CVE-2026-109619. El aviso de PHP las califica con una puntuación CVSS v4.0 de 9.2 cada una, que es territorio crítico.

Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

Para una empresa, el número de la vulnerabilidad no es lo relevante. Lo relevante son tres cosas:

No requiere contraseña. Tanto PHP como CERT-EU describen el efecto como ejecución remota de código sin autenticación. No hace falta tener una cuenta ni haber entrado antes.

No es un problema del sitio, sino del motor que lo ejecuta. Cloudflare lo dice sin rodeos: como las fallas están en el entorno de ejecución de PHP, actualizar el código del sitio o sus complementos no las corrige. Wiz, uno de los equipos que las encontró, va más lejos y señala que la explotación no depende de una falla en el código de la aplicación: incluso una aplicación mínima, sobre una versión afectada, puede ser vulnerable.

El riesgo no es igual en todas las instalaciones. PHP indica que están en riesgo todas las instalaciones que atienden peticiones web, y que considera el riesgo más alto en la configuración conocida como mod_php, donde se demostró un ataque que se dispara antes de que corra una sola línea del código de la aplicación.

Hay una tercera vulnerabilidad, CVE-2026-115560, divulgada el 23 de octubre. El propio PHP la describe como un vector improbable que solo puede ocurrir bajo una combinación inusual de configuración y código. No merece el mismo nivel de alarma que las dos anteriores.

Un dato de calendario que conviene anotar: PHP 8.2 deja de recibir soporte el 31 de diciembre de 2026. Las ramas 8.1 y anteriores ya no reciben actualizaciones del proyecto.

Lo que no está confirmado

Aquí la historia pública se separa de los documentos.

Nadie ha documentado una víctima. Ninguno de los cuatro avisos primarios —PHP, CERT-EU, Cloudflare y Wiz— documenta explotación exitosa con víctimas identificadas. CERT-EU señala que la circulación de pruebas de concepto eleva la probabilidad de que ya se esté explotando. Es una inferencia prudente de un organismo serio, no un hecho observado.

Los "millones de intentos" no están en el blog de Cloudflare. Cloudflare escribió que desplegó mitigaciones para todos sus clientes y que observó tráfico de ataque. En ese texto no aparece ninguna cifra de intentos, ni periodo de observación, ni afirmación de haber visto un solo compromiso.

El "70% de Internet afectado" mezcla dos cosas distintas. Ese 70% es la cuota de uso de PHP entre los sitios cuyo lenguaje de servidor se puede identificar. No es un conteo de sitios vulnerables, que nadie ha hecho. Usar la cuota de mercado como medida de exposición convierte "usan PHP" en "están afectados", y son cosas diferentes.

Vale la pena añadir un matiz del propio Wiz, que trabaja a favor de la calma: los fallos de memoria son complejos, y un ataque que funciona contra una instalación puede requerir ajustes sustanciales para funcionar contra otra.

Los ataques "con inteligencia artificial"

Tres investigaciones distintas se agruparon bajo el mismo paraguas. Esto es lo que se publicó y lo que dice cada informe:

Esto no significa que no haya pasado nada. Microsoft sí documenta actividad posterior en múltiples entornos de clientes, y casos en los que el atacante obtuvo acceso privilegiado a la infraestructura en la nube de una organización en menos de tres horas. Eso es grave y está medido. Simplemente no es lo mismo que 2,250 organizaciones caídas.

Sobre México hay un dato que sí conviene conocer: Straiker documenta que el grupo que investigó tenía en su inventario credenciales relacionadas con SPEI, el sistema de pagos interbancarios mexicano, y 903 números de cuenta CLABE. El informe dice que ese acceso podría permitir el abuso de SPEI. Habla de riesgo potencial; no documenta un uso exitoso.

Lo que la inteligencia artificial sí cambió

Esta es la parte que más se distorsionó, y los propios informes son notablemente sobrios al respecto.

Ninguno afirma que la IA haya hecho posible algo que antes fuera imposible. Todos hablan de velocidad, escala o costo.

Microsoft describe técnicas conocidas desde hace años —ataques de contraseñas y abuso de permisos delegados— y dice que el atacante usó la herramienta para acelerarlas a velocidad de máquina. NorForge señala que el uso de marcos de ataque con IA estaba establecido mucho antes de su informe. Straiker es explícito: no reclama esos elementos como nuevos.

La diferencia práctica no es que existan ataques nuevos. Es que el margen entre que se divulga una falla y que alguien la aprovecha se está acortando, y que tareas que antes requerían a una persona experta ahora se pueden encargar en paralelo por unos cuantos dólares.

Y una vuelta de tuerca que casi nadie contó

La vulnerabilidad de PHP la encontró una inteligencia artificial, pero del lado de la defensa.

Wiz documenta que dio con la primera el 19 de agosto de 2026 usando sus propias herramientas de inteligencia artificial, y el hallazgo se coordinó con el equipo de PHP antes de hacerse público. La corrección estuvo lista el día de la divulgación.

La historia de fondo, entonces, no es que la inteligencia artificial haya atacado Internet. Es que la inteligencia artificial está encontrando, en cimientos que llevaban más de una década en pie, fallas que nadie había visto. Eso va a seguir pasando, y va a pasar de los dos lados.

El incidente más instructivo del mes no tuvo nada de inteligencia artificial

Entre todo lo que se publicó en octubre, el caso que más le enseña a una empresa promedio es el de LiteLLM, una herramienta de software ampliamente usada.

Según su propio informe, el 21 de octubre su sistema de publicación distribuyó una versión comprometida del paquete, que estuvo disponible alrededor de dos horas antes de ser retirada.

¿Cómo entraron? Con una llave maestra que alguien subió a un repositorio público el 27 de mayo y que nunca se revocó. Cinco meses después seguía siendo válida. Con ella obtuvieron el acceso de un administrador de la organización, extrajeron credenciales de los sistemas de integración y publicaron la versión maliciosa usando permisos robados de otros mantenedores.

Ni agentes autónomos, ni vulnerabilidades de día cero. Una credencial expuesta y no revocada.

Qué le toca a su empresa

De todo lo anterior salen cuatro acciones concretas, en orden de urgencia:

Cómo leer el próximo "octubre negro"

Va a haber otro. Cuando llegue, tres preguntas separan la información de la alarma:

La ciberseguridad se gestiona con criterio, no con sobresaltos. Y el criterio casi siempre está a un clic del aviso original.