En octubre de 2026 se publicaron dos vulnerabilidades críticas en PHP, el lenguaje sobre el que corre buena parte de la web. Las identificaron investigadores de Calif, OpenAI y Wiz, con asistencia de modelos de inteligencia artificial, y la noticia encendió una alerta inmediata en la comunidad de ciberseguridad.
Entre el 20 y el 22 de octubre de 2026, PHP2Shell pasó de rumor a parche, y de parche a listas de indicadores de compromiso (IoC).
En pocos días, distintos proveedores de seguridad publicaron direcciones IP, dominios y hashes asociados a la explotación de estas vulnerabilidades.
(Acceso libre, no requiere suscripción)
En este artículo analizaremos lo que muestran las fuentes públicas sobre el avance de la aplicación de parches en América Latina y el Caribe, y compartiremos recomendaciones para mitigar y corregir esta vulnerabilidad.
Qué es PHP2Shell y a quién afecta
PHP2Shell es el nombre con el que se conoce a dos vulnerabilidades en el propio intérprete de PHP: CVE-2026-109618 y CVE-2026-109619. Ambas tienen una severidad CVSS v4.0 de 9.2 (9.8 en CVSS v3.1) y permiten ejecutar código de forma remota, sin autenticación, mediante solicitudes HTTP.
La severidad, sin embargo, es sólo una de las señales para priorizar. Si la cruzamos con otros dos indicadores, el panorama cambia:
En este artículo analizaremos lo que muestran las fuentes públicas sobre el avance de la aplicación de parches en América Latina y el Caribe, y compartiremos recomendaciones para mitigar y corregir esta vulnerabilidad.
Qué es PHP2Shell y a quién afecta
PHP2Shell es el nombre con el que se conoce a dos vulnerabilidades en el propio intérprete de PHP: CVE-2026-109618 y CVE-2026-109619. Ambas tienen una severidad CVSS v4.0 de 9.2 (9.8 en CVSS v3.1) y permiten ejecutar código de forma remota, sin autenticación, mediante solicitudes HTTP.
La severidad, sin embargo, es sólo una de las señales para priorizar. Si la cruzamos con otros dos indicadores, el panorama cambia:
Indicador
CVE-2026-109618
CVE-2026-109619
Qué mide
CVSS v4.0
9.2
9.2
Gravedad técnica si se explota
EPSS (FIRST, 26/10)
99,981%
99,997%
Probabilidad de explotación en los próximos 30 días
Catálogo KEV (CISA, 26/10)
No incluida
No incluida
Explotación confirmada
El EPSS de CVE-2026-109618 pasó de 11,84% a 99,98% el 25 de octubre, según el historial de CVEdetails. Al 26 de octubre, la API pública de FIRST asigna 99,981% a CVE-2026-109618 y 99,997% a CVE-2026-109619, ambas en el percentil más alto de todas las vulnerabilidades puntuadas. En cambio, al 26 de octubre ninguna de las dos figura en el catálogo KEV de CISA, que sólo incorpora vulnerabilidades con explotación confirmada. CISA publicó una alerta el 21 de octubre urgiendo a parchear, pero sin haber observado explotación, como resume Tenable.
Al estar en PHP y no en una aplicación concreta, el alcance es enorme. Cualquier sitio que corra sobre un PHP vulnerable puede estar expuesto, sea WordPress, Drupal, Joomla o un desarrollo propio. Las versiones corregidas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12, publicadas el 21 de octubre. Las ramas 8.1 y anteriores ya no reciben versiones oficiales corregidas.
Los detalles se filtraron antes de la fecha prevista y el equipo de PHP adelantó la publicación del parche. Además, Amazon informó que su red de honeypots registró un intento de explotación el 17 de octubre, cuatro días antes de que el parche fuera público.
Es importante no confundirlas con CVE-2026-115560, publicada el 23 de octubre, que algunas listas agrupan bajo el mismo nombre. Es un problema distinto, que requiere una configuración poco común y no tiene explotación reportada, de acuerdo con The Hacker News.
La región frente al parche
Censys mantiene un panel público que sigue, hora a hora, cuántos servicios PHP expuestos en Internet reportan una versión vulnerable o corregida, con desglose por país. Con estos datos analizamos 21 países de la región.
Al 26 de octubre, en América Latina y el Caribe está corregido el 12,8% de los servicios PHP con versión identificada. A nivel global, el valor es 25,1%. La región parchea a la mitad del ritmo del resto del mundo.
Ambos porcentajes cuentan como no parcheados a los servidores con versiones de PHP que ya no tienen corrección, como 7.4 o anteriores: son vulnerables y no hay actualización que aplicar. Censys no publica por país cuántos están en esa situación, así que no podemos saber qué parte del 87% restante de la región necesita actualizar y qué parte necesita migrar.
Otros datos que ayudan a entender el panorama:
Ramas sin corrección: a nivel global, el 73% de los servicios vulnerables corre en ramas de PHP sin parche posible. La versión más común de Internet, la 7.4.33, es una de ellas. Para esos servidores no hay actualización que aplicar, hay que migrar. Cisco Talos llega por otra vía a una conclusión similar y estima que cerca de la mitad de los sistemas PHP no recibirá parche.
Ritmo del parcheo: la gran mayoría de las correcciones se aplicó el 22 y el 23 de octubre. Desde entonces, la curva se aplanó.
Lo que enseñan las listas de indicadores
El cruce de indicadores dejó varias observaciones:
Cada fuente ve una parte: las 6 IP publicadas por Amazon están todas en la lista de FortiGuard, y 4 de las 6 de Cisco Talos también. Pero Amazon y Talos no comparten ninguna. Cada proveedor observa una porción distinta del mismo fenómeno, y algunas listas parecen incorporar datos de otras fuentes.
No hay un único atacante: las 82 IP de FortiGuard se reparten en 56 sistemas autónomos distintos, y el que más concentra tiene 5. Conviven nubes, hosting de bajo costo y redes de acceso residenciales y móviles, que pueden corresponder a equipos comprometidos.
Dominios creados al ritmo de la noticia: los tres dominios .com de la lista, todos con “php2shell” en el nombre, se registraron el 22 de octubre, entre 14 y 24 horas después de la publicación del parche.
Recomendaciones
Actualizar: a PHP 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o al paquete corregido de la distribución Linux usada.
Migrar las ramas sin soporte: en PHP 8.1 o anteriores no hay parche oficial, es necesario migrar a una versión con soporte. Quienes estén en PHP 8.2 pueden aplicar el parche, pero deberían planificar la migración: esa rama deja de recibir correcciones de seguridad el 31 de diciembre de 2026.
Mitigar mientras tanto: aplicar las medidas parciales que recomienda PHP para cada CVE, como limitar el tamaño de las solicitudes POST y deshabilitar session.upload_progress, reiniciando los procesos de PHP. Esto no reemplaza la actualización.
Revisar compromiso: si el servidor estuvo expuesto y sin parchear antes del 21 de octubre, conviene buscar señales de compromiso, por ejemplo solicitudes POST de gran tamaño con un campo PHP_SESSION_UPLOAD_PROGRESS y archivos inesperados en el directorio de sesiones.
Conclusiones y llamado a la acción
Cruzar listas públicas de indicadores aporta un contexto que ninguna lista trae por sí sola: cada proveedor ve una parte distinta del fenómeno, detrás de las IP hay decenas de redes diferentes y algunos indicadores aparecen apenas horas después de la noticia. Antes de bloquear o atribuir, conviene mirar de dónde viene cada dato.
En la región, el desafío no es sólo aplicar el parche: una parte importante de los servidores corre versiones de PHP que ya no tienen corrección, y para ellos la única salida es migrar, con el esfuerzo que eso implica.
Alentamos a los CSIRT, investigadores y operadores de la región a contrastar estas listas con sus propios registros web y de red, a priorizar la migración de las ramas de PHP sin soporte y a compartir lo que observen.
