Black October: la semana que sacudió la ciberseguridad | Quantyx

Black October: la semana de vulnerabilidades críticas que cambió las reglas de la ciberseguridad

Hay semanas que quedan en la historia de la ciberseguridad. Heartbleed en 2014, WannaCry en 2017, Log4Shell en 2021. La tercera semana de octubre de 2026 ya tiene nombre propio en la industria: Black October.

En pocos días se publicaron fallas críticas en PHP, Fortinet, Node.js, GitLab, Java, el kernel de Linux y la librería de imágenes más usada de Python. A eso se sumaron certificados de seguridad comprometidos, una herramienta de IA usada para robar credenciales y plataformas de desarrollo que expusieron millones de claves de sus clientes. Solo entre el 21 y el 22 de octubre, el CSIRT Nacional de Chile publicó seis alertas de vulnerabilidad crítica.

The Hacker News lo resumió así el 22 de octubre: “Esta semana ya ha sido dura para la ciberseguridad… y la semana ni siquiera ha terminado”.

En este artículo repasamos qué pasó, por qué no fue una coincidencia, qué tiene que ver la inteligencia artificial, cuáles son los riesgos de la nueva era de enjambres de agentes de IA y qué deberían hacer hoy las empresas en Chile. Si quieres el detalle de la falla más grave de la semana, lee nuestra guía sobre PHP2Shell.

Qué es “Black October”

“Black October” es el nombre con el que medios y analistas de seguridad se refieren al grupo de divulgaciones críticas publicadas entre el 19 y el 22 de octubre de 2026.

Un matiz importante, que destacan SecurityToday y Yahoo Tech: no se trata necesariamente de una ola nueva de ataques, sino de una ola de divulgaciones. Muchas de las fallas llevaban años en el código y varios incidentes ya estaban en curso desde semanas o meses antes. Lo que cambió fue que todo salió a la luz casi al mismo tiempo.

Eso tiene una consecuencia práctica: la fecha en que se publica una vulnerabilidad no es la fecha en que empezó el riesgo.

Las alertas del CSIRT Nacional

Entre el 21 y el 22 de octubre de 2026, el CSIRT Nacional de la ANCI emitió seis alertas de vulnerabilidad crítica, todas con TLP:CLEAR (información de difusión pública):

Las alertas están dirigidas especialmente a prestadores de servicios esenciales y operadores de importancia vital, pero sus recomendaciones aplican a cualquier organización que use esas tecnologías.

Qué pasó, capa por capa

1. La web: PHP2Shell

La falla más grave de la semana. Dos vulnerabilidades en el núcleo de PHP, el lenguaje que usan cerca del 70% de los sitios web cuyo lenguaje de servidor es conocido, permiten ejecutar código sin iniciar sesión y leer memoria con contraseñas, tokens y claves de API. Afectan a casi todas las versiones desde PHP 5.4 y se demostraron contra WordPress, Drupal y Joomla.

Hubo intentos de explotación antes de la divulgación, y gobiernos europeos desconectaron sus sitios de forma preventiva. El investigador Kevin Beaumont advirtió a Help Net Security que la situación “llevará a una masa de incidentes”, y el experto forense Hal Pomeranz anticipó “una cola larga” por la cantidad de instalaciones olvidadas que nunca se van a actualizar.

Actualización del 23 de octubre: una nueva advertencia de PHP. Dos días después del parche de emergencia, PHP publicó un aviso informativo sobre una nueva falla, CVE-2026-115560, que también podría permitir ejecutar código en un servidor web. Es distinta de PHP2Shell y no la corrigen las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

La buena noticia es que solo afecta a una configuración poco común. Debe pasar todo esto a la vez:

• la aplicación define session.serialize_handler como php_binary o php_serialize;
• luego lo cambia a php mientras se ejecuta, con ini_set();
• hace ese cambio antes de llamar a session_start();
• y la función de progreso de carga de sesiones (session upload progress) sigue activa, que es lo que viene por defecto.

PHP considera que este escenario es poco probable, así que no publicará un parche de emergencia: la corrección llegará en la próxima versión regular. Mientras tanto, recomienda una sola línea de configuración: session.upload_progress.enabled=0. Es la misma mitigación que ya se sugería para PHP2Shell, así que si la aplicaste el 21 de octubre y la mantuviste, no tienes que hacer nada más. PHP todavía no ha dicho qué versiones están afectadas ni qué gravedad tiene, y no se han reportado ataques que la exploten.

Mientras tanto, los ataques contra PHP2Shell siguen aumentando. Según Sophos y Arctic Wolf, los atacantes han intentado usar esas fallas para instalar una variante de la botnet Mirai. Por ahora, Wordfence y otros reportan escaneos e intentos, pero ninguna ejecución de código confirmada, y los investigadores dicen que construir un exploit confiable está resultando más difícil de lo esperado. Eso no es motivo para relajarse: lo que hoy falla, mañana puede funcionar.

Todo el detalle está en nuestra guía PHP2Shell: qué es y qué hacer.

2. El perímetro: Fortinet

Fortinet publicó el 22 de octubre actualizaciones que, según la empresa, deben implementarse de inmediato en FortiOS, FortiManager, FortiAnalyzer, FortiMail y FortiAuthenticator. Son equipos de seguridad perimetral muy usados por empresas e instituciones en Chile.

El CSIRT recomienda:

• Identificar todas las instancias, priorizando las expuestas a internet.
• Respaldar las configuraciones antes de actualizar.
• Revisar los logs en busca de accesos administrativos inusuales o cambios no aprobados.
• Si no se puede actualizar, restringir las interfaces de administración (HTTPS, SSH) a IP de confianza o deshabilitarlas en interfaces externas, y asegurar que FortiManager no sea accesible desde internet.

Que fallen los equipos que deberían proteger la red es un recordatorio de que ninguna capa es infalible.

3. La confianza: certificados de eMudhra

Un investigador descubrió que las llaves privadas de ocho certificados intermedios de la autoridad certificadora india eMudhra eran números menores a 256, cuando debían ser números aleatorios enormes. Cualquiera podía calcularlas casi al instante. Con esas llaves, un atacante podría hacerse pasar por sitios web legítimos.

• Chrome y Firefox bloquearon los seis certificados intermedios para sitios web en cuestión de horas.
• Mozilla decidió el 20 de octubre dejar de confiar en la raíz afectada, y Chrome hará lo mismo a partir del 27 de octubre (hora del Pacífico).
• Según el conteo de Chrome, cerca de 30.800 certificados vigentes dependían de esa raíz.
• eMudhra anunció que saldrá del negocio global de certificados SSL/TLS.
• Oracle publicó una alerta de seguridad para Java (CVE-2026-91403) que deja de confiar en esos certificados intermedios en Java SE y GraalVM.

La ANCI recomienda a los usuarios mantener actualizados el sistema operativo, el navegador y las aplicaciones, y a los administradores actualizar el paquete de certificados raíz.

4. El código: Node.js, Python y GitLab

• Node.js corrigió 10 fallas en sus versiones 22.x, 24.x y 26.x. La más seria está en el decodificador Brotli e investigadores de Imperva demostraron ejecución de código (“Node2Shell”) en una versión oficial. Las versiones 20.x y anteriores ya no reciben parches.
• Pillow, la librería de imágenes más usada de Python (unas 436 millones de descargas al mes, según OX Security), corrigió fallas críticas en su versión 13.0.0. Algunas permiten ejecutar código al abrir una imagen manipulada, algo muy común en formularios de carga y procesos de IA.
• GitLab corrigió dos fallas de gravedad máxima (CVSS 10.0) en octubre: CVE-2026-97229, el día 13, y CVE-2026-110264, el 22, que permite a un usuario no autenticado ejecutar código en el servidor.
• Laravel, uno de los frameworks PHP más populares, corrigió una falla crítica (CVSS 9.2) que permitía autenticarse como otro usuario en su API.
• GitLab y Ruby. GitLab corrigió dos fallas de gravedad máxima (CVSS 10.0) en octubre: CVE-2026-97229, el día 13, y CVE-2026-110264, el 22, que permite a un usuario no autenticado ejecutar código en el servidor. El 23 de octubre se supo el origen: errores en Onigmo, el motor de expresiones regulares de Ruby, que GitLab usa para compilar patrones que escriben sus usuarios, por ejemplo en la configuración de CI/CD. Un patrón manipulado podía corromper la memoria mientras Ruby lo compilaba y terminar en ejecución remota de código. GitLab había publicado cuatro CVE por estos problemas (CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 y CVE-2026-110264) y los parchó en su propia copia de Ruby. Ahora Ruby publicó las correcciones para todos: Ruby 4.0.9, 3.4.12 y 3.3.13.

El riesgo no se limita a GitLab. Según el aviso de Ruby, afecta a cualquier aplicación Ruby que compile expresiones regulares a partir de texto que controla un usuario, por ejemplo con Regexp.new, Regexp.union o /#{input}/. Las aplicaciones que solo usan expresiones escritas por sus propios desarrolladores no están afectadas. Ojo: Regexp.timeout no protege contra estos errores, y limitar el largo del patrón tampoco, porque algunos se activan con patrones cortos. Además, Ruby no ha solicitado CVE propios, así que algunos escáneres podrían no marcarlo. El mismo aviso recomienda rastrearlo con los CVE de GitLab.

5. La infraestructura: Linux

Dos fallas con puntuación 9.0 en KSMBD, el servidor SMB integrado en el kernel de Linux, permiten ejecución remota de código. Una de ellas no requiere autenticación. Al 22 de octubre no había parche en el kernel principal. Las encontró TrendAI, el escáner de IA de Trend Micro.

6. La cadena de suministro de la IA

Esta es quizás la parte más reveladora de la semana:

• LiteLLM, una librería muy usada para conectar aplicaciones con modelos de IA, sufrió el compromiso de su proceso de publicación. El 21 de octubre se distribuyó en PyPI y Docker una versión maliciosa (1.107.0) con un ladrón de credenciales y una puerta trasera que buscaba secretos de sistemas, navegadores, nube y herramientas de IA.
• Railway, una plataforma para desplegar aplicaciones, informó que un intruso pudo acceder a variables de entorno de clientes (donde se guardan claves de API y contraseñas de bases de datos). La empresa cree que el ataque es parte de una serie dirigida a plataformas, con el objetivo final de comprometer a proveedores de inferencia de IA.
• Zeabur, otra plataforma de desarrollo, anunció su cierre tras un segundo ataque en el que se robaron más de 3,2 millones de registros de variables de entorno y datos de 321.810 cuentas.
• PingCAP confirmó el robo de código fuente y de información de clientes con credenciales de servicio robadas.
• OpenCode, un agente de programación con IA, tenía una falla que permitía a un servidor MCP (los conectores que dan herramientas externas a los agentes) malicioso o secuestrado ejecutar código en el equipo del desarrollador. Se corrigió sin CVE ni aviso de seguridad, así que los escáneres no lo detectan.

Por qué todo pasó al mismo tiempo: la IA como acelerador

Que tantas fallas graves aparecieran juntas no es casualidad. Varias fueron descubiertas con ayuda de inteligencia artificial:

• PHP2Shell: Wiz las encontró usando su plataforma Wiz Atlas y modelos de frontera. Según Wiz, demostrar que eran explotables requería pasos “en el límite de lo que investigadores humanos podían lograr”, y la IA “redujo sustancialmente esa barrera”.
• Pillow: una de las fallas fue “encontrada por Anthropic usando Claude”, como parte de un esfuerzo que ha revelado cientos de fallas en librerías de código abierto.
• Linux KSMBD: las encontró TrendAI, un escáner de IA.

La comunidad ya se está adaptando. La documentación de seguridad del kernel de Linux, actualizada en mayo de 2026, establece que los bugs encontrados por herramientas de IA deben considerarse públicos por definición. Desde el 1 de mayo, el NCSC del Reino Unido recomienda a todas las organizaciones prepararse para una “ola de parches”, porque la IA en manos capaces puede explotar la deuda técnica rápido y a gran escala.

El tiempo entre parche y ataque ahora se mide en horas

• Amazon detectó un intento de explotación de PHP2Shell cuatro días antes de su publicación.
• Según Cloudflare, los intentos pasaron de decenas de miles en los 45 minutos posteriores al anuncio a millones en la madrugada del 22 de octubre.
• En GitLab, una falla anterior de gravedad máxima recibió sondeos a las pocas horas de su divulgación.

Amazon lo resume así: la IA abarata convertir un parche en un exploit funcional, por lo que los plazos de parcheo para fallas críticas en sistemas expuestos deben medirse en horas, no en 7 o 30 días.

La nueva era: riesgos de los enjambres de agentes de IA

Las empresas están pasando de usar un asistente de IA a desplegar enjambres de agentes: varios agentes que se coordinan entre sí, usan herramientas, leen correos, escriben código, consultan bases de datos y ejecutan acciones. Es una revolución de productividad, como explicamos en agentes de IA para operaciones de marketing. Black October mostró también su lado de riesgo.

1. Cada agente es una identidad con llaves

Un agente necesita claves de API, tokens y permisos para hacer su trabajo. Un enjambre multiplica esas llaves. Los casos de LiteLLM, Railway y Zeabur muestran que los atacantes están yendo directo por los secretos de IA y de la nube, porque una sola clave puede abrir muchos sistemas o generar enormes costos de uso (una práctica conocida como LLMjacking).

2. La cadena de suministro se vuelve más larga

Los agentes dependen de librerías, conectores MCP, plugins y servicios de terceros. Si cualquiera de ellos se compromete, como LiteLLM o un servidor MCP secuestrado en el caso de OpenCode, el agente ejecuta el ataque con los permisos de la empresa.

3. Instrucciones ocultas (prompt injection)

Un agente que lee páginas web, correos o documentos puede recibir instrucciones maliciosas escondidas en ese contenido. Si un sitio comprometido por PHP2Shell inserta texto pensado para agentes, estos pueden filtrar información o realizar acciones no autorizadas.

4. Acciones a velocidad de máquina

Un error humano afecta a un sistema. Un agente con permisos amplios puede repetir el error cientos de veces en minutos. En un enjambre, un agente comprometido puede influir en los demás.

5. Poca trazabilidad

Muchas organizaciones no registran qué hizo cada agente, con qué permisos y por instrucción de quién. Sin esos registros, investigar un incidente es casi imposible.

6. Los atacantes también usan enjambres

La misma tecnología permite a los atacantes escanear internet, identificar versiones vulnerables, adaptar exploits y lanzar campañas a gran escala, con mucho menos esfuerzo humano.

7. Agentes que se salen de su tarea

El 22 de octubre, la NSA, CISA y el NIST de Estados Unidos publicaron lineamientos para detectar, contener y apagar agentes de IA que se desvíen de sus tareas aprobadas, con foco en mantener la supervisión humana. Que las principales agencias de seguridad publiquen este tipo de guías muestra que el riesgo ya no es teórico.

Buenas prácticas para trabajar con agentes

• Inventario de agentes: qué agentes existen, qué hacen y quién es responsable de cada uno.
• Mínimo privilegio: cada agente con los permisos justos para su tarea.
• Credenciales separadas por agente y por servicio, con límites de gasto y rotación periódica.
• Secretos en un gestor seguro, nunca en texto plano ni en el código.
• Revisión de conectores y dependencias (MCP, librerías, plugins) antes de instalarlos, fijando versiones.
• Aprobación humana para acciones sensibles: pagos, envíos masivos, cambios en producción, borrado de datos.
• Registro de cada acción del agente, con trazabilidad.
• Botón de apagado: poder desactivar un agente o un enjambre de inmediato.
• Separar el contenido externo de las instrucciones, para reducir el riesgo de prompt injection.
• Pruebas de seguridad específicas para agentes antes de pasarlos a producción.

En Quantyx aplicamos estos principios cuando diseñamos agentes, automatizaciones e integraciones, incluidos los flujos de WhatsApp Business con IA.

La importancia de estar siempre actualizado

Black October deja una lección muy concreta: la seguridad de una empresa depende de todo lo que usa, no solo de lo que programa. PHP, Node.js, Java, Python, Linux, el firewall, los certificados y las librerías de IA son capas que casi ninguna empresa controla directamente, pero de las que todas dependen.

Lo que significa “estar actualizado” hoy

Checklist de higiene de actualizaciones

• Inventario completo de sitios, servidores, equipos de red, aplicaciones, librerías y servicios en la nube.
• Saber qué versión de cada componente está en uso.
• Usar solo versiones con soporte oficial (por ejemplo, PHP 8.2 o superior; Node.js 22 o superior).
• Suscribirse a las alertas del CSIRT Nacional y de los proveedores clave.
• Definir plazos de parcheo por criticidad: horas para lo crítico expuesto a internet.
• Respaldos automáticos y pruebas de restauración.
• Firewall de aplicaciones web (WAF) como capa adicional, no como reemplazo.
• Fijar versiones de dependencias y revisar sus actualizaciones.
• Rotar secretos después de cualquier incidente o exposición posible.
• Eliminar sitios, cuentas, plugins y servicios que ya no se usan.

Un equipo de TI siempre alerta

En una semana como esta, la diferencia entre una empresa afectada y una protegida no fue el tamaño del presupuesto, sino la capacidad de reaccionar rápido. Eso requiere personas, procesos y herramientas.

Qué necesita un equipo de TI preparado

1. Responsables claros. Saber quién decide parchar, quién decide desconectar un sistema y a quién se avisa.
2. Monitoreo de alertas. Alguien que lea a diario los avisos del CSIRT, de los proveedores y de las fuentes especializadas.
3. Plan de respuesta a incidentes escrito y probado: qué hacer en la primera hora, en el primer día y en la primera semana.
4. Capacidad de actuar fuera de horario. Las fallas no se publican en horario de oficina chileno.
5. Visibilidad. Logs centralizados, alertas de comportamiento anómalo y monitoreo de los sistemas expuestos.
6. Relación con proveedores. Contactos directos con el hosting, el proveedor de nube y los fabricantes de equipos de seguridad.
7. Simulacros. Practicar escenarios como “una falla crítica en el lenguaje de nuestro sitio” antes de que pase.
8. Comunicación. Saber qué informar a clientes, usuarios y autoridades, y cuándo.

¿Y si no tengo equipo de TI propio?

Muchas pymes no tienen un equipo interno, y no es necesario tenerlo para estar protegidas. Lo importante es que alguien tenga la responsabilidad explícita de mantener todo actualizado y responder ante alertas: un proveedor de hosting administrado, una agencia de desarrollo o un servicio externo de seguridad. Pregunta hoy a tu proveedor:

• ¿Quién actualiza PHP, Node.js y el sistema operativo de mi sitio?
• ¿Cuánto se demoraron en aplicar los parches de esta semana?
• ¿Tengo respaldos recientes y probados?
• ¿Quién me avisa si mi sitio es atacado?

Si nadie puede responder, ese es el primer riesgo a resolver.

El marco legal en Chile

La Ley Marco de Ciberseguridad (Ley 21.663) creó la ANCI y obliga a los prestadores de servicios esenciales y operadores de importancia vital a gestionar riesgos y reportar incidentes significativos, con una alerta temprana dentro de las 3 horas siguientes. Para esas organizaciones, una semana como Black October no es solo un problema técnico: es una obligación legal de gestión de riesgo.

La ciberseguridad como rubro en crecimiento

Black October también muestra algo más amplio: la ciberseguridad pasó de ser un área técnica a un rubro estratégico para la economía.

La brecha de talento

• La ANCI estima que Chile tiene una brecha de unos 28.000 especialistas en ciberseguridad, que tardaría cerca de una década en cerrarse.
• La estimación gubernamental citada en la Política Nacional de Ciberseguridad 2023-2028 calcula una demanda de unos 63.500 profesionales en 2026.
• La OCDE encontró que la demanda de profesionales de ciberseguridad en Chile creció 28,7% entre 2021 y 2022, frente a 2,9% del resto de las profesiones: casi diez veces más.
• Según el estudio de fuerza laboral de ISC2 de 2024, América Latina tiene una escasez de unos 328.000 especialistas, y la brecha global supera los 4,7 millones de puestos.
• Además, parte del talento latinoamericano trabaja de forma remota para Estados Unidos, lo que hace todavía más difícil contratar a nivel local, según El Economista.

El contexto de amenazas en Chile

• La ANCI recibió 324 reportes de incidentes entre enero y junio de 2026, unos 54 ciberataques de efecto significativo al mes.
• El CSIRT Nacional identificó la explotación de aplicaciones expuestas a internet como una de las técnicas de acceso inicial más observadas en el primer trimestre de 2026, justo el tipo de ataque que permiten PHP2Shell, GitLab o Fortinet.

Qué significa para las empresas

• La seguridad ya es un costo de operar, como la contabilidad o los seguros.
• Los clientes y socios preguntarán más. En licitaciones, auditorías y contratos B2B, demostrar buenas prácticas de seguridad será cada vez más un requisito.
• El talento escasea, así que conviene combinar personal interno, proveedores especializados y automatización con supervisión.
• La seguridad debe estar en el diseño, no agregarse al final: en el sitio web, en las integraciones y en los agentes de IA.
• Hay oportunidad: para profesionales que se especializan, para empresas que ofrecen servicios de seguridad y para organizaciones que convierten su madurez en seguridad en una ventaja competitiva.

Qué hacer esta semana: checklist para empresas

Hoy

• Revisar las seis alertas del CSIRT Nacional y confirmar si usas alguno de los productos.
• Actualizar PHP, o pedir confirmación escrita al hosting de que ya lo hizo.
• Desactivar la función de progreso de carga de sesiones en PHP (session.upload_progress.enabled=0) hasta que salga la corrección de CVE-2026-115560, salvo que tu aplicación la necesite.
• Actualizar Fortinet y restringir las interfaces de administración.
• Revisar las versiones de Node.js, Java, GitLab y Pillow si las usas.
• Actualizar navegadores, sistemas operativos y paquetes de certificados.
• Si tienes aplicaciones en Ruby (por ejemplo, Ruby on Rails), actualizar a Ruby 4.0.9, 3.4.12 o 3.3.13. Si no puedes, evitar compilar expresiones regulares con texto que ingresan los usuarios.

Esta semana

• Si usaste LiteLLM el 21 de octubre, revisar si instalaste la versión 1.107.0 y rotar todas las credenciales del equipo afectado.
• Si usas Railway u otras plataformas afectadas, rotar variables de entorno y claves de API.
• Revisar los logs desde antes de cada anuncio, por ejemplo desde el 17 de octubre en el caso de PHP.
• Rotar claves de servidores que estuvieron expuestos sin parche.
• Revisar los agentes de IA, conectores MCP y herramientas de programación con IA en uso.

Este mes

• Hacer el inventario completo de tecnología y versiones.
• Definir responsables y plazos de parcheo por criticidad.
• Escribir o actualizar el plan de respuesta a incidentes.
• Revisar los permisos de agentes e integraciones.
• Planificar la migración de todo lo que esté fuera de soporte.

Para usuarios: qué hacer

Si no administras sistemas, no tienes que parchar servidores, pero sí puedes protegerte:

• Actualiza tu navegador, sistema operativo y aplicaciones. Así recibes, entre otras cosas, el bloqueo de los certificados de eMudhra.
• Usa contraseñas distintas en cada servicio y un gestor de contraseñas.
• Activa la verificación en dos pasos en correo, banco y redes sociales.
• Desconfía de mensajes urgentes que se aprovechan de la noticia: “actualiza tu cuenta”, “descarga este parche”, “tu sitio fue hackeado”.
• No instales aplicaciones ni archivos enviados por mensajes o anuncios, aunque parezcan de entidades oficiales.
• Si un servicio informa una filtración, cambia tu contraseña de inmediato.
• Ante fraudes o incidentes, contacta al CSIRT Nacional al 1510 o en ayuda@anci.gob.cl.

Cómo te ayuda Quantyx

En Quantyx desarrollamos y mantenemos sitios, integraciones y agentes de IA para empresas. Después de Black October podemos ayudarte a:

• Hacer un inventario de tus sitios, servidores, dependencias e integraciones.
• Revisar y actualizar PHP, Node.js y otros componentes, coordinando con tu proveedor de hosting.
• Migrar lo que esté fuera de soporte, probando que todo siga funcionando.
• Rotar secretos y revisar cómo se guardan las claves de API.
• Revisar los permisos y conectores de tus agentes de IA y automatizaciones.
• Definir un plan de mantenimiento y respuesta para que la próxima vez la reacción tome horas.

Conoce nuestro trabajo en desarrollo personalizado y en agentes, automatizaciones e integraciones.

Preguntas frecuentes

¿Qué es Black October?

Es el nombre que la industria de la ciberseguridad le dio a la ola de divulgaciones críticas publicadas entre el 19 y el 22 de octubre de 2026, que incluyó PHP2Shell, fallas en Fortinet, Node.js, GitLab, Java, Linux y Pillow, el compromiso de certificados de eMudhra y ataques a la cadena de suministro de herramientas de IA.

¿Fue un ataque coordinado?

No. Fue una concentración de divulgaciones de fallas distintas. Algunas llevaban años en el código, y algunos incidentes ya estaban en curso desde antes. La IA aceleró el descubrimiento de varias de ellas.

¿Qué es lo más urgente?

Actualizar PHP si tu sitio lo usa, actualizar los equipos Fortinet y revisar las demás alertas del CSIRT Nacional. Luego, rotar credenciales en sistemas que pudieron estar expuestos.

¿Ya actualicé PHP, estoy protegido de todo?

De PHP2Shell sí, pero el 23 de octubre PHP advirtió de otra falla (CVE-2026-115560) que esas versiones no corrigen. Solo afecta a una configuración poco común, y se mitiga desactivando la función de progreso de carga de sesiones (session.upload_progress.enabled=0) hasta la próxima versión regular de PHP.

¿Por qué la IA aumenta el riesgo?

Porque permite encontrar fallas y convertir parches en exploits mucho más rápido. Además, los agentes de IA agregan nuevas credenciales, conectores y permisos que los atacantes pueden aprovechar.

¿Qué es un enjambre de agentes?

Es un conjunto de agentes de IA que trabajan coordinados, cada uno con tareas, herramientas y permisos. Pueden automatizar procesos completos, pero también multiplican los puntos de entrada si no se gestionan con mínimo privilegio, trazabilidad y supervisión humana.

¿Mi pyme necesita un equipo de ciberseguridad?

No necesariamente uno interno, pero sí alguien con la responsabilidad clara de mantener todo actualizado y responder ante alertas, ya sea un proveedor de hosting administrado, una agencia o un servicio externo.

¿Dónde veo las alertas oficiales en Chile?

En el sitio de alertas del CSIRT Nacional.

Conclusión

• Black October fue una ola de divulgaciones críticas en PHP, Fortinet, Node.js, GitLab, Ruby, Java, Linux, Pillow y certificados, más ataques a la cadena de suministro de la IA.
• El CSIRT Nacional publicó seis alertas críticas en dos días.
• La IA aceleró tanto el descubrimiento de fallas como su explotación: los plazos de parcheo ahora se miden en horas.
• Los enjambres de agentes de IA abren una nueva superficie de ataque: credenciales, conectores, instrucciones ocultas y acciones a velocidad de máquina.
• Estar actualizado y tener un equipo de TI alerta, propio o externo, ya no es opcional.
• La ciberseguridad es un rubro estratégico y en crecimiento, con una brecha de talento de miles de especialistas en Chile.

Si quieres revisar cómo quedó tu empresa después de Black October, cuéntanos tu caso y respondemos en menos de 24 horas hábiles.

Fuentes

CSIRT Nacional (ANCI)

• AVC26-00740: PHP – Vulnerabilidades Críticas
• AVC26-00741: Fortinet – Vulnerabilidad Crítica
• AVC26-00742: eMudhra – Vulnerabilidad Crítica
• AVC26-00743: Node.js – Vulnerabilidad Crítica
• AVC26-00744: GitLab – Vulnerabilidad Crítica
• AVC26-00745: Oracle Java – Vulnerabilidad Crítica
• ANCI: Brecha de especialistas en ciberseguridad

Fabricantes

• Oracle: Security Alert CVE-2026-91403
• Oracle Security Blog

The Hacker News

• PHP warns of another unpatched code execution flaw
• ThreatsDay: AI Secrets Leak, PingCAP Source Theft y más
• eMudhra to exit global SSL/TLS business
• Node.js Brotli decoder bug could allow RCE
• Researchers demonstrate Node2Shell RCE
• LiteLLM suspects GitHub token leak
• OpenCode flaw lets malicious MCP server run code
• Railway says intruder may have accessed environment variables
• Two CVSS 9.0 Linux KSMBD RCE flaws
• GitLab patches CVSS 10.0 flaw
• Critical flaw in Python's Pillow

Análisis y contexto

• Ruby: Regexp compilation fixes related to GitLab's CVEs
• SecurityToday: Black October, many attacks had been running for months
• Yahoo Tech: Black October is a disclosure wave
• Wiz: PHP2Shell
• Help Net Security: PHP2Shell
• AWS Security Blog: PHP2Shell exploitation prior to public disclosure
• WebThreat: Black October 2026, what leaked and what to rotate
• OCDE: Building a Skilled Cyber Security Workforce in Latin America
• El Economista: Déficit de trabajadores de ciberseguridad en América Latina

Actualizado: 23 de octubre de 2026, con el aviso de PHP sobre CVE-2026-115560. Esta es una situación en desarrollo; revisa las alertas del CSIRT Nacional y los avisos oficiales de cada fabricante para obtener la información más reciente. Este artículo es informativo y no reemplaza una evaluación técnica de tus sistemas Actualizado: 23 de octubre de 2026, con el aviso de PHP sobre CVE-2026-115560 y las correcciones de Ruby vinculadas a los CVE de GitLab. Esta es una situación en desarrollo; revisa las alertas del CSIRT Nacional y los avisos oficiales de cada fabricante para obtener la información más reciente. Este artículo es informativo y no reemplaza una evaluación técnica de tus sistemas.