El 21 de octubre de 2026, el proyecto PHP publicó versiones de emergencia para dos fallos críticos, CVE-2026-109618 y CVE-2026-109619, conocidos ya como PHP2Shell. Encadenados, permiten a un atacante ejecutar código en un servidor con una sola petición HTTP manipulada. El atacante no necesita iniciar sesión, ni un plugin vulnerable, ni ningún error de configuración. Si PHP responde a peticiones web en tu servidor, está expuesto hasta que lo actualices.
Los atacantes ya estaban probando el fallo días antes de que saliera la corrección, y la explotación masiva empezó a las pocas horas del lanzamiento. Los investigadores de seguridad calculan que entre 1,3 y 1,9 millones de hosts accesibles desde internet quedaron expuestos. En esta guía te explicamos qué son estas vulnerabilidades, qué versiones están corregidas, cómo parchear paso a paso un servidor propio y cómo comprobar si alguien entró antes que tú.
Puntos clave
- PHP2Shell son dos fallos críticos de PHP (CVSS 9.2) que permiten la ejecución remota de código sin autenticación con una sola petición HTTP.
- Todas las versiones de PHP desde la 5.4 están afectadas cuando sirven tráfico web: mod_php, PHP-FPM, CGI, FrankenPHP y LiteSpeed.
- Las versiones corregidas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Reinicia todos los workers de PHP después de actualizar.
- Todos los servidores cPanel y de WordPress gestionado de WebGee ya están parcheados; los clientes no tienen que hacer nada.
- La explotación comenzó antes de que existiera la corrección, así que revisa tus logs y archivos en busca de señales de intrusión incluso después de parchear.
Clientes de WebGee: ya estáis protegidos Nuestros ingenieros han actualizado todos los servidores cPanel compartidos y de revendedor de WebGee y todos los servidores de Hosting WordPress Gestionado a las versiones corregidas de PHP, y después han reiniciado todos los workers de PHP. No tienes que hacer nada. Esta guía es para servidores que gestionas tú, como un VPS, un servidor dedicado o un servidor cloud con acceso root.
¿Qué es PHP2Shell?
PHP2Shell es el nombre que reciben dos fallos de seguridad de memoria en el núcleo de gestión de peticiones de PHP. Ambos están en código que se ejecuta antes de que tu aplicación (WordPress, Laravel, Magento o cualquier otra) vea la petición. Por eso tener tu CMS y tus plugins al día no te protege en este caso.
CVE-2026-109618: corrupción por falta de memoria al procesar la petición
Cuando PHP procesa un cuerpo multipart/form-data (el formato que usan los formularios y las subidas de archivos), quedarse sin memoria a mitad del proceso deja estructuras internas inicializadas a medias. Después, el código de limpieza de PHP trata ese estado roto como si fuera válido. Una petición manipulada puede forzar esta situación incluso en servidores con límites de memoria normales.
CVE-2026-109619: estado global obsoleto y use-after-free
PHP gestiona los errores fatales con longjmp(), que salta fuera del código que falla sin deshacerlo ordenadamente. Tras el error de memoria anterior, el estado global asociado a la petición puede quedar apuntando a memoria que ya se ha liberado. La siguiente petición que gestione el mismo worker de PHP puede entonces usar esa memoria. Los investigadores han confirmado tanto la filtración de memoria como la ejecución remota de código completa.
Juntos, los dos fallos convierten una única petición POST malformada en una shell que se ejecuta como el usuario de tu servidor web (www-data, apache o nobody). A partir de ahí, un atacante puede leer tu wp-config.php y las credenciales de la base de datos, instalar puertas traseras, enviar spam o adentrarse más en tu red.
¿Qué gravedad tiene?
- Gravedad: ambos CVE tienen una puntuación CVSS v4.0 de 9.2 (crítica). En los primeros avisos circuló una puntuación de 10.0.
- Autenticación: no se requiere. El fallo es accesible desde cualquier URL que procese PHP.
- Explotación: confirmada en ataques reales, y circula código público de prueba de concepto.
- Aplicaciones: se ha demostrado la ejecución de código sin autenticación en WordPress, Drupal, Joomla y Magento.
- Antigüedad: el código vulnerable se remonta a PHP 5.4.0, así que los servidores muy antiguos también están afectados.
¿A quién afecta?
A cualquier instalación de PHP que sirva tráfico web, sea cual sea la API de servidor que use:
- Apache con mod_php: el mayor riesgo, porque el procesamiento vulnerable se ejecuta dentro del propio worker de Apache.
- PHP-FPM detrás de nginx, Apache o Caddy.
- php-cgi, FrankenPHP y LiteSpeed (LSAPI).
El PHP que solo se usa en línea de comandos (tareas cron, workers que nunca procesan cuerpos HTTP) no es accesible directamente, pero normalmente el mismo binario también está instalado para la web. Actualízalo todo.
Versiones de PHP corregidas
Actualiza como mínimo a la versión indicada para tu rama:
- PHP 8.5: 8.5.12 o posterior
- PHP 8.4: 8.4.27 o posterior
- PHP 8.3: 8.3.36 o posterior
- PHP 8.2: 8.2.35 o posterior
- PHP 7.4 a 8.1: no hay versión oficial. Las correcciones solo existen como backports en el código fuente y a través de proveedores como CloudLinux (alt-php) y algunas distribuciones de Linux.
- PHP 5.4 a 7.3: sin soporte y sin corrección. Actualiza o saca el sitio de internet.
Paso 1: comprueba qué versión de PHP usa tu servidor
Comprueba tanto el binario de línea de comandos como la versión que usa realmente tu servidor web. A menudo son distintas.
# Command-line PHP
php -v
# Every PHP binary installed on the server
ls /usr/bin/php* /usr/sbin/php-fpm* /opt/cpanel/ea-php*/root/usr/bin/php /opt/alt/php*/usr/bin/php 2>/dev/null
# The version your web server serves: drop a temporary file, fetch it, then delete it
echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/v.php >/dev/null
curl -s https://your-domain.com/v.php; echo
sudo rm /var/www/html/v.phpNo dejes archivos phpinfo() olvidados Si usas un archivo phpinfo() o de versión para comprobarlo, bórralo inmediatamente después. Los atacantes buscan estos archivos para identificar servidores vulnerables.
Paso 2: parchea PHP en tu servidor
Elige la sección correspondiente a tu plataforma. Después de actualizar, tienes que reiniciar todos los procesos de PHP. Los workers antiguos siguen ejecutando el código vulnerable hasta que se sustituyen.
Ubuntu y Debian
sudo apt update
sudo apt install --only-upgrade 'php*-common' 'php*-cli' 'php*-fpm' 'libapache2-mod-php*'
# Restart PHP-FPM (repeat for each installed version)
sudo systemctl restart php8.3-fpm
# Using mod_php? Restart Apache instead
sudo systemctl restart apache2
# Confirm
php -vSi instalas PHP desde el PPA ondrej/php o un repositorio de terceros similar, asegúrate de que ese repositorio ha publicado las versiones corregidas antes de dar por hecho que estás protegido.
AlmaLinux, Rocky Linux y RHEL
sudo dnf clean all
sudo dnf upgrade 'php*'
# Restart PHP-FPM and the web server
sudo systemctl restart php-fpm
sudo systemctl restart httpd # or nginx
php -vServidores cPanel y WHM (EasyApache ea-php)
cPanel distribuye PHP en paquetes ea-php. Actualízalos todos a la vez:
# CloudLinux / CentOS 7
yum clean all && yum update "ea-php*"
# AlmaLinux / CloudLinux 8, 9 and 10
dnf clean all && dnf upgrade "ea-php*"
# Restart PHP-FPM for all accounts, then Apache or LiteSpeed
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd
# Check each installed version
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo -n "$p: "; $p -r 'echo PHP_VERSION, PHP_EOL;'; doneCloudLinux alt-php (PHP Selector)
CloudLinux incorpora la corrección en todas las ramas de alt-php, incluidas versiones sin soporte como la 5.6 y la 7.4. El número de versión no cambia, así que revisa el registro de cambios del paquete en lugar de php -v:
yum clean all && yum update 'alt-php*' 'ea-php*' -y
# Confirm the fix is in the installed package (example: alt-php 7.4)
rpm -q --changelog alt-php74 | grep -m1 -i 'CVE-2026-109618'Docker y contenedores
Los contenedores no se actualizan solos. Descarga la imagen oficial parcheada, vuelve a compilar y despliega de nuevo:
# Pin to a fixed release (or newer)
FROM php:8.3.36-fpm
# ...your existing build stepsdocker pull php:8.3.36-fpm
docker compose build --pull
docker compose up -d
# Confirm inside the running container
docker compose exec app php -vPaso 3: mitigaciones temporales si no puedes parchear hoy
Estos ajustes reducen la exposición, pero no corrigen el fallo. Úsalos solo para ganar tiempo mientras programas la actualización, por ejemplo en PHP 7.3 o anterior, donde no existe corrección.
Refuerza php.ini
El exploit depende de que se alcance el propio límite de memoria de PHP durante el procesamiento. Desactivar ese límite a nivel de PHP (y aplicar un límite estricto en otro nivel, como verás más abajo) elimina el desencadenante principal. El seguimiento del progreso de subida es otra vía de acceso al código vulnerable.
; /etc/php/8.3/fpm/conf.d/99-php2shell.ini (adjust the path to your version)
; Interim mitigation for CVE-2026-109618 / CVE-2026-109619
memory_limit = -1
session.upload_progress.enabled = 0
post_max_size = 1M
; PHP 8.5 only
fatal_error_backtraces = 0Aplicaciones como WordPress aumentan memory_limit por su cuenta en tiempo de ejecución. Fija los valores en el pool de PHP-FPM para que el código no pueda sobrescribirlos:
; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_flag[session.upload_progress.enabled] = offCombina siempre memory_limit = -1 con un límite estricto Sin límite de memoria en PHP, un solo script descontrolado puede consumir toda la RAM del servidor. Limita la memoria a nivel de proceso, con un MemoryMax de systemd para el servicio PHP-FPM o un límite de memoria del contenedor, para que sea el kernel, y no PHP, quien detenga un worker descontrolado.
# Cap PHP-FPM memory with systemd
sudo systemctl edit php8.3-fpm
# [Service]
# MemoryMax=2G
# Or, for Docker:
docker update --memory 2g --memory-swap 2g <container>Limita el tamaño del cuerpo de la petición en el servidor web
Rechaza los cuerpos demasiado grandes antes de que lleguen a PHP. Así se bloquean los payloads grandes y manipulados que usan los exploits públicos, pero también se bloquearán las subidas grandes legítimas, así que aumenta el límite solo en las rutas que lo necesiten.
# nginx: inside http {} or server {}
client_max_body_size 1m;
# Allow bigger uploads only where needed, e.g. the WordPress media uploader
location = /wp-admin/async-upload.php {
client_max_body_size 64m;
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}# Apache: in the vhost or .htaccess (bytes)
LimitRequestBody 1048576Después, reinicia todos los workers de PHP para que ninguno conserve un estado corrupto:
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx # or: sudo systemctl restart apache2Si tu sitio está detrás de Cloudflare, activa sus reglas WAF gestionadas para esta vulnerabilidad; Cloudflare ha habilitado la protección también en el plan gratuito. Eso sí, considera el WAF una capa adicional, no un sustituto del parche. El CERT-EU también recomienda aislar las aplicaciones PHP expuestas a internet que no se puedan parchear de inmediato.
Paso 4: comprueba si ya te han comprometido
La explotación empezó antes de que la mayoría pudiera parchear, así que actualizar no es el final del trabajo. Busca estas señales.
Errores de falta de memoria en la línea 0
Los intentos, fallidos o exitosos, dejan un error fatal de memoria sin archivo ni línea reales, normalmente junto a un POST inusualmente grande:
sudo grep -R "Allowed memory size of .* exhausted .* in Unknown on line 0" \
/var/log/php*-fpm.log /var/log/apache2/error.log /var/log/httpd/error_log \
/var/log/nginx/error.log 2>/dev/null | tail -n 50Fallos de los workers
# Apache children dying with segfaults
sudo grep -R "AH00052: child pid .* exit signal Segmentation fault" /var/log/apache2/ /var/log/httpd/ 2>/dev/null
# PHP-FPM workers killed by signals
sudo grep -R "exited on signal" /var/log/php*-fpm.log 2>/dev/nullShells iniciadas por el usuario del servidor web
# A shell running under apache, www-data or php-fpm is a red flag
ps aux | grep -E "(apache|www-data|php-fpm|nobody)" | grep -E "\b(sh|bash|dash)\b" | grep -v grep
# Unexpected outbound connections from the web user
sudo ss -tunp | grep -E "php|apache|httpd|nginx"Puertas traseras y persistencia
# PHP files changed in the last 7 days
sudo find /var/www -type f -name "*.php" -mtime -7 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -n 50
# PHP files in upload folders (they should never be there)
sudo find /var/www -path "*uploads*" -name "*.php"
# Cron jobs added for the web user
sudo crontab -u www-data -l 2>/dev/null; sudo crontab -u apache -l 2>/dev/nullEn tus logs de acceso, busca peticiones POST con nombres de campo de formulario enormes (más de 1 MB), bytes binarios o nulos en el cuerpo, o una estructura como =[binary]&a=1&[long field][x]=1.
Un exploit exitoso no siempre provoca un fallo, así que un log limpio no demuestra que estés a salvo. Si encuentras cualquiera de estas señales, da por hecho que te han comprometido:
- desconecta el sitio o ponlo en modo mantenimiento;
- cambia las contraseñas de la base de datos, las claves de API y los salts de WordPress;
- restaura una copia de seguridad anterior al 17 de octubre de 2026;
- y parchea antes de volver a poner el sitio en línea.
Lista de respuesta ante PHP2Shell
- Localiza todas las versiones de PHP del servidor, tanto CLI como web
- Actualiza a 8.2.35, 8.3.36, 8.4.27, 8.5.12 o a un backport del proveedor
- Reinicia PHP-FPM, Apache o LiteSpeed para que no quede ningún worker antiguo
- Vuelve a compilar y desplegar los contenedores a partir de imágenes parcheadas
- Aplica los ajustes temporales de php.ini y los límites de tamaño del cuerpo en todo lo que aún no puedas parchear
- Busca en los logs errores de memoria en la línea 0 y segfaults
- Comprueba si hay shells del usuario web, archivos PHP nuevos o tareas cron nuevas
- Cambia las credenciales si algo parece sospechoso
Por qué esto sigue ocurriendo y cómo ayuda el hosting gestionado
PHP2Shell pasó del primer impacto en un honeypot a la explotación masiva en menos de una semana, y la mayor parte ocurrió antes de que existiera una corrección. Para una empresa que gestiona su propio servidor, defenderse de algo así implica tener a alguien vigilando las fuentes de seguridad las 24 horas, probando las actualizaciones y aplicándolas en cada versión de PHP y en cada worker en cuanto se publican. A menudo eso hay que hacerlo a las 2 de la madrugada, en fin de semana, mientras ya se están usando exploits públicos.
Eso es exactamente lo que hace nuestro equipo por los clientes de WebGee. Con PHP2Shell, nuestros ingenieros:
- aplicaron las versiones corregidas de PHP en todos los servidores cPanel compartidos y de revendedor;
- actualizaron todos los servidores de Hosting WordPress Gestionado a la última versión parcheada de PHP;
- reiniciaron todos los workers de PHP para que no quedara ningún proceso vulnerable en ejecución;
- y lo hicieron todo sin que los clientes tuvieran que hacer nada.
Además de los parches, el hosting de WebGee incluye análisis de malware a nivel de servidor, un firewall de aplicaciones web y copias de seguridad diarias. Si en algún momento un ataque consigue colarse, tendrás un punto de restauración limpio.
Si usas WordPress, WooCommerce u otra aplicación PHP en un servidor que tienes que parchear tú, plantéate dejar esa tarea en nuestras manos. Migramos tu sitio gratis y sin ningún tiempo de inactividad.
¿Prefieres mantener tu propio servidor?
Si necesitas acceso root, un servidor cloud de WebGee te da control total, y nuestros ingenieros de soporte pueden ayudarte a parchearlo, reforzarlo y monitorizarlo. Para sitios que solo necesitan seguir siendo rápidos y seguros, el Hosting WordPress Gestionado y el hosting cloud con cPanel mantienen PHP actualizado por ti. ¿No sabes cuál te conviene? Habla con nuestro equipo.
Preguntas frecuentes
Tengo mi web alojada en WebGee. ¿Tengo que hacer algo?
No. Hemos actualizado todos los servidores cPanel compartidos y de revendedor de WebGee, así como todos los servidores de Hosting WordPress Gestionado, a las versiones corregidas de PHP, y hemos reiniciado todos los workers de PHP. Si gestionas tu propio servidor cloud o dedicado con acceso root, sigue los pasos de esta guía o contacta con nuestro equipo de soporte para que te ayude.
¿Actualizar WordPress o mis plugins soluciona PHP2Shell?
No. Las vulnerabilidades están en el propio PHP y se activan antes de que se ejecute WordPress o cualquier otro código de la aplicación. Tienes que actualizar los paquetes de PHP del servidor y reiniciar PHP.
¿Qué versiones de PHP corrigen CVE-2026-109618 y CVE-2026-109619?
PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12, o cualquier versión posterior. De PHP 7.4 a 8.1 solo hay backports en el código fuente y compilaciones de proveedores como CloudLinux alt-php. De PHP 5.4 a 7.3 no hay corrección.
Uso una versión antigua de PHP que no tiene corrección. ¿Qué hago?
Actualiza a una rama de PHP con soporte lo antes posible. Mientras tanto, aplica los ajustes temporales de php.ini y los límites de tamaño de petición de esta guía, protege el sitio con un WAF o sácalo de internet. CloudLinux alt-php también incluye correcciones adaptadas para muchas versiones sin soporte.
¿Basta con un firewall de aplicaciones web?
No. Un WAF puede bloquear patrones de exploit conocidos y te da margen, pero los atacantes cambian sus payloads. Parchear PHP es la única solución real.
¿Cómo sé si han hackeado mi servidor?
Busca errores 'Allowed memory size ... in Unknown on line 0', workers que fallan con segfault, shells ejecutándose como el usuario del servidor web, archivos PHP modificados recientemente, archivos PHP en carpetas de subida y nuevas tareas cron. Un ataque exitoso puede no dejar ningún fallo, así que, ante la duda, cambia las credenciales y restaura una copia de seguridad anterior al 17 de octubre de 2026.
