Alerta de seguridad · CVE-2026-109618 · CVE-2026-109619
¿Tu sitio web está expuesto a PHP2Shell?
PHP2Shell son dos fallas críticas (CVSS 9.2) en PHP, el lenguaje que mueve cerca del 70% de los sitios web, incluidos WordPress, Drupal y Joomla. Un atacante sin usuario ni contraseña puede tomar el control del servidor. Ingresa tu sitio y te decimos en segundos si tu versión está afectada y qué hacer.
Revisión pasiva: solo leemos las cabeceras públicas de tu sitio. No enviamos ataques.
¿Qué es PHP2Shell y por qué importa?
Es una familia de vulnerabilidades de memoria en el núcleo de PHP, corregida el 21 de octubre de 2026. La falla está en PHP, no en tu código: incluso un sitio “Hola mundo” en una versión afectada puede quedar expuesto. Actualizar WordPress, temas o plugins no lo corrige; hay que actualizar el PHP del servidor.
¿Qué puede hacer un atacante con mi sitio?
- Ejecutar código en tu servidor sin autenticarse: tomar el control, desfigurar el sitio, instalar malware o usarlo para entrar a otros sistemas.
- Leer la memoria del proceso PHP: contraseñas, tokens de sesión, llaves de API y certificados, incluso de otros visitantes.
- Robar datos sin dejar rastro evidente: la fuga de memoria no requiere ejecutar código, por lo que es más difícil de detectar.
Los investigadores lo demostraron contra WordPress, Drupal y Joomla, pero no hace falta ninguna de esas aplicaciones: basta PHP vulnerable sirviendo peticiones web (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP o LiteSpeed).
¿Qué versiones de PHP están afectadas?
Casi todas las versiones desde PHP 5.4 tienen al menos una de las dos fallas. Estas son las primeras versiones corregidas por rama:
| Rama de PHP | Vulnerable | Primera versión corregida |
|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 |
| 8.4 | < 8.4.27 | 8.4.27 |
| 8.3 | < 8.3.36 | 8.3.36 |
| 8.2 | < 8.2.35 | 8.2.35 |
| 8.1 y anteriores | Todas | Sin versión oficial: migrar o usar el parche de tu distribución |
¿Qué hago para corregirlo?
- Actualiza PHP a una versión corregida en cada servidor o contenedor que atiende tu sitio. Es la única corrección completa.
- Reinicia Apache, PHP-FPM y todo proceso PHP de larga duración (colas, Octane, FrankenPHP). Sin reinicio sigue corriendo la versión vieja.
- Si tu sitio está en un hosting, pide a tu proveedor que confirme por escrito la versión de PHP y el parche para CVE-2026-109618 y CVE-2026-109619.
- Vuelve a revisar tu sitio aquí y en el servidor (
php -vno siempre es el mismo PHP que atiende la web).
Actualización · 23 de octubre de 2026 · CVE-2026-115560
PHP recomienda mantener session.upload_progress.enabled = 0 incluso con PHP ya actualizado, hasta la próxima versión regular. Cierra una vía de ejecución remota poco probable: solo ocurre si la aplicación configura session.serialize_handler como php_binary o php_serialize y lo cambia a php con ini_set() antes de session_start(). Si tu aplicación nunca cambia ese ajuste, puede dejar la función activa. Si ya aplicaste esta medida el 21 de octubre, déjala como está. Ver aviso de PHP
¿Y si no puedo actualizar hoy?
Estas medidas del aviso oficial de PHP reducen la exposición a ataques conocidos, pero no hacen seguro el servidor. Aplícalas en php.ini, el pool de FPM o la configuración de Apache (no con ini_set() ni .user.ini) y reinicia todos los workers:
memory_limit = -1 ; mejor con php_admin_value para que la app no lo cambie
post_max_size = 8M ; 32M si tu sitio necesita subir archivos
upload_max_filesize = 8M ; siempre menor que post_max_size
session.upload_progress.enabled = 0 ; mantenla también después de actualizar
fatal_error_backtraces = 0 ; solo PHP 8.5- Con
memory_limit = -1, contén el consumo con un límite de contenedor o cgroup v2 (memory.max). No usesRLIMIT_ASniRLIMIT_DATA: provocan la misma falla. - Limita en el servidor web o proxy el tamaño de las peticiones, la cantidad de campos y de partes multipart.
- Mantén activas las reglas WAF de tu CDN. En Cloudflare están activas en todos los planes; en planes pagados, confirma que el Managed Ruleset esté en modo bloqueo.
- Señales de posible ataque: peticiones multipart extrañas seguidas de errores de memoria, muchos errores 500, cookies
PHPSESSIDanormalmente grandes y reinicios inexplicables de workers PHP.
Preguntas frecuentes
¿Cómo funciona esta revisión?
Hacemos una petición HEAD a tu sitio (o GET si el servidor no acepta HEAD), seguimos hasta 3 redirecciones y leemos las cabeceras públicas Server y X-Powered-By, además de señales pasivas como la cookie PHPSESSID. Comparamos la versión anunciada con las versiones corregidas. Usamos la lógica del revisor de código abierto publicado por OpenAI.
Si el resultado dice “corregido”, ¿estoy 100% seguro?
No necesariamente. Las cabeceras muestran la versión que el sitio anuncia, no prueban qué binario corre ni si los workers se reiniciaron. Tampoco pueden ver parches aplicados por distribuciones como Ubuntu, Debian o Red Hat. La verificación definitiva se hace en el servidor.
Mi sitio oculta la versión de PHP. ¿Qué hago?
Es buena práctica (expose_php = Off), pero no corrige PHP2Shell. Revisa la versión en tu panel: en WordPress, Herramientas → Salud del sitio → Información → Servidor; en Drupal, Informes → Informe de estado; en Joomla, Sistema → Información del sistema; en cPanel, Seleccionar versión de PHP o MultiPHP Manager.
¿Guardan los sitios que reviso?
Sí. Registramos la URL revisada y el resultado técnico para fines estadísticos y de investigación de mercado de Area56 Digital. No guardamos tu dirección IP en claro.
¿No sabes cómo seguir? No te preocupes, te orientamos
PHP2Shell es un tema técnico, pero no tienes que resolverlo solo. Si no sabes qué pedirle a tu hosting, cómo actualizar o si tu sitio quedó realmente protegido, conversemos y te ayudamos a definir los próximos pasos.
Tu sitio es por donde llegan tus prospectos: mejor resolverlo a tiempo que enterarse cuando ya está caído.
Hablemos