PHP ha lanzado actualizaciones de seguridad de emergencia para dos vulnerabilidades críticas que podrían permitir a atacantes ejecutar código malicioso en un servidor web sin iniciar sesión.

Las fallas, identificadas como CVE-2026-109618 y CVE-2026-109619 y bautizadas en conjunto como PHP2Shell, residen en el propio PHP, el lenguaje de programación que está detrás de sitios web y aplicaciones como WordPress, Drupal y Joomla. Cada una obtiene 9.2 sobre 10 en el sistema de puntuación de vulnerabilidades común (CVSS), lo que las sitúa en el rango crítico.

¿Qué es PHP2Shell?

PHP se ejecuta en un servidor web, donde gestiona las solicitudes de los visitantes, extrae información de bases de datos, procesa formularios y construye páginas. Según la firma de seguridad Qualys, PHP2Shell comprende dos errores en la forma en que el lenguaje maneja la memoria y el estado de una solicitud web. Las vulnerabilidades están en PHP mismo, no en WordPress, Drupal o Joomla.

WordPress dijo en una publicación en X que las fallas afectan a cualquier servidor que aloje una aplicación PHP y que no se requiere ni se planea una actualización de WordPress. Dado que cada aplicación en un servidor depende del mismo entorno de ejecución, un PHP parcheado cierra la brecha para todas, y un solo entorno sin parchear las deja a todas expuestas, por más actualizadas que estén sus aplicaciones y plugins.

La primera falla, CVE-2026-109618, aparece cuando PHP se queda sin memoria a mitad de una solicitud y deja datos a medio configurar. La segunda, CVE-2026-109619, ocurre cuando PHP sigue apuntando a datos de la solicitud después de que la memoria subyacente ha sido liberada.

Wiz, una de las empresas que reportaron los errores, dijo haber demostrado ataques que ejecutan código en sitios de WordPress y Drupal antes del inicio de sesión. La empresa añadió que una de las fallas también puede filtrar la memoria de un proceso PHP en ejecución. El atacante no necesita ninguna cuenta, y lo que suceda después depende de la configuración del servidor y de los permisos que tenga el proceso PHP comprometido.

¿Quié están expuestos?

PHP dijo en su anuncio que cualquier instalación que atienda solicitudes web está en riesgo, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El proyecto señaló que el riesgo es mayor con el mod_php de Apache, y destacó que un exploit demostrado permite que una solicitud no autenticada desencadene el ataque antes de que se ejecute cualquier código de la aplicación, es decir, el disparador no depende de ninguna debilidad en el código del sitio alojado.\nWiz indicó que las versiones afectadas se remontan a PHP 5.4, un rango que abarca servidores heredados de larga vida. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y versiones anteriores ya no reciben actualizaciones del proyecto, aunque PHP ofrece backports mínimos del código fuente para 7.4, 8.0 y 8.1 a quienes compilan desde el código fuente o no tienen soporte de un proveedor.

PHP también dijo que la rama 8.2 deja de recibir correcciones de seguridad a fin de año, por lo que los usuarios de esa versión deberían planificar una actualización. Algunas distribuciones de Linux y proveedores pueden incorporar las correcciones a versiones anteriores; los administradores deben revisar sus avisos y, cuando no existan, planificar la migración a una versión con soporte. Los productos, contenedores y paneles de hosting que incluyen su propio PHP necesitan actualizaciones por separado.

Según la firma de seguridad Huntress, los detalles de las fallas se filtraron en línea un día antes de la divulgación prevista. PHP adelantó el lanzamiento y publicó las correcciones el 21 de octubre.

Sansec, otra firma de seguridad, dijo que espera una explotación masiva ahora que los parches y los análisis técnicos son públicos. Señaló que Cloudflare ya ha reportado ataques tempranos. Con los detalles técnicos disponibles y ataques ya registrados, los intentos de explotación contra servidores que aún no se han actualizado son lo inmediato que deben vigilar los defensores.

Cómo responder

Actualizar WordPress, Drupal, Joomla o un plugin no corregirá una falla en el propio PHP. Los administradores pueden tomar las siguientes medidas:

Actualizar PHP. Instale una versión corregida a través del gestor de paquetes y luego confirme que el servidor web la esté usando. Los usuarios de WordPress pueden ver su versión en Tools > Site Health > Info > Server, y muchos proveedores de hosting la muestran en su panel de control.

Revisar cada instalación. Inspeccione contenedores, paneles de control y cualquier aplicación que incluya su propio PHP.

Consultar a su proveedor de hosting. En un hosting compartido, PHP puede estar fuera del control del operador. Pregunte al proveedor si ha aplicado el parche y no lo dé por hecho. WordPress indicó que los proveedores ya podrían estar parcheando y agregando reglas de firewall, pero aun así recomienda verificar con el hosting.

Vigilar su repositorio. Sansec advirtió que el repositorio de Remi, común en servidores PHP, no tenía la corrección el día del lanzamiento, y recomendó usar los paquetes de la distribución o compilar desde el código fuente.

Usar mitigaciones solo como medida provisional. PHP dijo que no existen mitigaciones completas y que actualizar es la única opción segura. Medidas como limitar el tamaño de las solicitudes o desactivar el seguimiento de cargas no hacen segura una instalación.

Verificar si hubo un compromiso. Busque procesos inesperados lanzados por PHP, archivos desconocidos y conexiones salientesñas. Un parche no eliminará el malware ya instalado.

Los visitantes comunes no pueden corregir estas fallas, porque residen en servidores y no en teléfonos ni computadoras portátiles. Eso no significa que todos los sitios PHP hayan sido atacados, pero actualizar a una versión corregida es la única solución completa.