Dos vulnerabilidades agrupadas bajo los identificadores CVE-2026-109618 y CVE-2026-109619 afectan al núcleo de PHP y pueden permitir que un atacante ejecute código en servidores sin autenticarse o lea información sensible de la memoria de los procesos. Wiz Research comunicó el hallazgo el 21 de octubre de 2026, fecha en la que PHP publicó correcciones para varios problemas de seguridad relacionados con la gestión de memoria en el motor del lenguaje.
La gravedad señalada por Wiz alcanza una puntuación CVSS de 9,2. El riesgo no se limita a una aplicación concreta: según la investigación, los fallos residen en PHP y pueden afectar incluso a programas sencillos escritos en ese lenguaje. Wiz afirma que las vulnerabilidades alcanzan versiones de PHP que se remontan a la 5.4 y que cada versión publicada durante la última década tiene al menos uno de los problemas descritos.
Qué puede hacer un atacante
Wiz agrupó cuatro casos de fallos de seguridad de memoria bajo dos CVE. Entre los impactos demostrados figuran la divulgación de memoria de procesos, la corrupción de memoria y la ejecución remota de código (RCE). La lectura de memoria puede exponer contraseñas, tokens de autenticación, claves de API y certificados presentes en el proceso, incluso sin que el atacante consiga ejecutar código.
Para mostrar el alcance, el equipo desarrolló un exploit llamado php2shell y demostró ejecución remota sin autenticación en WordPress, Drupal y Joomla, usando las imágenes de contenedor más recientes de esas plataformas disponibles durante las pruebas. Wiz recalca que esos sistemas fueron objetivos de demostración: la vulnerabilidad está en el propio motor PHP y no requiere un defecto en el código de WordPress, Drupal o Joomla.
PHP se utiliza en una parte extensa de la web y sirve de base a sistemas de gestión de contenidos y otros servicios. Wiz Research estima que el lenguaje impulsa el 70 % de los sitios web del mundo. El Español publicó una estimación distinta, del 75 %. Las cifras no coinciden; ambas publicaciones describen, en cualquier caso, una tecnología extendida cuya capa de ejecución compartida puede convertir un defecto del motor en un problema para muchas organizaciones.
Por qué los errores de memoria importan
Los fallos descritos se relacionan con el tratamiento de errores fatales durante las solicitudes, en particular con errores de falta de memoria. Según Wiz, una solicitud interrumpida puede dejar referencias internas obsoletas o estado de memoria inconsistente. Si un proceso reutiliza ese estado al atender otra solicitud, el resultado puede ser una lectura o corrupción de memoria.
Uno de los patrones técnicos identificados es el use-after-free: el programa conserva o utiliza una referencia a un bloque de memoria después de que este haya sido liberado. Otro caso implica confusión de tipos en OPcache, que mantiene estructuras compiladas en memoria compartida. Son clases de errores difíciles de explotar porque el resultado depende de cómo se organiza y reutiliza la memoria, y de las versiones, la configuración y el comportamiento de la aplicación.
Esto también explica por qué una actualización de la aplicación no basta necesariamente. Si el fallo está en el intérprete, cualquier servicio que ejecute una versión afectada de PHP puede quedar expuesto, aunque su propio código no tenga un error equivalente. Para los equipos técnicos, el inventario de riesgo debe incluir las versiones del entorno de ejecución y los servicios que las utilizan, no solo los repositorios de cada aplicación.
El papel de la inteligencia artificial
Wiz sostiene que los fallos llevaban más de una década en el código, pero convertirlos en exploits funcionales exigía encadenar varios errores, adaptarse a la disposición de memoria de cada objetivo y repetir ciclos de pruebas y depuración. La empresa utilizó Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol durante la investigación, y atribuye a Gemini 4 Argon una contribución relevante en el descubrimiento, el desarrollo del exploit, la detección de ataques y la comprobación de la corrección.
La importancia para los profesionales no es que la IA elimine la necesidad de conocimientos técnicos, sino que puede reducir el trabajo necesario para investigar variaciones y adaptar un exploit a distintos entornos. Wiz afirma que modelos de frontera, combinados con herramientas de pruebas y depuración, hicieron viable un proceso que antes habría sido difícil de implementar y escalar. La misma capacidad puede ayudar a encontrar y corregir defectos, pero también reduce la barrera práctica para explotar vulnerabilidades complejas.
El trabajo incluyó coordinación con el equipo de PHP, Calif y OpenAI para el descubrimiento, la divulgación y la verificación del parche. Wiz también señala que colaboró con proveedores y organizaciones como Google Cloud, Cloudflare, AWS, Microsoft, Automattic, Fastly, Akamai, Imperva y Vercel para preparar orientación, detecciones y mitigaciones para quienes no pudieran actualizar inmediatamente.
Qué deberían hacer los equipos
La medida principal es actualizar PHP a una versión corregida, como recomienda Wiz. Las organizaciones deberían identificar los servidores que ejecutan PHP y comprobar qué versión utiliza cada uno, incluidos los entornos de alojamiento y los servicios que no se administran desde el mismo repositorio que la aplicación. Si la actualización no es inmediata, conviene aplicar las mitigaciones disponibles para el entorno y revisar las alertas y los registros en busca de actividad anómala.
Wiz propone prestar atención, entre otras señales, a solicitudes multipart inusuales seguidas de errores de memoria o respuestas HTTP 500 repetidas, cookies PHPSESSID de tamaño o formato inesperado y reinicios o cambios inexplicados en los procesos PHP. La empresa advierte que estas señales pueden orientar una investigación, pero que la corrección mediante el parche es la única remediación completa de los fallos descritos.
PHP publicó además una advertencia informativa sobre el progreso de carga de sesiones. El equipo recomienda desactivar temporalmente session.upload_progress.enabled hasta la siguiente versión de corrección habitual para protegerse de un vector RCE poco probable. PHP especifica que ese caso requiere una combinación inusual: configurar session.serialize_handler como php_binary o php_serialize y cambiarlo después a php en tiempo de ejecución mediante ini_set() antes de llamar a session_start(), manteniendo habilitado el progreso de carga. Si la aplicación no cambia así el manejador de serialización, PHP indica que puede conservar la función habilitada. La organización prevé publicar un aviso completo para CVE-2026-115560 con la siguiente versión; se trata de una advertencia adicional con condiciones concretas, no de una descripción de todas las vulnerabilidades de PHP2Shell.
Un problema de seguridad que no termina con el parche
Wiz indica que los cuatro casos detallados no agotan las variantes posibles de este patrón en el código de PHP y que el parche corrige el problema en su raíz para eliminar las variantes identificadas. Para los administradores, el paso inmediato es instalar la actualización aplicable y verificar que los procesos realmente ejecutan la versión corregida.
La divulgación deja una advertencia para desarrolladores y responsables de seguridad: la complejidad técnica ya no garantiza que un fallo antiguo sea difícil de explotar. La revisión del código, las pruebas, la gestión de memoria y la respuesta coordinada siguen siendo necesarias; también lo es tratar los componentes comunes, como el motor de un lenguaje, como parte esencial de la superficie de ataque.
Fuentes: Wiz Research, PHP.net, El Español
