ciberseguridad

Cómo actualizar PHP por PHP2Shell y saber si ya te atacaron

¿Tu red tiene estas señales?

Diagnóstico gratuito con NESS.

PHP2Shell (CVE-2026-109618 y CVE-2026-109619) ya se está explotando: desde el 21 de octubre de 2026 Amazon, VulnCheck, Cloudflare y Pantheon reportan ataques de varios actores. Ese mismo día PHP publicó 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir estas dos fallas críticas de ejecución remota de código sin autenticación. Si administras servidores o sitios en PHP, esta guía responde, con comandos, las preguntas que necesitas resolver para dejar todo parcheado hoy. El contexto completo está en PHP2Shell ya se está explotando: actualiza PHP hoy.

¿A qué versión de PHP debo actualizar?

A la versión corregida de tu rama:

PHP 8.5: 8.5.12
PHP 8.4: 8.4.27
PHP 8.3: 8.3.36
PHP 8.2: 8.2.35

Dentro de la misma rama (por ejemplo de 8.3.x a 8.3.36) el cambio es una actualización de parche, no un salto de versión mayor.

¿Cómo saber qué versión de PHP tengo?

En la línea de comandos

php -v

Ojo: la versión de la consola puede no ser la que usa tu sitio web. Si usas PHP-FPM, revisa también el binario de FPM, por ejemplo en Debian o Ubuntu:

php-fpm8.3 -v
systemctl list-units --type=service | grep -i php

Desde el navegador con phpinfo()

Crea un archivo temporal en la carpeta web con este contenido, ábrelo en el navegador y mira la versión en el encabezado. Bórralo apenas termines, porque expone información del servidor.

<?php phpinfo();

En WordPress

Entra a Herramientas > Salud del sitio > Información > Servidor. Ahí aparece la versión de PHP que realmente usa tu sitio.

¿Cómo actualizar PHP en Ubuntu o Debian?

Si usas los paquetes oficiales de tu distribución:

sudo apt update
sudo apt install --only-upgrade 'php8.3*'

Cambia 8.3 por tu rama (en Debian 12 los paquetes son php8.2, en Ubuntu 24.04 php8.3). También puedes aplicar todas las actualizaciones con sudo apt upgrade.

Importante: Debian y Ubuntu suelen retroportar los parches de seguridad sin cambiar al número de versión de PHP, así que php -v puede seguir mostrando un número menor a 8.3.36 aunque ya estés protegido. Para confirmarlo revisa el registro de cambios del paquete:

apt changelog php8.3-cli | grep -i CVE-2026-1096

Si el paquete corregido aún no aparece, revisa los avisos de seguridad de Ubuntu o de Debian.

¿Y si uso el PPA de Ondřej Surý?

El PPA ppa:ondrej/php publica las versiones de PHP con su número original, así que después de actualizar php -v debe mostrar la versión corregida (por ejemplo 8.4.27). El comando es el mismo:

sudo apt update
sudo apt install --only-upgrade 'php8.4*'

Si todavía no aparece la versión corregida, el PPA aún no la ha publicado: aplica las medidas temporales que explicamos más abajo y, si el servidor está expuesto a internet, considera sacarlo de línea hasta actualizar.

¿Cómo actualizar PHP en RHEL, AlmaLinux o Rocky Linux?

Con los paquetes de la distribución:

sudo dnf upgrade 'php*'

Para ver qué rama de PHP tienes habilitada como módulo:

dnf module list php

Igual que en Debian, Red Hat y sus derivados retroportan parches. Confirma la corrección en el registro de cambios del paquete:

rpm -q --changelog php-cli | grep -i CVE-2026-1096

¿Y si uso el repositorio de Remi?

PHP advirtió el 21 de octubre que el repositorio voluntario rpms.remirepo.net no tendría actualizaciones ese día y recomienda pasar a los paquetes de tu distribución o compilar desde el código fuente para poder parchear de inmediato. Si dependes de Remi, revisa si ya publicó la versión corregida antes de asumir que estás protegido.

¿Cómo actualizar PHP en Windows con IIS?

Descarga la versión corregida de tu rama desde windows.php.net. Usa la misma variante que tienes (NTS para IIS con FastCGI, x64).
Haz una copia de la carpeta actual de PHP, incluido tu php.ini.
Reemplaza los archivos de PHP por los nuevos y conserva tu php.ini y tus extensiones.
Reinicia IIS para que FastCGI cargue la nueva versión:

iisreset

Confirma con php -v en la carpeta de PHP y con phpinfo() desde el navegador.

¿Cómo actualizar PHP en Docker?

Las imágenes oficiales usan etiquetas por rama, como php:8.4-fpm, php:8.3-apache o php:8.2-cli. Para tomar el parche hay que descargar la imagen nueva y reconstruir tus contenedores:

docker pull php:8.4-fpm
docker compose build --pull
docker compose up -d

Antes de desplegar, verifica que la imagen ya trae la versión corregida:

docker run --rm php:8.4-cli php -v

Si fijas una versión exacta en tu Dockerfile (por ejemplo FROM php:8.4.26-fpm), cámbiala a la corregida (8.4.27) cuando esa etiqueta esté publicada. Si la imagen aún muestra una versión anterior, todavía no ha salido la etiqueta parcheada.

¿Cómo actualizar PHP en cPanel, hPanel de Hostinger o Plesk?

En hosting compartido el proveedor es quien actualiza PHP. Desde tu panel puedes ver y elegir la rama (8.2, 8.3, 8.4 u 8.5), pero el parche dentro de cada rama lo instala el proveedor.

cPanel: en MultiPHP Manager o en Select PHP Version ves la versión de cada dominio. Si administras el servidor con WHM, las versiones de PHP se instalan con EasyApache 4 y se actualizan con las actualizaciones del sistema.
hPanel de Hostinger: en la configuración de PHP del sitio ves y cambias la rama activa.
Plesk: en la configuración de PHP del dominio eliges la versión; los administradores del servidor actualizan los componentes de PHP desde el actualizador de Plesk.

Si no ves la versión corregida, escribe a soporte de tu hosting y pregunta cuándo aplicarán 8.5.12, 8.4.27, 8.3.36 u 8.2.35 (o el paquete corregido equivalente).

¿Cómo reinicio PHP-FPM, Apache o NGINX después de actualizar?

PHP no toma la versión nueva hasta que reinicias los procesos que lo cargan. Además, PHP recomienda reiniciar todos los procesos para que también apliquen los cambios de configuración.

PHP-FPM

# Debian / Ubuntu (cambia 8.3 por tu rama)
sudo systemctl restart php8.3-fpm

# RHEL / AlmaLinux / Rocky
sudo systemctl restart php-fpm

Apache con mod_php

# Debian / Ubuntu
sudo systemctl restart apache2

# RHEL / AlmaLinux / Rocky
sudo systemctl restart httpd

NGINX

NGINX no ejecuta PHP: lo pasa a PHP-FPM. Lo que hay que reiniciar es el servicio de PHP-FPM. Si cambiaste configuración de NGINX, valida y recarga:

sudo nginx -t && sudo systemctl reload nginx

Si usas NGINX, revisa también nuestra nota sobre los parches urgentes de F5 para NGINX.

¿Qué hago si tengo PHP 8.1 o anterior?

PHP 8.1 y anteriores ya no reciben versiones del proyecto PHP. Por la gravedad del caso, el equipo de seguridad publicó parches mínimos de código fuente para PHP 7.4, 8.0 y 8.1, útiles solo si compilas PHP tú mismo. Algunas distribuciones y proveedores de soporte extendido ofrecen correcciones retroportadas, así que pregúntale a tu proveedor. La salida recomendada es migrar a una rama con soporte (8.2 a 8.5) y, mientras tanto, aislar esos servidores o ponerlos detrás de una VPN o un WAF.

¿Sirve desactivar session.upload_progress?

Ayuda, pero no protege del todo. PHP indica que poner session.upload_progress.enabled=0 bloquea las rutas de sesión confirmadas de CVE-2026-109619, pero no otras variantes, y no hace nada contra CVE-2026-109618. Si lo aplicas mientras actualizas:

Configúralo en php.ini, en el pool de FPM o en la configuración del servidor, porque debe aplicar antes de procesar la petición.
No uses ini_set() ni .user.ini.
Reinicia todos los procesos de PHP.

; php.ini
session.upload_progress.enabled = 0

; pool de PHP-FPM (por ejemplo www.conf)
php_admin_value[session.upload_progress.enabled] = 0

Para CVE-2026-109618, PHP sugiere fijar memory_limit=-1 de forma que las aplicaciones no lo puedan cambiar (por ejemplo con php_admin_value en el pool de FPM), además de bajar post_max_size (8M si no necesitas subir archivos, 32M si sí) y mantener upload_max_filesize por debajo. En PHP 8.5 recomienda también fatal_error_backtraces=0. Ninguna de estas medidas reemplaza la actualización.

¿Actualizar WordPress actualiza PHP?

No. WordPress, sus plugins y temas corren encima de PHP, que es software del servidor. Actualizar WordPress no cambia tu versión de PHP. PHP se actualiza en el servidor (con los comandos de esta guía) o lo actualiza tu hosting. Puedes confirmar la versión en Herramientas > Salud del sitio > Información > Servidor.

¿Cómo verifico que quedé parcheado?

Revisa la versión de cada forma en que corre PHP: consola (php -v), PHP-FPM (php-fpm8.3 -v) y el sitio web (phpinfo() temporal o Salud del sitio de WordPress).
Si usas paquetes de la distribución, busca los CVE en el registro de cambios del paquete, porque el número de versión puede no cambiar:

# Debian / Ubuntu
apt changelog php8.3-cli | grep -i CVE-2026-1096

# RHEL / AlmaLinux / Rocky
rpm -q --changelog php-cli | grep -i CVE-2026-1096

Confirma que reiniciaste PHP-FPM o Apache después de actualizar. Un proceso viejo sigue corriendo el código vulnerable aunque el paquete nuevo ya esté instalado.
Revisa cada servidor y contenedor, no solo el principal. Un inventario de activos te evita olvidar el servidor de pruebas que quedó expuesto.

¿Cómo sé si ya me atacaron?

No es fácil. Según CrowdStrike, el ataque casi no deja rastro: los procesos siguen estables, las respuestas salen con código HTTP 200 y los logs de la aplicación no muestran nada, porque el código de la aplicación nunca llega a ejecutarse. El único indicio del lado del servidor es una línea de error fatal por límite de memoria en el log de errores del servidor web, un mensaje que suele descartarse como ruido.

Busca errores fatales de memoria en el log de errores desde el 17 de octubre, fecha del primer intento que detectó Amazon. En PHP ese error suele decir “Allowed memory size of … bytes exhausted”. Las rutas típicas son estas:

# Apache en Debian / Ubuntu
sudo grep -i "allowed memory size" /var/log/apache2/error.log*

# Apache en RHEL / AlmaLinux / Rocky
sudo grep -i "allowed memory size" /var/log/httpd/error_log*

# NGINX con PHP-FPM
sudo grep -i "allowed memory size" /var/log/nginx/error.log*

Vigila los procesos de PHP: el FBI recomienda alertar si un proceso de PHP lanza intérpretes de comandos o descarga archivos de forma inesperada.

ps -ef --forest | grep -E -A3 "php-fpm|php-cgi|apache2|httpd"

Revisa cambios recientes: archivos nuevos o modificados en la carpeta web, tareas cron y cuentas de usuario nuevas.

sudo find /var/www -type f -newermt "2026-10-17" -name "*.php"
sudo crontab -l; ls -la /etc/cron.d/

Si encuentras errores de memoria en un servidor que estuvo sin parchear, o cualquiera de estas señales, trátalo como posiblemente comprometido: actualiza, cambia credenciales y revisa el servidor a fondo antes de darlo por limpio. Parchear cierra la puerta, pero no borra lo que un atacante haya dejado adentro.

¿Cómo pruebo la compatibilidad antes de subir de versión?

Si solo pasas a la versión corregida de tu misma rama, el riesgo de incompatibilidad es bajo. Si tienes que saltar de rama (por ejemplo de 8.1 a 8.2 o superior):

Prueba primero en un entorno de pruebas con la misma versión de destino.
Lee las guías de migración del manual de PHP, por ejemplo Migración de PHP 8.1.x a PHP 8.2.x.
Analiza tu código con PHPCompatibility para PHP_CodeSniffer:

composer require --dev phpcompatibility/php-compatibility
vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.2-

En WordPress, actualiza plugins y tema, revisa que sean compatibles con tu versión de destino y haz una copia de seguridad antes de cambiar la rama en el panel.

Mantén tus servidores parcheados sin perseguir versiones a mano

Con NESS Enterprise, NESS Unified IT Defense reúne en un solo agente gestión de parches, inventario de activos y monitoreo de infraestructura, junto con NESS Endpoint Protection y su motor antimalware propio. Así sabes qué servidores tienes, qué versiones corren y cuáles faltan por actualizar. Si quieres verlo funcionando, agenda una demo de NESS.

Fuentes

Tyna

Detecta antes del cifrado

Monitoreo, EDR y parches en un solo agente.

NESS correlaciona eventos con IA cada 5 segundos y reduce hasta 98% los tiempos de respuesta.

+450empresas en LATAM

+7países

+4Mvulnerabilidades gestionadas