PHP2Shell: la vulnerabilidad crítica de PHP y qué hacer
Anunciadas el 20 de octubre de 2026 y corregidas al día siguiente, dos vulnerabilidades críticas de PHP permiten ejecutar código en un servidor web sin ninguna credencial. Qué ha pasado, quién está expuesto y qué hacer.
El 20 de octubre de 2026 el equipo de seguridad de PHP anunció una actualización urgente para dos vulnerabilidades críticas, y el 21 de octubre publicó las correcciones. Los dos fallos, apodados «PHP2Shell», permiten a cualquiera ejecutar código en un servidor web sin credenciales. PHP mueve unos siete de cada diez sitios web cuya tecnología se conoce, incluidos todos los creados con WordPress, Joomla, Drupal o Magento.
Si eres cliente nuestro, puedes estar tranquilo: ya hemos actualizado PHP a una versión segura para todos nuestros clientes. No tienes que hacer nada. Si tu sitio lo gestiona otra empresa, a continuación te explicamos qué revisar.
Qué ha pasado
- 17 de octubre. Amazon registra un primer intento de ataque en sus servidores señuelo (honeypots), cuatro días antes de que las vulnerabilidades se hagan públicas.
- 20 de octubre. Los identificadores de las dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, circulan por la red antes de lo previsto. El equipo de PHP anuncia las correcciones para el día siguiente, con un día de adelanto sobre el calendario.
- 21 de octubre. Salen PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las distribuciones de Linux habían recibido las correcciones por adelantado. En pocas horas, Amazon y Cloudflare informan de los primeros ataques.
Por qué es tan grave
Las dos vulnerabilidades tienen una puntuación de gravedad de 9,2 sobre 10 (CVSS 4.0) y tres características que rara vez coinciden:
- No hace falta acceso. Basta una petición al sitio, sin usuario ni contraseña.
- El fallo está en PHP, no en el sitio. Tener WordPress, Joomla y los plugins actualizados no protege, porque el problema está en el lenguaje sobre el que funcionan. Los investigadores han demostrado el ataque en instalaciones de WordPress, Drupal, Joomla y Magento.
- Afecta a cualquier configuración. El equipo de PHP considera en riesgo todas las instalaciones que sirven páginas web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es máximo con mod_php, donde el ataque puede empezar antes de que se ejecute el código del sitio.
En términos técnicos, la primera vulnerabilidad (CVE-2026-109618) nace de cómo PHP gestiona la falta de memoria: un error en el momento equivocado deja los datos de la petición a medio inicializar, y la limpieza final los trata como válidos. La segunda (CVE-2026-109619) deja datos de una petición después de que su memoria se haya liberado, y la siguiente petición atendida por el mismo proceso puede reutilizarlos. En ambos casos, quien ataca puede ejecutar código con los permisos del servidor web.
En el momento de la publicación, el equipo de PHP no había encontrado exploits funcionales en circulación. Sin embargo, Amazon ya habla de explotación a gran escala, y varios investigadores han reproducido los ataques de forma independiente: cualquier sitio sin actualizar debe considerarse en riesgo.
Qué versiones son seguras
- PHP 8.5: desde la 8.5.12.
- PHP 8.4: desde la 8.4.27.
- PHP 8.3: desde la 8.3.36.
- PHP 8.2: desde la 8.2.35. Eso sí, el soporte de la 8.2 termina el 31 de diciembre de 2026, así que conviene planificar ya el paso a una versión más reciente.
- PHP 8.1, 8.0 y 7.4: ya no reciben actualizaciones oficiales. Dada la gravedad, el equipo de PHP ha publicado las correcciones como código fuente, y algunos proveedores las distribuyen en paquetes actualizados. Es una solución de emergencia: lo correcto es pasar a una versión con soporte.
- PHP 7.3 y anteriores: sin corrección. Las versiones afectadas se remontan hasta PHP 5.4, así que un sitio tan antiguo debe actualizarse de inmediato.
En algunas distribuciones de Linux la corrección llega en un paquete que conserva el número de versión antiguo. Si el número que ves no está en esta lista, pregunta a tu proveedor de hosting si la corrección ya está instalada.
Qué hacer si no gestionamos tu sitio
- Comprueba la versión de PHP. La encontrarás en el panel de tu hosting. En WordPress está en Herramientas → Salud del sitio → Información → Servidor, y en Joomla en Sistema → Información del sistema.
- Pregunta a tu hosting si ha actualizado, y cuándo. En un hosting compartido, la actualización le corresponde al proveedor, no a ti.
- No confíes en plugins o fragmentos de código «anti PHP2Shell». El fallo está en el lenguaje y un plugin no puede corregirlo: la única solución completa es actualizar PHP.
- Busca señales de intrusión desde el 17 de octubre: cuentas de administrador que no reconoces, archivos PHP desconocidos (por ejemplo, en la carpeta de subidas), páginas modificadas, errores 500 repetidos. Si encuentras algo, considera el servidor comprometido: actualízalo, restaura una copia de seguridad limpia y cambia todas las contraseñas y claves que conoce el sitio (base de datos, FTP, administradores, servicios externos).
Si gestionas tú el servidor
Si no puedes actualizar enseguida, el equipo de PHP indica medidas que reducen el riesgo sin eliminarlo: poner memory_limit a -1 y session.upload_progress.enabled a 0 a nivel de servidor (php.ini o pool de PHP-FPM; ini_set() y .user.ini llegan demasiado tarde), en PHP 8.5 también fatal_error_backtraces a 0, reducir post_max_size y reiniciar todos los procesos de PHP. Las reglas de firewall que Cloudflare ha activado en todos sus planes también cubren solo los ataques ya conocidos. Son parches provisionales: la instalación sigue siendo vulnerable hasta que se actualiza.
Esta vez no bastaba con actualizar WordPress y sus plugins: el fallo estaba en el lenguaje sobre el que funcionan. Un sitio seguro necesita a alguien que se ocupe también del servidor.
Cómo trabajamos
Las actualizaciones de seguridad del servidor están incluidas en nuestro hosting gestionado: quien nos confía su sitio no tiene que seguir los boletines de seguridad ni acordarse de intervenir. Si tu sitio está alojado en otro lugar y no sabes qué versión de PHP usa, escríbenos: comprobaremos juntos si está expuesto y qué hace falta para protegerlo.
Artículo actualizado el 22 de octubre de 2026. La situación sigue evolucionando: para los detalles técnicos, la referencia es el aviso de seguridad oficial de PHP.