ES
ENPHP ya sacó el parche, y lo sacó antes de lo previsto. Si tienes PHP en algún servidor, actualiza a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y reinicia los servicios. No existe una mitigación completa: el propio PHP dice que actualizar es la única opción segura.
Actualizado el 21 de octubre de 2026, 8:50 a.m. hora Colombia.
Para quien no siguió la historia: el 20 de octubre se filtraron dos vulnerabilidades críticas de ejecución remota de código en el núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, a las que los investigadores empezaron a llamar php2shell. PHP las tenía programadas para corregir el 21 a las 14:00 UTC, pero liberó las versiones antes de esa hora.
Qué hacer ahora
Tres cosas, en este orden. Primero, actualiza a una de las versiones corregidas, o al paquete de tu distribución o proveedor que ya la incluya. Segundo, reinicia PHP-FPM, Apache, FrankenPHP y cualquier proceso de larga duración, porque instalar el paquete no basta: lo que ya estaba corriendo sigue con el código viejo. Tercero, revisa tus logs desde las 15:00 UTC del 20 de octubre (10:00 a.m. en Colombia), por si alguien entró antes del parche.
Qué corrige
El aviso de PHP habla de dos fallas distintas.
La CVE-2026-109618 nace de cuando a PHP se le acaba la memoria. El manejo de ese error puede cortar a PHP con los datos de la petición a medio inicializar, y la limpieza posterior trata esos datos rotos como si estuvieran bien.
La CVE-2026-109619 es un estado interno que sobrevive después de que se libera su memoria. La siguiente petición que atienda el mismo worker puede usar ese estado viejo antes de que se reinicie.
Las dos permiten ejecutar código sin autenticación, y las dos tienen severidad 9.2 en CVSS v4.0. Con mod_php, PHP dice tener un exploit demostrado en el que una petición cualquiera dispara el ataque antes de que corra una sola línea de tu aplicación. Por eso actualizar WordPress, Laravel o un plugin no te sirve de nada aquí: el problema está en el intérprete, no en tu código.
Afecta a todo PHP que atienda peticiones web: PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera que el riesgo es mayor con mod_php.
Cómo actualizar
Ubuntu y Debian. PHP dice que las distribuciones recibieron los parches por adelantado, así que puede que tu paquete ya esté listo:
bashsudo apt update
sudo apt upgrade
sudo systemctl restart php8.3-fpm
Cambia php8.3-fpm por tu versión, y reinicia también apache2 si usas mod_php. Ojo con el número de versión: un paquete puede traer el arreglo sin cambiar el número de PHP. Para confirmarlo, mira el changelog:
bashzcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | head -20
Tiene que mencionar CVE-2026-109618 y CVE-2026-109619. Después comprueba qué se está ejecutando de verdad:
bashphp-fpm8.3 -v
systemctl status php8.3-fpm --no-pager | head -5
Si tienes más de una rama de PHP instalada (ls /etc/php te las muestra), actualiza todas.
Docker y Dokploy. La versión de PHP vive dentro de la imagen, así que reiniciar el contenedor no cambia nada. Reconstruye con la imagen base nueva y vuelve a desplegar:
bashdocker build --pull --no-cache -t mi-app:nueva .
docker run --rm mi-app:nueva php -v
Tiene que salir 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Si todavía sale la versión anterior, la imagen base aún no se actualizó y toca esperar un poco.
Hosting compartido. Pídele a tu proveedor que te confirme que ya está desplegado el arreglo en el runtime de tus dominios. "Programado" no es lo mismo que "desplegado".
Windows. PHP publica el código fuente y los binarios en su página de descargas.
PHP 8.1 o anterior. El proyecto ya no las actualiza. Algunas distribuciones y proveedores de soporte extendido ofrecen correcciones propias, así que pregúntale al tuyo, o migra a una versión con soporte. Si compilas desde el código fuente, el equipo de seguridad publicó parches mínimos para PHP 7.4, 8.0 y 8.1 en su repositorio.
RHEL y el repositorio Remi. PHP avisa que rpms.remirepo.net, que mantienen voluntarios, no va a tener actualizaciones hoy, y recomienda usar los paquetes de la distribución o compilar desde el código fuente.
Si de verdad no puedes actualizar hoy
PHP publicó unas medidas que reducen la exposición a vías de ataque concretas, pero avisa que no hacen segura una instalación. Úsalas solo como parche temporal.
Para la falla de memoria (CVE-2026-109618): fija memory_limit=-1 de una forma que las aplicaciones no puedan cambiar, por ejemplo con php_admin_value en el pool de FPM, y revisa que nada vuelva a poner un límite. Esto quita el fallo que un atacante puede provocar con el límite de memoria de PHP, pero un fallo de asignación más abajo todavía puede llegar a la ruta vulnerable. Pon también un post_max_size bajo: 8M si tu aplicación no recibe archivos, 32M si los recibe. Y si usas contenedores, un límite de memoria del contenedor ayuda como frontera de disponibilidad, pero no uses RLIMIT_AS ni RLIMIT_DATA, porque pueden provocar justo el fallo que quieres evitar.
Para la falla del estado obsoleto (CVE-2026-109619): pon session.upload_progress.enabled=0 y reinicia todos los workers. Tiene que ir en php.ini, en el pool de FPM o en la configuración del servidor, no con ini_set() ni en .user.ini. Eso bloquea las rutas de sesión confirmadas, pero no otras variantes. En PHP 8.5 añade fatal_error_backtraces=0, que cierra la ruta confirmada de los backtraces de errores fatales.
Después de actualizar
Revisa los logs desde las 15:00 UTC del 20 de octubre: caídas de PHP-FPM, peticiones raras y archivos nuevos o modificados en los directorios web. Instalar el parche no borra una intrusión que ya haya pasado.
La señal de explotación más probable, según Huntress y el investigador Florian Roth, son procesos hijo sospechosos lanzados por PHP: un php-fpm, php-cgi, apache2 o httpd que de pronto ejecuta una shell, python, perl, curl, wget, nc o comandos como whoami e id. Si tienes un EDR, ponle una alerta a ese patrón. Si no, Huntress menciona process-watcher, una herramienta gratuita de Roth para vigilar eso en Linux.
Si encuentras algo, aísla el servidor, guarda los logs y busca webshells, cron jobs y cuentas nuevas. Para limitar el daño de una intrusión futura, guarda menos datos en el servidor, dale menos permisos al usuario de PHP y a las cuentas de servicio, y manda los logs a otro lugar (consejos de GMO Flatt Security).
Lo que se dijo antes del parche, y cómo salió
Durante la mañana del 21 circularon muchas cosas, y no todas resultaron ciertas. Las versiones que se rumoreaban (8.5.12, 8.4.27, 8.3.36 y 8.2.35) eran las correctas. La idea de que todo venía del progreso de subida de sesiones era solo en parte cierta: PHP confirma que es una de las rutas de la segunda falla, pero hay dos fallas, no una, y desactivar esa función no basta. La cifra de 10.0 que circulaba era de reportes filtrados, y la oficial es 9.2. Y los reportes de ataques tempranos, como el que se atribuyó al CTO de Cloudflare, nunca los confirmó PHP.
Preguntas rápidas
¿Es verdad que el 80% de internet está comprometido? No hay nada que lo respalde. PHP está en cerca del 71% de los sitios cuyo lenguaje de servidor se conoce (W3Techs, julio de 2026), y de ahí sale el número. Pero estar expuesto no es lo mismo que estar comprometido, y PHP no ha confirmado ataques masivos.
Instalé el paquete. ¿Ya estoy protegido? No hasta que reinicies. PHP-FPM, Apache y los procesos largos, como los workers de colas u Octane, siguen con la versión vieja hasta que los reinicias.
Uso PHP 7 u 8.1. ¿Qué hago? El proyecto no las actualizará. Pregunta a tu distribución o proveedor de soporte si hay una corrección propia, o migra a una rama con soporte (8.2 a 8.5). Mientras tanto, saca ese servidor de internet o ponlo detrás de una VPN o un WAF.
¿Apago mis webs con PHP? Lo que hay que hacer es actualizar, y en la mayoría de los servidores toma minutos. Para sitios que hoy no necesitas, como entornos de pruebas, apagarlos o limitarlos por IP hasta parchear sí tiene sentido.
Fuentes
- Aviso de PHP: https://www.php.net/archive/2026.php#2026-10-21-5
- Descargas de PHP: https://www.php.net/downloads.php
- watchTowr: https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
- Huntress: https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
- Sansec: https://sansec.io/research/php2shell
- CERT-EU: https://cert.europa.eu/publications/security-advisories/2026-018/
- GMO Flatt Security: https://blog.flatt.tech/entry/php2shell
- W3Techs (uso de PHP): https://w3techs.com/technologies/comparison/pl-php
Velozen Hosting