Actualización PHP2Shell: confirman ataques exitosos y CISA lo suma a KEV

Provectis
28/10/2026
•
Vulnerabilidad crítica

Síntesis

Las fallas críticas de PHP conocidas como PHP2Shell pasaron de los intentos masivos a la explotación comprobada: se confirmaron ejecuciones reales en servidores trampa y la CISA de Estados Unidos las sumó a su catálogo de fallas explotadas.

  • Vulnerabilidades: CVE-2026-109618 y CVE-2026-109619, CVSS 9.2, ejecución remota de código sin autenticación.
  • 35 shells confirmadas el 24 de octubre en honeypots con PHP 8.4.26 sobre Apache mod_php.
  • CISA las incorporó al catálogo KEV el 26 de octubre, con plazo al 29 para agencias federales.
  • Versiones corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

Qué pasó

El 21 de octubre el proyecto PHP publicó un aviso de seguridad con parches para dos errores del motor del lenguaje: uno en el manejo de falta de memoria y otro que deja estado interno reutilizable entre solicitudes. El aviso advierte que el riesgo es mayor en Apache con mod_php, donde el ataque se activa antes de que corra el código de la aplicación.

Durante días hubo millones de intentos sin éxito confirmado. El sábado 24, Adel Karimi, investigador de Perplexity, publicó un informe técnico con 35 shells abiertas en tres de sus servidores señuelo. La actividad vino de dos direcciones IP, filtró memoria y luego ejecutó comandos de reconocimiento. El patrón es consistente con CVE-2026-109618; el informe no demuestra el uso de la segunda falla.

El lunes 26, CISA agregó ambas al catálogo KEV, según BleepingComputer y Security Affairs. BleepingComputer, con datos de VirusTotal, estima más de 5,1 millones de servidores PHP expuestos. Sobre las dos fallas, el proyecto fue claro: "No hay mitigaciones completas, actualizar es la única opción segura".

En Chile, el CSIRT Nacional de la ANCI publicó el 26 de octubre una guía de mitigación para organizaciones que no pueden actualizar de inmediato. El documento recuerda que las ramas 8.1 y anteriores no tendrán parches y estima que la explotación automatizada es difícil por las diferencias entre entornos, aunque advierte que eso puede cambiar rápido.

Qué significa para una empresa en Chile

PHP sostiene WordPress, Joomla, Drupal, Nextcloud, desarrollos en Laravel o Symfony e intranets de muchas empresas medianas, a menudo en hostings externos o a cargo de agencias que nadie audita. Con código de ataque público y explotación confirmada, un servidor web vulnerable puede entregar credenciales de bases de datos, datos de clientes o acceso a la red interna si no hay segmentación. El CSIRT agrega un punto clave: con PHP 8.1 o anterior no basta con parchar, porque subir de versión suele romper la aplicación y obliga a migrar código.

También hay impacto en continuidad: según SecurityWeek, incluso los intentos fallidos generaron 30 errores de memoria y 11 caídas de procesos en los servidores de Karimi.

Si el servidor contiene datos personales, una intrusión es un incidente que la Ley 21.719 obligará a gestionar y reportar. Para prestadores de servicios esenciales y operadores de importancia vital, la Ley 21.663 exige además notificar al CSIRT Nacional con una alerta temprana dentro de las primeras tres horas.

Qué hacer

  • Inventariar todo servicio con PHP (hostings externos, contenedores, CMS con sus extensiones) y retirar de internet herramientas como phpMyAdmin.
  • Respaldar base de datos y archivos, y luego actualizar la aplicación y PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Con 8.1 o anterior, planificar la migración del código.
  • Mientras se migra, poner el sitio detrás de un WAF con reglas para PHP2Shell y bloquear en el firewall todo tráfico que no provenga del WAF, para impedir ataques directos a la IP del servidor.
  • Aislar los servidores vulnerables: no compartirlos con otras aplicaciones, permitir hacia la red interna solo conexiones indispensables y aplicar las configuraciones recomendadas por PHP.
  • Revisar registros desde el 17 de octubre (errores de memoria, caídas de procesos, comandos lanzados por el usuario del servidor web) y, si el riesgo es alto y no hay mitigación posible, despublicar la aplicación hasta tener un plan.
Provectis
28/10/2026
•
Expertos en servicios y soluciones TI