La firma de seguridad Wiz Research reveló una vulnerabilidad crítica en PHP. Según su cálculo, ese lenguaje sostiene cerca del 70 % de los sitios web del mundo. Son dos fallas agrupadas bajo el nombre PHP2Shell, con una gravedad de 9,2 sobre 10. Permiten ejecutar código en el servidor sin contraseña y leer la memoria donde viven contraseñas, tokens y claves. El equipo de PHP liberó el parche el 21 de octubre.
Según detalló Wiz Research en su informe, las fallas viven en el núcleo del lenguaje y no en una aplicación concreta. El equipo demostró la ejecución de código sin autenticación sobre WordPress, Drupal y Joomla con sus imágenes más recientes. Por separado, mostró que un atacante puede leer la memoria del proceso. Esa memoria guarda contraseñas, llaves de sesión temporales y claves de acceso de programas ajenos.
Cómo funciona la vulnerabilidad crítica en PHP
La vulnerabilidad crítica en PHP nace de un error en el manejo de la memoria. Ocurre cuando una petición termina de forma abrupta, por ejemplo al agotar la memoria disponible. El fallo deja un estado interno corrupto, y una petición posterior reutiliza esa memoria ya liberada. Así un atacante sin credenciales puede ejecutar código o leer datos ajenos. El problema alcanza a toda versión publicada desde PHP 5.4. Las dos fallas llevan los códigos CVE-2026-109618 y CVE-2026-109619.
La primera, CVE-2026-109618, filtra memoria por sí sola, de forma parecida a la falla Heartbleed de 2014. La segunda, CVE-2026-109619, combina dos problemas para lograr la ejecución de código. El parche corrige la causa de raíz y elimina todas las variantes. Las versiones corregidas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Las versiones anteriores, sin soporte, no recibieron una corrección oficial.
PHP mueve WordPress, Drupal y MediaWiki, el software que sostiene Wikipedia. Como el fallo está en el propio lenguaje, hasta una aplicación mínima sin errores queda expuesta. Cualquier versión de la última década, desde la 5.4, se ve afectada por al menos una de las fallas.
Una divulgación coordinada entre empresas
El hallazgo no se divulgó en solitario. Wiz coordinó con el equipo de PHP, con OpenAI, cuyo modelo de lenguaje participó en el hallazgo, y con la firma de seguridad Calif. Los tres documentaron el trabajo por su cuenta. Los modelos de inteligencia artificial más avanzados redujeron la barrera para explotar la falla. Con herramientas de prueba y depuración, convirtieron un defecto antiguo en un ataque que funciona. Analizaron los fallos y probaron los ataques en cada versión y configuración de PHP. Wiz afirma que desarrollaron y adaptaron ataques funcionales sobre varias aplicaciones en cuestión de horas.
La defensa también fue conjunta. Proveedores como Automattic, Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft y Vercel prepararon protecciones temporales para quienes no podían aplicar el parche de inmediato. Cloudflare detectó los primeros intentos de ataque a las 07:43 del 21 de octubre, antes de la liberación oficial del parche.
El mismo recurso sirve a los dos lados. La inteligencia artificial encontró la falla y abarató también el trabajo de explotarla. Wiz sostiene que el caso recuerda a Heartbleed en 2014 y a Log4Shell en 2021, porque cambia lo que se considera vulnerable en la práctica. Cuando el tiempo y la pericia necesarios bajan, la complejidad deja de ser una barrera. El riesgo real de cada sitio depende de si corre una versión sin parche. La divulgación coordinada busca que el parche llegue antes que los atacantes.
La recomendación es aplicar el parche de inmediato. Como la falla está en PHP y no en el código de las aplicaciones, actualizar el lenguaje corta el problema de raíz.
Otras fuentes consultadas: Sansec, 21/10/2026 · BleepingComputer, 21/10/2026 · Google Cloud, 21/10/2026.
(El alcance del 70 % y la cronología de la investigación son cifras aportadas por Wiz.)
