Entre el lunes 19 y el miércoles 21 de octubre de 2026, internet tuvo una de esas semanas que los equipos de tecnología recuerdan por años. Se publicaron dos fallas críticas en el corazón de PHP, el lenguaje con el que funciona el 69,3% de los sitios web cuyo lenguaje de servidor se conoce, según W3Techs. El mismo día, Node.js liberó diez correcciones de seguridad, una de ellas de ejecución remota de código, y alguien inyectó código malicioso en LiteLLM, una herramienta abierta que muchas empresas usan para conectar sus aplicaciones con distintos modelos de IA. TechCrunch lo resumió con un titular que pocos olvidarán: internet está teniendo un muy mal día de ciberseguridad.
Los tres incidentes no tienen relación entre sí, y eso es justamente lo que los vuelve interesantes para quien dirige una empresa. Cada uno golpea una capa distinta del stack tecnológico, cada uno exige una respuesta en horas y no en semanas, y en al menos dos de ellos aparece un actor nuevo en la historia de la seguridad informática: la inteligencia artificial que encuentra fallas en el código antes de que lo haga una persona. Este artículo explica qué pasó con el detalle técnico necesario, lo traduce para quien no es ingeniero y propone qué debería revisar un directorio o una gerencia esta misma semana.
QUÉ PASÓ CON PHP, EXPLICADO SIN JERGA
PHP es el motor que corre detrás de WordPress, de buena parte de los ecommerce de la región y de miles de portales corporativos, intranets y sistemas internos. Cuando alguien visita una página hecha en PHP, el servidor ejecuta un pequeño programa que arma esa página en milisegundos y la entrega al navegador. Para hacerlo rápido, el servidor mantiene procesos de trabajo (los llamados workers) que atienden una petición tras otra sin reiniciarse cada vez.
Las dos fallas, registradas como CVE-2026-109618 y CVE-2026-109619, viven precisamente en esa maquinaria. La primera aparece cuando PHP se queda sin memoria a mitad de una petición: el manejo de ese error puede interrumpir el proceso con datos internos a medio inicializar, y la limpieza posterior los trata como si fueran válidos. La segunda tiene que ver con estado interno que sobrevive a una petición después de que su memoria fue liberada, de modo que la siguiente petición atendida por el mismo worker puede usar esa información obsoleta antes de que se reinicie. Así lo describe el propio aviso del equipo de seguridad de PHP.
Dicho en simple, un atacante puede enviar peticiones fabricadas con cuidado para provocar esos estados raros de la memoria y, a partir de ahí, ejecutar código propio en el servidor sin necesidad de usuario ni contraseña. Por eso ambas recibieron una puntuación CVSS v4.0 de 9,2 sobre 10 y la categoría de críticas. Según el análisis publicado por Google Cloud, están presentes en todas las versiones desde PHP 5.4 hasta la 8.5.11, lo que significa que el error convivió más de una década con millones de sitios sin que nadie lo notara.
Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las ramas 8.1 y anteriores ya no reciben actualizaciones oficiales; el equipo de PHP publicó parches mínimos de código fuente para 7.4, 8.0 y 8.1, pensados para quien compila por su cuenta, y Google fue directo en su recomendación: las aplicaciones en PHP 8.1 o anteriores siguen vulnerables y deben migrar a 8.2 o superior. El equipo de PHP agregó una frase que vale la pena leer dos veces, porque resume la situación: no hay mitigaciones completas y actualizar es la única opción segura.
UNA CRONOLOGÍA QUE SE ADELANTÓ A SÍ MISMA
La secuencia de fechas, reconstruida por Tenable, muestra lo difícil que es hoy mantener un secreto técnico. El 17 de octubre, cuatro días antes de la publicación oficial, Amazon Threat Intelligence detectó un intento de explotación contra uno de sus señuelos de monitoreo. El 20 de octubre los identificadores de las fallas circularon en un foro y PHP publicó un aviso anticipado de la actualización. El parche estaba programado para el 22, pero se adelantó al 21 de octubre a las 14:00 UTC precisamente porque la información ya estaba en la calle.
Ese mismo día, la agencia estadounidense de ciberseguridad CISA pidió a las organizaciones actualizar de inmediato, partiendo por los sistemas expuestos a internet, y sacar de línea los que no pudieran actualizarse. Según el reporte de Reuters que cita TechCrunch, sitios de gobiernos en distintos países quedaron fuera de servicio mientras se aplicaban los parches. La pregunta de si las fallas ya se estaban explotando a gran escala tuvo respuestas distintas según la fuente: Amazon habló de explotación amplia, Cloudflare de ataques tempranos y CISA, al momento de su alerta, de que aún no la había observado. Para efectos de gestión, la conclusión práctica es la misma, porque una falla de este calibre con detalles públicos se trata como si ya estuviera siendo atacada.
LA IA YA ENCUENTRA LAS FALLAS
Lo verdaderamente nuevo de esta semana está en quién encontró los errores. La PHP Foundation reconoció a Calif, OpenAI y Wiz, entre otros, por la investigación y la divulgación responsable, y tanto Calif como Wiz declararon que usaron modelos de IA en su trabajo. Google fue más explícito en su blog: Wiz usó una combinación de modelos para identificar y ayudar a corregir las vulnerabilidades, y Gemini 4 Argon hizo, en sus palabras, una contribución invaluable a encontrar la falla, desarrollar el exploit de prueba, detectar ataques y validar el parche.
En Node.js pasó algo parecido. El boletín de seguridad del 21 de octubre corrigió diez vulnerabilidades, cuatro de severidad alta, y la más grave, una escritura fuera de límites en el decodificador Brotli que permitía ejecución remota de código, fue reportada por OpenAI Codex Security junto a dos investigadores humanos. Es decir, en la misma semana, dos de los entornos que sostienen la mayor parte de la web moderna recibieron correcciones críticas encontradas con ayuda de modelos de IA.
Esto cambia la economía de la seguridad de una forma que conviene entender bien. Durante décadas, encontrar una falla profunda en un lenguaje como PHP exigía semanas de trabajo de especialistas muy escasos, y esa escasez funcionaba, sin que nadie lo planificara, como una barrera de protección. Hoy un modelo puede leer cientos de miles de líneas de código, razonar sobre estados de memoria improbables y proponer un caso de prueba en horas. Esa misma capacidad está disponible para defensores y para atacantes, y TechCrunch lo advirtió al cierre de su nota: la IA puede hacer más fácil que los atacantes exploten una vulnerabilidad una vez que se conoce.
La lectura optimista, que compartimos, es que esta semana la IA trabajó del lado de los defensores: encontró las fallas, ayudó a escribir los parches y los validó antes de que hubiera un desastre mayor. La lectura exigente es que el tiempo entre que una falla se publica y que alguien la explota se está acortando, y que las empresas que actualizan cada trimestre van a quedar expuestas en ventanas cada vez más largas en relación con la velocidad del atacante.
LOS OTROS DOS FRENTES: NODE.JS Y LITELLM
Node.js es el entorno que ejecuta JavaScript en servidores, y está detrás de muchos sitios modernos, aplicaciones y herramientas internas. Junto al error de Brotli, el boletín corrigió dos formas de saltarse la verificación del nombre del servidor en conexiones TLS, que es la comprobación que asegura que un sistema está hablando con quien cree que está hablando. Las versiones corregidas son 26.12.1, 24.22.1 y 22.23.4. En la misma actualización, Node.js retiró de su lista de certificados de confianza un certificado intermedio de eMudhra, una autoridad certificadora de India cuyas llaves privadas, según TechCrunch, fueron comprometidas, lo que habría permitido emitir certificados falsos para suplantar sitios legítimos.
LiteLLM es otra historia y probablemente la más reveladora para un área de Marketing o de producto. Se trata de un proxy de código abierto que permite a una aplicación conectarse a varios proveedores de modelos de lenguaje con una sola interfaz, y se volvió muy popular entre equipos que construyen agentes y automatizaciones. Según TechCrunch, el 21 de octubre un atacante logró publicar versiones con código malicioso en PyPI, Docker Hub y el registro de contenedores de GitHub. El código incluía un ladrón de información diseñado para extraer credenciales de nube, contraseñas y llaves de servicios de IA, y venía acompañado de un troyano de acceso remoto. LiteLLM retiró las versiones y publicó una guía de remediación para quienes las hubieran instalado.
El caso de LiteLLM muestra una capa del stack que muchas empresas todavía no miran con lupa: las herramientas que conectan la empresa con la IA. Esas piezas suelen instalarse rápido, muchas veces por un equipo pequeño que está probando algo nuevo, y concentran justamente las llaves más valiosas, porque una llave de API de un proveedor de IA conectada a datos de clientes vale mucho para un atacante.
QUÉ CAPA DEL STACK TOCÓ CADA INCIDENTE
La forma más útil de leer esta semana es por capas. Un incidente en el lenguaje del servidor se gestiona distinto que uno en una librería o en la cadena de confianza de los certificados, y cada capa tiene un dueño distinto dentro de la empresa.
| Incidente | Capa del stack | Qué arriesga la empresa | Pregunta para la gerencia |
|---|---|---|---|
| PHP (CVE-2026-109618 y 109619) | Lenguaje del servidor web | Toma de control del sitio, del ecommerce o de la intranet sin contraseña | ¿Qué sitios corren PHP, en qué versión, y quién los actualiza? |
| Node.js (10 fallas, 4 altas) | Entorno de ejecución de aplicaciones | Ejecución remota de código y conexiones que creen hablar con el servidor correcto sin hacerlo | ¿Qué aplicaciones usan Node.js y en qué rama de versiones? |
| LiteLLM | Herramientas de IA y librerías de terceros | Robo de llaves de nube, de proveedores de IA y de contraseñas | ¿Quién instala librerías de IA y con qué credenciales funcionan? |
| eMudhra | Cadena de confianza de certificados | Sitios falsos que parecen legítimos ante navegadores y sistemas | ¿Nuestros sistemas actualizan sus listas de certificados de confianza? |
Cuando se mira así, aparece algo que en nuestra experiencia se repite mucho: casi ninguna empresa tiene una sola persona que pueda responder las cuatro preguntas. El sitio institucional lo administra una agencia, el ecommerce un proveedor, la intranet el área de TI y los pilotos de IA un equipo de innovación o de Marketing. La falla de PHP no distingue entre esas fronteras organizacionales y entra por la que esté más descuidada.
POR QUÉ ESTO TAMBIÉN ES UN TEMA DE MARKETING
Puede parecer que la seguridad del servidor es asunto exclusivo de TI, pero en la práctica el área de Marketing es dueña de una parte enorme de la superficie expuesta de una empresa. Los sitios de campaña, las landings que se levantan en una tarde, el blog en WordPress, los plugins que se instalan para un formulario, el gestor de etiquetas, el CRM conectado al sitio y, cada vez más, las automatizaciones con IA que leen y escriben datos de clientes. En una revisión típica del stack de MarTech, como la que describimos en nuestra guía de MarTech por tamaño de empresa, aparecen decenas de herramientas, y varias de ellas corren sobre PHP sin que el equipo lo sepa.
La confianza, por su parte, es un activo de marca. Un sitio comprometido puede redirigir visitantes a páginas fraudulentas, robar datos de un formulario de contacto o servir malware a los propios clientes, y el daño reputacional llega antes que el informe técnico. Los datos propios que una empresa construye con años de trabajo, y que explicamos como ventaja competitiva en la ingeniería del dato propio en la era de la IA, valen exactamente lo que vale la seguridad de los sistemas que los guardan.
LO QUE DEBERÍA REVISAR UN LÍDER ESTA SEMANA
La primera tarea es un inventario honesto. CISA recomienda empezar por identificar todos los sistemas que corren cualquier versión de PHP, incluyendo el PHP que viene empaquetado dentro de otro software, y priorizar los que están expuestos a internet. Un gerente no necesita hacer ese inventario personalmente, pero sí puede pedirlo con un plazo de horas y con un formato simple: sitio o sistema, proveedor responsable, versión de PHP y fecha de actualización comprometida.
La segunda tarea es preguntar por los proveedores. Muchos sitios corporativos viven en hostings administrados donde el proveedor actualiza PHP, y otros viven en servidores donde nadie lo hace a menos que se lo pidan. Vale la pena escribir hoy mismo a cada agencia, hosting y proveedor de software preguntando si ya aplicaron las versiones corregidas y pidiendo una confirmación por escrito. En los servicios gestionados en la nube, Google detalló que algunas plataformas se parchan solas y otras requieren volver a desplegar la aplicación con la imagen actualizada, una diferencia que conviene confirmar caso a caso.
La tercera tarea es mirar los sistemas antiguos con valentía. Las ramas 8.1 y anteriores de PHP no tienen parche oficial, y los sitios que siguen en esas versiones, que suelen ser los que nadie quiere tocar porque funcionan, quedaron expuestos sin una solución simple. La recomendación oficial es migrar a 8.2 o superior, y mientras eso ocurre, CISA sugiere sacar el sistema de línea o protegerlo detrás de un firewall de aplicaciones web como medida temporal.
La cuarta tarea apunta a la capa de IA. Si la empresa usa librerías como LiteLLM o cualquier otra pieza que conecte aplicaciones con modelos de lenguaje, alguien debería poder responder qué versiones están instaladas, desde dónde se descargan y con qué llaves funcionan. Una práctica sana es que esas llaves tengan el mínimo de permisos necesario, que roten periódicamente y que estén separadas por proyecto, de modo que un robo afecte una sola iniciativa y no todo el ecosistema.
La quinta tarea es acordar un tiempo de respuesta. Una forma práctica de bajar todo esto a la gestión es definir, para cada nivel de severidad, cuántas horas o días puede pasar entre la publicación de un parche y su aplicación en los sistemas de la empresa, y medir ese número cada mes. Lo que no se mide se negocia en cada crisis, y en una semana como esta la negociación se hace con el reloj en contra.
EL CAMBIO DE FONDO: SEGURIDAD A VELOCIDAD DE MÁQUINA
Si uno se aleja de los detalles técnicos, la semana deja una tendencia clara. La misma IA que hoy ayuda a escribir código, como explicamos en qué IA usar según tu rol, también se está volviendo una herramienta extraordinaria para auditarlo. Las fallas que dormían durante años en código maduro van a aparecer más rápido, en mayor cantidad y con exploits de prueba más elaborados, y eso significa que las empresas van a recibir más alertas críticas que nunca.
Esa abundancia de hallazgos es, en el largo plazo, una muy buena noticia. Un software con menos fallas escondidas es un internet más seguro para todos, y la IA está haciendo en meses una limpieza que a la industria le habría tomado décadas. La condición es que las organizaciones tengan la capacidad de absorber esa velocidad: inventarios al día, proveedores que responden en horas, ambientes que se pueden actualizar sin miedo y equipos que entienden qué parte del stack les pertenece.
Hay una analogía útil con lo que pasó en Marketing con la automatización de medios. Cuando las plataformas empezaron a decidir pujas en milisegundos, los equipos que siguieron revisando campañas una vez por semana quedaron atrás, y los que ganaron fueron los que rediseñaron su forma de trabajar para operar al ritmo de la máquina, con reglas claras y con personas concentradas en las decisiones que importan. La seguridad está entrando en esa misma etapa. El criterio humano sigue siendo el que define prioridades y asume riesgos, una idea que desarrollamos en la capa de decisión, pero la ejecución de los parches y la vigilancia de los sistemas tienen que acercarse a la velocidad con la que hoy se descubren las fallas.
También vale la pena una reflexión sobre la dependencia. Un sitio corporativo moderno descansa sobre capas de software abierto mantenidas por comunidades pequeñas, desde el lenguaje hasta la librería de compresión y la autoridad que firma los certificados. Esta semana esas comunidades respondieron con una rapidez admirable, con avisos anticipados, parches para versiones antiguas y guías detalladas. Las empresas que se benefician de ese trabajo tienen un rol que jugar, ya sea manteniendo sus versiones al día, reportando problemas o apoyando a las fundaciones que sostienen las piezas de las que dependen.
UNA CONVERSACIÓN PARA EL DIRECTORIO
Para un directorio, la pregunta de fondo que deja esta semana va más allá de si el sitio ya está parchado. La pregunta es si la empresa sabe con precisión qué software sostiene su operación digital, quién es responsable de cada pieza y cuánto tarda en reaccionar cuando una de ellas falla. Esa respuesta suele estar repartida entre TI, Marketing, operaciones y una lista de proveedores, y ordenarla es una tarea de gestión antes que de tecnología.
Las empresas que salgan bien paradas de esta etapa van a ser las que traten su stack como un activo vivo, con dueño, inventario y tiempos de respuesta medidos, y que usen la misma IA que hoy encuentra fallas para revisar su propio código, sus configuraciones y sus dependencias antes de que lo haga otro. La semana del 19 al 21 de octubre mostró que esa capacidad ya existe y que está disponible para cualquiera. La ventaja la va a tener quien la ponga a trabajar primero de su lado.