PHP2Shell: la vulnerabilidad crítica de PHP y qué tienes que hacer hoy

No es la típica vulnerabilidad de un plugin que afecta a unas pocas webs. Esta vez el problema está en el propio PHP, el lenguaje en el que funcionan WordPress, PrestaShop, Magento, Joomla, Drupal, Laravel y buena parte de internet. Te explicamos qué ha pasado, cómo saber si tu web está expuesta y qué hacer según dónde la tengas alojada.

Qué ha pasado

Investigadores de Wiz, con ayuda de modelos de IA, encontraron varios fallos de gestión de memoria en PHP. El problema aparece cuando un proceso de PHP se queda sin memoria a mitad de una petición: algunas estructuras internas no se limpian bien y la siguiente petición que atiende ese mismo proceso puede acabar usando memoria que controla el atacante. Con eso se puede llegar a ejecutar código en el servidor.

Los fallos se agrupan en dos identificadores:

Lo peor es que no hace falta que tu código tenga ningún fallo: basta con enviar peticiones preparadas a cualquier web en PHP vulnerable. Y la noticia se filtró el 20 de octubre, un día antes de que salieran los parches, así que los atacantes han tenido ventaja. Amazon, Cloudflare y watchTowr han informado de intentos de explotación.

Versiones afectadas y versiones seguras

Qué hacer según dónde esté tu web

Si tienes un hosting compartido

El que tiene que actualizar PHP es tu proveedor. Escríbele y pregunta si sus servidores ya tienen el parche de CVE-2026-109618 y CVE-2026-109619, también en las versiones antiguas de PHP que ofrezca. Si no te da una respuesta clara, es mala señal.

Si tienes un VPS o un servidor propio

Aquí te toca a ti. Los pasos generales:

1. Comprueba qué PHP usas.

   php -v
   php -i | grep "Server API"

2. Actualiza los paquetes. En Debian o Ubuntu: apt update && apt upgrade. En AlmaLinux o Rocky: dnf upgrade. Si usas cPanel o Plesk, lanza su actualización de PHP desde el panel.
3. Comprueba que el parche está. En sistemas con RPM: rpm -q --changelog NOMBRE-DEL-PAQUETE | head y busca los CVE. En Debian/Ubuntu, revisa el aviso de seguridad de tu distribución.
4. Reinicia PHP. Si no reinicias PHP-FPM, LiteSpeed o Apache, seguirán funcionando los binarios antiguos en memoria: systemctl restart php8.3-fpm (cambia la versión por la tuya).
5. Si usas Docker. Descarga la imagen oficial actualizada y recrea los contenedores: docker compose pull && docker compose up -d.

Si tu VPS es administrado, las actualizaciones de seguridad forman parte del servicio: escribe a tu proveedor para confirmar que está hecho.

Si tu PHP es 8.1 o anterior y no puedes actualizar

PHP no publicará versiones corregidas para ramas sin soporte. Tus opciones son compilar PHP con los parches publicados en código fuente, usar un PHP con soporte extendido (como el de CloudLinux) o, lo más sensato, aprovechar para actualizar la web a una versión moderna.

Medidas temporales mientras parcheas

Los desarrolladores de PHP han sido claros: no hay ninguna configuración que lo solucione del todo. Aun así, mientras actualizas, ayuda:

• Desactivar session.upload_progress.enabled en el php.ini si no lo usas (casi nadie lo usa).
• En PHP 8.5, poner fatal_error_backtraces = 0.
• Activar un WAF con reglas para PHP2Shell, como los que han publicado Cloudflare o Fastly.

Estas medidas bloquean los ataques conocidos, pero no todas las variantes. Son un parche de emergencia, no una solución.

Cómo saber si alguien lo ha intentado

Revisa los registros de tu servidor en busca de:

• Peticiones multipart/form-data raras seguidas de errores «Allowed memory size exhausted».
• Rachas de errores HTTP 500 sin motivo aparente.
• Cookies PHPSESSID anormalmente largas o con caracteres extraños.
• Procesos de PHP que se reinician continuamente.

Si ves algo de esto en un servidor sin parchear, trátalo como un posible incidente: parchea, revisa los ficheros modificados recientemente y cambia contraseñas y claves. Una buena política de copias de seguridad te puede salvar en un caso así.

¿Y WordPress?

WordPress no tiene que publicar ninguna actualización, porque el fallo no está en WordPress sino en PHP. Pero eso no significa que tu WordPress esté a salvo: si el PHP de tu servidor es vulnerable, tu web también lo es. Lo mismo para PrestaShop, WooCommerce, Magento o cualquier aplicación PHP.

Fuentes: avisos de seguridad del proyecto PHP del 21 de octubre de 2026, Wiz Research, watchTowr y The Hacker News.