El 21 de octubre de 2026 el equipo de PHP publicó actualizaciones de emergencia para corregir dos vulnerabilidades críticas, bautizadas por los investigadores como PHP2Shell. Permiten a un atacante ejecutar código en tu servidor sin usuario ni contraseña, con una simple petición a tu web. Si tu web usa PHP, y eso incluye cualquier WordPress, PrestaShop o Moodle, te afecta.
Qué ha pasado
Son dos fallos distintos, los dos con una puntuación de 9,2 sobre 10 (CVSS v4):
| CVE | Qué falla | Resultado |
|---|---|---|
| CVE-2026-109618 | Cuando PHP se queda sin memoria a mitad de una petición, deja datos internos a medio inicializar y luego los usa como si fueran válidos. | Ejecución remota de código |
| CVE-2026-109619 | Un proceso de PHP que atiende varias peticiones seguidas puede reutilizar memoria ya liberada de una petición anterior (use-after-free). | Ejecución remota de código |
En la práctica, el atacante envía un formulario o una subida de archivos (multipart) preparada para provocar el fallo. No necesita cuenta, ni que tu aplicación tenga ningún error propio: en la configuración más expuesta, el ataque se produce antes de que se ejecute una sola línea de tu web.
Una filtración que adelantó el parche
La publicación estaba prevista para el jueves 22, pero el lunes 20 alguien publicó los detalles antes de tiempo. El post se borró, pero las capturas ya circulaban por redes. PHP respondió adelantando el parche al martes 21.
Al cierre de este artículo no hay exploit público ni ataques masivos confirmados, pero los investigadores coinciden en que es cuestión de días: varios equipos ya están reproduciendo el fallo y el propio aviso oficial confirma que existe un exploit funcional. El NCSC británico recomienda desconectar los sistemas que no se puedan actualizar ya.
A quién afecta
A cualquier instalación de PHP que sirva páginas web, sea cual sea la forma de ejecutarlo:
- Apache con mod_php: el caso más grave. El ataque funciona con una sola petición y sin tocar tu código.
- PHP-FPM (Nginx, la mayoría de hostings modernos): también vulnerable, con condiciones algo más difíciles de reunir.
- php-cgi, FrankenPHP y LiteSpeed: afectados.
Lo que importa es la versión de PHP, no la aplicación. Un WordPress perfectamente actualizado sobre un PHP sin parchear sigue siendo vulnerable.
Qué versiones están corregidas
| Rama | Versión segura | Soporte |
|---|---|---|
| PHP 8.5 | 8.5.12 o superior | ✅ |
| PHP 8.4 | 8.4.27 o superior | ✅ |
| PHP 8.3 | 8.3.36 o superior | ✅ |
| PHP 8.2 | 8.2.35 o superior | ⚠️ Fin de soporte el 31/12/2026 |
| PHP 8.1, 8.0 y 7.4 | Sin versión oficial | ❌ Sin soporte |
| PHP 7.3 y anteriores | Sin parche | ❌ Sin soporte |
Si estás en PHP 8.1 o anterior, no habrá actualización oficial. PHP ha publicado parches mínimos de código fuente para 7.4, 8.0 y 8.1, y algunas distribuciones Linux los incluirán en sus paquetes, pero lo sensato es subir a 8.3 o 8.4 cuanto antes.
Qué hacer hoy
1. Comprueba tu versión de PHP
En un hosting compartido, la verás en el panel de control (normalmente en un apartado Configuración de PHP). En WordPress: Herramientas > Salud del sitio > Información > Servidor. En un servidor propio:
php -vOjo: la versión de la línea de comandos puede no coincidir con la que usa la web. Si tienes dudas, crea un info.php con <?php phpinfo();, ábrelo en el navegador y bórralo en cuanto lo veas.
2. Actualiza
- Hosting compartido o gestionado: los proveedores recibieron el parche antes de hacerse público y la mayoría ya lo está aplicando. Confirma con tu proveedor que tu versión es igual o posterior a las de la tabla. Si estás en PHP 8.1 o anterior, cambia de versión desde el panel.
- Servidor propio (Debian, Ubuntu, RHEL…): actualiza los paquetes de PHP de tu distribución y reinicia PHP-FPM o Apache. Sin reinicio, los procesos siguen ejecutando el código viejo.
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm # o apache2, según tu instalaciónSi usas el repositorio de Remi (rpms.remirepo.net), no tuvo los paquetes el día 21: pasa a los paquetes de tu distribución o compila desde el código fuente.
3. Si no puedes actualizar ya: mitigaciones temporales
Reducen el riesgo, no lo eliminan. PHP lo deja claro: no hay mitigación completa, solo actualizar es seguro. Añádelas en el php.ini o en la configuración del pool de FPM (no en .user.ini ni con ini_set(), que llegan tarde) y reinicia todos los procesos:
; CVE-2026-109618
memory_limit = -1
post_max_size = 8M ; 32M si tu web necesita subir archivos
upload_max_filesize = 8M ; siempre por debajo de post_max_size
; CVE-2026-109619
session.upload_progress.enabled = 0
fatal_error_backtraces = 0 ; solo PHP 8.5Además:
- Limita el tamaño de las peticiones en Nginx, Apache o tu proxy. Si tu web no tiene formularios con archivos, bloquea las peticiones multipart antes de que lleguen a PHP.
- Si usas Cloudflare, ya tiene reglas de WAF para los vectores conocidos, también en el plan gratuito.
- No uses
RLIMIT_ASniRLIMIT_DATApara limitar memoria: provocan justo el fallo que se quiere evitar.
4. Revisa que no te hayan entrado
Si tu web estuvo expuesta, vigila durante las próximas semanas: archivos .php nuevos o modificados en carpetas de subidas, usuarios administradores que no reconoces, tareas programadas extrañas o picos de tráfico saliente. Que no haya nada raro en los logs no garantiza que no te hayan atacado.
Resumen
- PHP2Shell son dos fallos críticos (CVE-2026-109618 y CVE-2026-109619) que permiten ejecutar código en tu servidor sin autenticación.
- Afecta a todo PHP que sirva webs, con o sin WordPress; el peor caso es Apache con mod_php.
- Versiones seguras: 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
- PHP 8.1 o anterior: sin parche oficial; actualiza de rama.
- Las mitigaciones ayudan mientras actualizas, pero solo el parche te protege.
Si tienes una web y no sabes qué versión de PHP usa o cómo actualizarla, escríbeme y lo revisamos.
Fuentes: anuncio oficial de PHP, avisos GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp, Rapid7, Huntress y Help Net Security.