Parche de seguridad PHP (php2shell)
php2shell son dos fallos críticos de PHP publicados el 21 de octubre de 2026 (CVSS v4.0 9.2, sin autenticación). Afectan a cualquier web que sirva peticiones con PHP, sea WordPress, Drupal, Joomla, Magento, PrestaShop o Laravel. Están corregidos en 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
¿Tienes esta vulnerabilidad? Te actualizamos PHP, aplicamos la mitigación temporal donde todavía no se pueda actualizar y revisamos que no haya rastro de intrusión.
$ php -vPHP 8.3.30 (cli)# 8.3.30 < 8.3.36: afectado$ php-fpm8.3 -vPHP 8.3.30 (fpm-fcgi)# La CLI y FPM pueden tener versiones distintas$ php -i | grep upload_progress.enabledsession.upload_progress.enabled => On => On# Mitigación temporal: 0 en php.ini y reiniciar FPM8.5.12 · 8.4.27 · 8.3.36 · 8.2.35php2shell: dos fallos críticos en el propio intérprete
El 21 de octubre de 2026 el proyecto PHP publicó versiones nuevas para corregir CVE-2026-109618 y CVE-2026-109619. Adelantó la publicación a las 14:00 UTC porque el día anterior un post en Hacker News había filtrado los identificadores antes del embargo.
CVE-2026-109618 es una corrupción de memoria: si PHP se queda sin memoria a mitad de preparar los datos de la petición, la limpieza trata datos inválidos como válidos. Basta una petición multipart manipulada que agote la memoria aunque su tamaño parezca dentro de los límites. CVE-2026-109619 deja estado interno liberado entre peticiones, y una petición posterior en el mismo worker lo reutiliza. Huntress lo describe como un use-after-free en el heap sin autenticación, con fuga de memoria y ejecución remota de código con los privilegios del worker web.
El fallo está en PHP, así que actualizar el CMS o los plugins no lo corrige. Según php.net afecta a todas las instalaciones que sirven peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es mayor con mod_php, donde Rapid7 indica que es explotable antes de que llegue a ejecutarse el código de la aplicación. Wiz demostró ejecución remota sin autenticación contra WordPress, Drupal y Joomla, y una vía de fuga de memoria que podría exponer contraseñas, tokens, API keys y certificados.
A 21 de octubre, Rapid7 esperaba explotación y varios equipos la estaban reproduciendo; Huntress no la había observado en sus clientes. El NCSC británico y CERT-EU emitieron alertas ese mismo día. PHP está detrás de cerca del 69,7 % de las webs cuyo lenguaje de servidor se conoce, según W3Techs.
Fuentes: php.net · Rapid7 · Huntress · NCSC · Infosecurity Magazine
Versiones corregidas de PHP
Si tu servidor sirve peticiones web con PHP y su versión es anterior a la de su rama en esta tabla, estás afectado. Las distribuciones Linux con soporte extendido sacaron sus paquetes antes: ahí manda el aviso de tu proveedor, no el número.
| Rama | Corregida en | Nota |
|---|---|---|
| 8.5 | 8.5.12 | |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | Fin de vida el 31-dic-2026 |
| 8.1, 8.0, 7.4 | Sin versión oficial | PHP publicó backports mínimos en código fuente para quien compile |
| 7.3 y anteriores | Sin corrección | Migrar a una rama con soporte |
Revisa esto
- Tu web es WordPress, Drupal, Joomla, Magento, PrestaShop, Laravel o cualquier otra aplicación PHP accesible desde internet.
-
php -vophp-fpm -vdan un número inferior al de tu rama en la tabla. - Usas Apache con
mod_php: es la configuración de más riesgo. - Usas el PHP de tu distribución Linux: el número puede no cambiar aunque el paquete esté parcheado, así que hay que mirar el aviso del proveedor.
- Estás en un hosting compartido: actualiza el proveedor, pero puedes ver la versión en el panel o con
phpinfo()y pedirle la fecha.
Si hoy no puedes actualizar
Estas son las mitigaciones temporales que publicó el proyecto PHP. Reducen la exposición mientras preparas la actualización, pero no la sustituyen.
- 01 Pon
session.upload_progress.enabled=0enphp.inio en el pool de PHP-FPM y reinicia todos los workers. Conini_set()o.user.inino sirve. - 02 En PHP 8.5, además,
fatal_error_backtraces=0. - 03 Limita en el servidor web o en el proxy el tamaño de la petición y el número de campos, partes y cabeceras.
- 04
post_max_size=8Msi la web no admite subidas de ficheros;32Msi las admite. - 05 Si no puedes actualizar, busca indicios de compromiso y puertas traseras. Si tampoco puedes mitigar, el NCSC recomienda plantearse desconectar el sistema.
Siete pasos, en este orden
Aplicamos el mismo procedimiento en cada servidor: primero saber qué versión hay en cada sitio, después corregir y al final comprobar que nadie entró antes del parche.
Inventario de versiones
Listamos cada servidor, contenedor y hosting donde corre PHP, con la versión de la CLI y la de FPM, el modo (FPM, mod_php, CGI) y quién lo mantiene. La web olvidada en un servidor viejo es la que se queda sin parchear.
Mitigación inmediata
Donde la actualización no puede hacerse en el momento, desactivamos session.upload_progress en php.ini o en el pool, limitamos tamaño y partes de las peticiones y reiniciamos los workers.
Actualización
Subimos a la versión corregida de tu rama o al paquete parcheado de tu distribución. Si sigues en 8.1 o anterior, te explicamos las dos salidas: compilar con los backports o migrar a una rama con soporte.
Verificación
Comprobamos la versión que atiende de verdad las peticiones, no solo la de la línea de comandos, y que la web, los formularios y las subidas siguen funcionando.
Revisión de indicios de compromiso
Revisamos logs de acceso y de error, ficheros modificados recientemente en el directorio de la web y usuarios administradores nuevos en el CMS.
Rotación de secretos, si procede
Si hay señales de acceso, o el servidor estuvo expuesto a la fuga de memoria, cambiamos contraseñas de base de datos, claves de API, tokens y certificados.
Vigilancia de nuevos avisos
Dejamos anotado qué versión tiene cada servidor y qué avisos seguir (PHP, tu distribución, tu CMS), para que la siguiente actualización empiece desde ese inventario.
Lo que suele quedarse a medias
¿No sabes qué versión de PHP tiene tu web?
Consultoría gratuita →Preguntas frecuentes sobre php2shell
¿Qué es php2shell?
¿Mi WordPress está afectado aunque tenga los plugins al día?
¿Basta con desactivar session.upload_progress?
Sigo en PHP 7.4 u 8.0, ¿qué hago?
¿Y si estoy en un hosting compartido?
Cuéntanos dónde corre tu PHP
Empezamos por el inventario: qué versión tiene cada servidor, qué hay que hacer hoy y qué puede esperar a una ventana de mantenimiento.
Cuéntanos tu reto. Te proponemos solución.
Sin compromiso. En menos de 24 h recibes una propuesta con alcance, plazos y presupuesto. Sin letra pequeña.