¿Tu web es vulnerable a
PHP2Shell?

Qué es PHP2Shell: la vulnerabilidad crítica de PHP de 2026, explicada claro

PHP es el motor invisible de la mayoría de webs: WordPress, tiendas online, intranets. Se han encontrado dos fallos graves en ese motor.

PHP2Shell es el nombre con el que se conocen dos vulnerabilidades críticas del núcleo de PHP, divulgadas y corregidas el 21 de octubre de 2026, valoradas con 9.2 sobre 10 en la escala CVSS 4.0. Los fallos permiten que alguien, sin tener acceso ni contraseña, le envíe a tu web una petición preparada y consiga ejecutar sus propias órdenes en el servidor. Si eso ocurriera, podría modificar la web, acceder a los datos que guarda o usarla para atacar a otros. Afectan a prácticamente todas las versiones de PHP que no se hayan actualizado, y el riesgo es mayor en servidores que usan mod_php.

¿Afecta a mi web? Versiones de PHP afectadas y corregidas

Si tu web usa PHP y no se ha actualizado desde el 21 de octubre de 2026, podría estar expuesta. No necesitas saber qué versión tienes: el comprobador de arriba te da una primera pista y, si no se puede ver desde fuera, abajo tienes qué preguntar.

Como visitante de otras webs, puedes navegar con normalidad. Estos fallos afectan al servidor, no a tu ordenador o móvil.

Qué hacer si tu web la lleva otra persona

No tienes que tocar nada. Tienes que preguntar. Copia este correo y envíalo a tu hosting o a quien te hizo la web:

Si en 48 horas no tienes respuesta clara, es una señal en sí misma. Una web necesita a alguien que la mantenga.

Cómo actualizar PHP frente a PHP2Shell, paso a paso

Lo definitivo es actualizar PHP. Las mitigaciones solo reducen la exposición mientras tanto.

1. Paso 1 · Comprueba tu versión y tu SAPI

   En el servidor, mira qué versión corre y cómo (mod_php, PHP-FPM o CGI):

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

   Si usas paquetes del sistema, revisa también el changelog de tu distro: la corrección puede venir aplicada sin que cambie el número de versión.

2. Paso 2 · Actualiza a la versión corregida

   8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 según tu rama. Ejemplos:

   # Debian / Ubuntu
   sudo apt update && sudo apt upgrade php*
   
   # RHEL / AlmaLinux / Rocky
   sudo dnf update php\*

   Con Docker, cambia a la etiqueta corregida de la imagen y reconstruye.

3. Paso 3 · Reinicia todos los workers de PHP

   La actualización no se aplica hasta reiniciar los procesos. Varias mitigaciones tampoco funcionan vía ini_set() o .user.ini: hay que reiniciar.

   sudo systemctl restart php8.3-fpm   # o tu versión
   sudo systemctl restart apache2      # si usas mod_php

4. Paso 4 · Si todavía no puedes actualizar: mitigaciones temporales

   Aplícalas en la configuración efectiva (php.ini del SAPI web o pool de FPM), de forma que la aplicación no pueda sobrescribirlas, y reinicia los workers. No sustituyen a la actualización.

   ; php.ini (contra CVE-2026-109619)
   session.upload_progress.enabled = 0
   
   ; (contra CVE-2026-109618)
   memory_limit = -1

   En el servidor web o proxy: bloquea multipart/form-data si no lo necesitas y baja post_max_size. En PHP 8.5, desactiva los backtraces en los fallos fatales (fatal errors).

5. Paso 5 · Empieza por lo más expuesto

   Primero los sistemas públicos y los que usan mod_php. Después paneles tipo cPanel/Plesk y aplicaciones como WordPress, Drupal, Magento o Laravel, expuestas a través del núcleo de PHP.

6. Paso 6 · Comprueba que todo está bien y busca señales de acceso previo

   Tras actualizar, revisa si alguien pudo aprovechar el fallo antes: picos de peticiones multipart seguidas de fallos de memoria o 500 repetidos, cookies PHPSESSID anómalas, reinicios inesperados de workers, ficheros PHP modificados o webshells, usuarios administradores nuevos o conexiones salientes raras. Ante la duda, cambia contraseñas, claves API y tokens de los sistemas PHP expuestos.

La comprobación fiable se hace en el servidor

Lo que esta web lee desde fuera es una pista, no una prueba. Esto es lo fiable:

# ¿Qué versión corre realmente?
php -v

# ¿El paquete del sistema incluye la corrección? (busca los CVE en el changelog)
# Debian/Ubuntu:
zcat /usr/share/doc/php*/changelog.Debian.gz 2>/dev/null | grep -i "109618\|109619"
# RHEL-like:
rpm -q --changelog php | grep -i "109618\|109619"

Preguntas frecuentes sobre PHP2Shell