php2shell: la falla crítica de PHP que toma servidores sin contraseña (2026)

Si tienes un sitio o sistema en PHP, actualiza PHP hoy. El 21 de octubre de 2026, el proyecto PHP reveló dos vulnerabilidades críticas — apodadas php2shell (CVE-2026-109618 y CVE-2026-109619) — que permiten a un atacante ejecutar código en el servidor sin contraseña, con una sola solicitud. La corrección es directa: actualizar a una versión parcheada de PHP. Este post explica qué es la falla, a quién afecta, cómo se explota y el paso a paso para protegerte.

Qué es php2shell

Son dos fallas en el núcleo de PHP, ligadas al manejo de memoria durante el procesamiento de solicitudes HTTP. El equipo de PHP calificó la gravedad en 9,2 de 10 en la escala CVSS 4.0; el NVD (la base nacional de vulnerabilidades de EE. UU.) registra 9,8 de 10 en CVSS 3.1 — en cualquiera de las dos, es el tope de la gravedad. El impacto principal es ejecución remota de código (RCE) sin autenticación: el atacante corre comandos en el servidor sin tener cuenta ni contraseña. Como consecuencia, puede tumbar el servicio, filtrar datos y tomar el control de la máquina.

Cloudflare estima que PHP está presente en cerca del 70% de los sitios — es la base de WordPress, de tiendas online, de portales y de incontables APIs. Por eso es tan serio: no es un nicho, es la mayor parte de la web. El mismo día de la divulgación, servicios públicos salieron de línea para parchear a las apuradas — en Brasil, parte de los servicios del regulador de telecomunicaciones (Anatel) quedaron temporalmente inaccesibles.

A quién afecta

Cualquier instalación de PHP que atiende solicitudes web. La falla está en PHP mismo, no en un framework específico, así que alcanza los principales modos de ejecución:

• PHP-FPM (el más común hoy, detrás de Nginx);
• Apache con mod_php — señalado como el escenario de mayor riesgo;
• php-cgi, FrankenPHP y LiteSpeed.

En la práctica incluye WordPress (y todo su ecosistema de temas y plugins), aplicaciones Laravel, tiendas en Magento/WooCommerce, paneles internos y APIs hechas en PHP. Según el proyecto, las versiones desde PHP 5.4 en adelante se reportan como afectadas — o sea, incluye mucho código viejo todavía en producción.

Cómo saber en 1 minuto si estás expuesto

Es simple: si tu sitio o sistema corre PHP y la versión no es una de las corregidas (8.5.12, 8.4.27, 8.3.36 u 8.2.35, o un paquete de tu distribución ya actualizado), considérate expuesto. Para revisar la versión: en el servidor, php -v; en un sitio, la versión a veces aparece en el encabezado HTTP X-Powered-By (si no está oculto) o en el panel del hosting. Ante la duda, pregúntale a tu proveedor “¿qué versión de PHP usa mi sitio y ya tiene la corrección de php2shell?”.

Cómo se explota la falla

El detalle que hace a php2shell tan peligrosa: una sola solicitud HTTP dispara el ataque antes de que corra el código de tu aplicación. No importa el framework, el plugin de seguridad ni la regla de negocio — el problema ocurre en la capa de PHP que arma la solicitud, antes de llegar a tu código. Las dos CVE tienen causas relacionadas, ambas en manejo de memoria:

CVE-2026-109618 — corrupción de memoria en la limpieza de la solicitud

Cuando el servidor se queda sin memoria (out-of-memory) a mitad del procesamiento, PHP puede interrumpirse con los datos internos de la solicitud parcialmente inicializados. La rutina de limpieza entonces trata esos datos inválidos como válidos — y esa corrupción de memoria es lo que el atacante usa para ejecutar código.

CVE-2026-109619 — estado global reutilizado de una solicitud anterior

Un estado interno que pertenece a una solicitud puede sobrevivir después de que su memoria fue liberada. Una solicitud posterior, atendida por el mismo proceso worker, puede terminar usando ese estado “viejo” antes de que la inicialización normal lo reinicie. Es un clásico uso-después-de-liberación (use-after-free) entre solicitudes, que lleva a ejecución de código y a fuga de datos de una solicitud a otra.

Investigadores ya demostraron un exploit funcional, y Cloudflare afirma haber identificado vectores de ataque conocidos — por eso el parche es urgente. (No vamos a publicar detalles de explotación aquí.)

Cómo llegamos hasta acá

Las fallas se encontraron de forma independiente hace meses — según los reportes, por la empresa de seguridad Calif y por OpenAI — y investigadores de Wiz publicaron la explicación técnica. El plan era una divulgación coordinada: las distribuciones Linux y los proveedores recibieron el parche antes, para liberar los paquetes el mismo día. Pero la información sobre la falla se filtró antes de la divulgación oficial, y ahí empezó la carrera: sitios salieron de línea para actualizar a las apuradas, Cloudflare activó reglas de WAF unas nueve horas antes del anuncio, y PHP publicó las versiones corregidas el 21 de octubre de 2026. Es un recordatorio de que, cuando la falla está en el núcleo de una tecnología tan omnipresente como PHP, el tiempo entre “existe corrección” y “estoy protegido” es solo el que tardes en actualizar.

Por qué no alcanza con “sortearla”

El comunicado del equipo de PHP es directo: no hay solución alternativa definitiva; actualizar es la única opción segura. Cambiar configuración o limitar memoria puede reducir la exposición, pero no cierra la falla. Un WAF (firewall de aplicaciones) ayuda como capa temporal — Cloudflare activó reglas para los vectores conocidos, incluso en el plan gratuito, unas nueve horas antes de la divulgación — pero sirve para ganar tiempo, no para reemplazar el parche. El NCSC del Reino Unido llegó a recomendar sacar de línea cualquier sistema que no se pueda corregir de inmediato.

Cómo corregirlo ahora

1. Revisa tu versión de PHP. En el servidor: php -v. En hosting administrado, el panel (cPanel, Plesk) muestra la versión en uso.
2. Actualiza a una versión parcheada (lanzadas el 21/10/2026):

   PHP 8.5.x  →  8.5.12
   PHP 8.4.x  →  8.4.27
   PHP 8.3.x  →  8.3.36
   PHP 8.2.x  →  8.2.35

3. Reinicia PHP después de actualizar. PHP-FPM (systemctl restart php8.3-fpm, ajustando la versión) o Apache con mod_php. Sin reiniciar, el proceso viejo (vulnerable) sigue corriendo.
4. ¿Hosting administrado o una distribución Linux? Ubuntu, Debian, AlmaLinux y Red Hat liberaron paquetes corregidos (muchos antes de la divulgación pública). Actualiza con el gestor de paquetes del sistema y confirma con tu proveedor.
5. ¿Estás en una versión vieja (fin de vida)? PHP 8.1 y anteriores no reciben release oficial, pero el equipo de seguridad publicó backports mínimos de código fuente para PHP 7.4, 8.0 y 8.1 (para quien compila desde el código). PHP 5.x y 7.0–7.3 no tienen corrección del proyecto — el camino es migrar a una versión soportada, con urgencia.
6. WAF como capa temporal. Si usas Cloudflare, confirma que la protección está activa. Es un paliativo mientras actualizas, no la solución.
7. Verifica señales de compromiso. Como ya hay exploit, trata a los servidores desactualizados como potencialmente alcanzados: mira logs de acceso por solicitudes extrañas, archivos nuevos o modificados en la raíz de la aplicación (webshells), tareas programadas y usuarios creados sin explicación.

Actualicé. ¿Y si entraron antes?

Actualizar cierra la puerta, pero no deshace lo que hayan podido hacer mientras estuvo abierta. Como la falla permite ejecución de código sin login y ya existe un exploit público, un servidor que pasó días sin parchear merece una revisión más allá de lo básico: buscar webshell, persistencia (cron, servicios, claves SSH agregadas), credenciales que puedan haberse filtrado y haya que rotar, y accesos anómalos en los logs. Si tu sistema guarda datos personales o procesa pagos, esta revisión deja de ser opcional.

Es justo el tipo de situación donde una mirada externa ayuda: confirmar que la corrección se aplicó en todos los puntos y que nadie dejó algo atrás. Si quieres que te ayudemos a revisar tu caso, habla con un investigador — y, de forma más amplia, un pentest periódico encuentra este tipo de brecha antes de que sea noticia.

Fuentes oficiales y análisis: php.net (versiones corregidas), NVD CVE-2026-109618, NVD CVE-2026-109619, NCSC-NL (información operativa) y Help Net Security. Este artículo es informativo y no reemplaza el aviso oficial de tu proveedor y tu distribución.