PHP2Shell: la falla crítica de PHP que afecta a gran parte de la web y cómo protegimos nuestros sitios

PHP2Shell es el nombre que recibieron dos vulnerabilidades del propio lenguaje PHP: CVE-2026-109618 y CVE-2026-109619. Ambas tienen una severidad de 9.2 sobre 10 (CVSS 4.0) y permiten la ejecución remota de código: un atacante, sin usuario ni contraseña, puede hacer que el servidor ejecute sus propias instrucciones.

La primera aparece cuando PHP se queda sin memoria a mitad de preparar una petición y deja datos internos a medio construir. La segunda ocurre cuando información de una petición sobrevive a la memoria que la contenía, y la siguiente petición atendida por el mismo proceso puede usar esos restos. Lo más delicado: según los reportes, un ataque funcional necesita una sola petición y se dispara antes de que se ejecute el código de tu sitio.

PHP es, por mucho, el lenguaje de servidor más usado en la web. Según W3Techs, al 27 de octubre de 2026 lo usa el 69.2 % de los sitios cuyo lenguaje de servidor se conoce. Ahí están WordPress, Moodle, Laravel, Drupal, Joomla y una enorme cantidad de sistemas hechos a medida.

• Está expuesta cualquier instalación de PHP que responda visitas web: PHP-FPM, Apache con mod_php, php-cgi, LiteSpeed y FrankenPHP. El riesgo es mayor cuando PHP corre como módulo de Apache.
• No depende de tu tema ni de tus plugins: actualizar WordPress no te protege, porque la falla está debajo, en PHP.
• Unit 42, de Palo Alto Networks, reportó más de 22.6 millones de instancias expuestas potencialmente vulnerables según su telemetría.

• 17 de octubre: Amazon registró en sus servidores trampa un intento de explotación, cuatro días antes de la publicación oficial.
• 20 de octubre: los detalles de las fallas se filtraron antes de la fecha de divulgación prevista para el 22.
• 21 de octubre: PHP publicó las versiones corregidas y la agencia de ciberseguridad de Estados Unidos (CISA) pidió parchear de inmediato. Ese mismo día ya se observaban intentos de explotación activa.

Instalar la versión nueva no basta: hay que reiniciar los procesos de PHP para que el servidor deje de usar el código vulnerable que ya tenía cargado en memoria.

Hospedamos sitios WordPress y aplicaciones en servidores que administramos nosotros. Eso nos permitió actuar sin esperar a un proveedor. El 21 de octubre, el mismo día de la publicación del parche, seguimos este orden:

• Inventario completo. Identificamos todo lo que corre PHP: 8 sitios WordPress, una plataforma Moodle, una aplicación Laravel y las herramientas internas del servidor.
• Respaldo antes de tocar. Tomamos instantáneas completas de los servidores y guardamos las imágenes anteriores de las aplicaciones, para poder volver atrás en minutos si algo fallaba.
• Parche en todo. Los 8 WordPress pasaron a PHP 8.5.12. La plataforma Moodle y la aplicación Laravel, que corrían PHP como módulo de Apache (el escenario de mayor riesgo), se reconstruyeron sobre PHP 8.3.36. También actualizamos las demás versiones de PHP instaladas y la plataforma de despliegue.
• Reinicio de procesos para que el código corregido quedara activo.
• Revisión de intrusión. Comparamos el núcleo de WordPress de los 8 sitios con los archivos oficiales, buscamos archivos PHP en las carpetas de subidas, revisamos cada archivo modificado en las 36 horas previas y los procesos de las aplicaciones. No encontramos señales de que esta vulnerabilidad se hubiera usado contra nuestros sitios.
• Verificación final. Confirmamos que todos los sitios y aplicaciones respondían con normalidad después de los reinicios.
• Registro para cada cliente. La intervención quedó anotada en la bitácora de cada sitio, que forma parte de su reporte mensual.

Además, nuestros sitios pasan por Cloudflare, que publicó reglas de firewall contra los vectores de ataque conocidos para todos sus clientes. Es una capa adicional útil, pero la protección real es el parche.

• Averigua tu versión de PHP. En WordPress está en Herramientas, Salud del sitio, Información, Servidor.
• Compárala con la tabla de arriba. Si es menor, pide a tu proveedor la actualización y que reinicie PHP.
• Si usas PHP 8.1 o anterior, el problema va más allá de esta falla: esas versiones ya no reciben parches. Planifica la migración.
• Busca señales de intrusión desde el 17 de octubre: archivos nuevos, usuarios desconocidos, redirecciones o procesos extraños. Si encuentras algo, sigue nuestra guía para un WordPress hackeado.
• Si no puedes actualizar pronto, organismos como el NCSC del Reino Unido recomiendan considerar desconectar el sistema mientras tanto.

Lo que hizo posible parchear el mismo día no fue la suerte. Fue tener un inventario claro de lo que corre en cada servidor, respaldos que se prueban, acceso directo a la infraestructura y alguien vigilando las alertas de seguridad. En un hosting compartido, en cambio, dependes de los tiempos de tu proveedor.

Si quieres que tu sitio esté en esas condiciones, conoce el servicio de hospedaje y mantenimiento web, o empieza por la auditoría gratuita de tu sitio.

• Help Net Security: PHP2Shell, vulnerabilidades de PHP parcheadas
• watchTowr: preguntas frecuentes sobre CVE-2026-109618
• Unit 42 (Palo Alto Networks): Threat Brief sobre PHP2Shell
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• W3Techs: uso de PHP en sitios web