El 21 de octubre de 2026 a las 14:00 UTC el equipo de PHP publicó los parches de dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Empezamos alrededor de una hora después. Hacia las 17:00 UTC todos los servidores que mantenemos estaban protegidos: 88 proyectos con nuestro soporte. Aquí contamos cómo lo hicimos y qué nos frenó, porque los mismos obstáculos están en muchos servidores que nadie ha parcheado todavía.
Si solo quieres saber si tu web está afectada y qué pedirle a tu hosting, lee nuestro primer artículo sobre PHP2Shell.
La primera hora: cortar la vía de ataque en todas partes
Instalar un PHP corregido en decenas de servidores lleva tiempo. Desactivar el mecanismo vulnerable lleva minutos. Así que eso fue lo primero, en cada servidor, antes de compilar nada.
El aviso de seguridad de PHP menciona session.upload_progress.enabled como una de las vías de CVE-2026-109619. Lo desactivamos en la configuración principal de PHP de cada versión de PHP en cada servidor y reiniciamos los workers de PHP. El aviso advierte que .user.ini e ini_set() no sirven, así que cambiamos los archivos a nivel de servidor. En PHP 8.5 también desactivamos fatal_error_backtraces, como sugiere el aviso.
Con esto solo se cerraba la vía confirmada de CVE-2026-109619 a través de las sesiones. Para CVE-2026-109618 hacía falta la actualización en sí.
Tres tipos de servidores, tres formas de parchear
Nuestros 88 proyectos funcionan sobre configuraciones distintas, y cada una necesitó su propio camino.
Servidores con PHP de los paquetes de la distribución. Aquí el parche llega de los mantenedores de los paquetes. Ubuntu publicó paquetes corregidos el mismo día. Un detalle para quien revise un servidor así: después de la actualización, php -v puede seguir mostrando el número antiguo, por ejemplo 8.3.6, porque Ubuntu parchea el paquete y mantiene la versión. Comprueba la versión del paquete.
Servidores gestionados con un panel de hosting. Varios servidores usan aaPanel, que compila su propio PHP. El día de la publicación el panel no tenía PHP actualizado. Esperar al panel suponía dejar estos servidores abiertos durante un tiempo indefinido, así que compilamos PHP nosotros.
Contenedores Docker. Algunos proyectos ejecutan PHP dentro de contenedores construidos a partir de imágenes existentes. Reconstruir y volver a desplegar una aplicación entera en mitad de un incidente añade riesgo. En lugar de eso parcheamos el PHP dentro de los contenedores en marcha y dejamos programadas reconstrucciones limpias de las imágenes para más adelante.
Compilar PHP nosotros sin romper el panel
El PHP de un panel no se compila igual que uno estándar. Si compilas PHP con las opciones por defecto y lo sustituyes sin más, desaparecen extensiones y el panel deja de reconocer su propio PHP.
Escribimos un script de compilación y lo ejecutamos por cada versión de PHP en cada servidor con panel:
- lee las opciones exactas de configure del PHP ya instalado, para que la nueva compilación tenga las mismas extensiones y rutas;
- compila la versión corregida desde el código fuente oficial;
- comprueba con qué bibliotecas OpenSSL y curl está enlazado el nuevo binario. El panel enlaza algunas versiones de PHP con sus propias copias, más antiguas, de estas bibliotecas, y el script se asegura de que la nueva compilación use las mismas;
- hace copia de los binarios antiguos, instala los nuevos y reinicia PHP;
- si PHP no vuelve a arrancar, restaura por sí solo los binarios antiguos.
Con el script podíamos parchear una versión de PHP en un servidor, revisar las webs y repetir en el siguiente sin trabajo manual cada vez.
PHP 7.4, 8.0 y 8.1: sin versión oficial
El equipo de PHP ya no publica versiones de estas ramas. Para PHP2Shell solo publicó los cambios en el código fuente para 7.4, 8.0 y 8.1. Algunos de nuestros proyectos todavía funcionan con estas versiones.
En esos casos aplicamos los parches del equipo de PHP sobre la última versión de cada rama y la compilamos con el mismo script. Los cambios publicados también tocan archivos de versión y changelogs, que no se aplican limpiamente sobre una versión publicada, así que aplicamos solo los cambios de código.
Un servidor tenía PHP 7.4 de los paquetes de Ubuntu 20.04. Para esa versión de Ubuntu el parche solo llega a través del mantenimiento de seguridad ampliado de Ubuntu (ESM), y ese servidor no lo usa. Compilamos PHP 7.4 con los mismos flags de compilación que usa Ubuntu y sustituimos solo el binario de PHP-FPM, dejando el original al lado. Una futura actualización del paquete sobrescribiría nuestra compilación, y lo dejamos anotado en la documentación del proyecto.
Contenedores: parcheados ahora, reconstruidos después
Para cada contenedor compilamos el PHP corregido en una copia limpia de la imagen oficial para el mismo sistema operativo. Después copiamos solo los binarios de PHP y las extensiones que necesitaba al contenedor en marcha, con una copia de los originales dentro.
Una imagen basada en Alpine necesitó los mismos parches adicionales sobre el código fuente que aplica la imagen Docker oficial de PHP. Sin ellos, la compilación fallaba con un compilador más reciente.
La pega de este método: el parche dura solo hasta que alguien vuelva a crear el contenedor desde la imagen antigua. Si tu equipo parcheó contenedores así, mete una reconstrucción de la imagen en el plan, o la vulnerabilidad vuelve con el siguiente despliegue.
Después del parche: los logs
Cuando todos los servidores tenían un PHP corregido, revisamos los logs del servidor web y de PHP en todos ellos en busca de peticiones que encajaran con la forma de explotar estas vulnerabilidades. No encontramos señales de explotación.
Lo que le diríamos al dueño de una web después de esa tarde
- La velocidad de tu hosting es tu velocidad. Si tu PHP viene de un panel o de un proveedor que espera al panel, tu web sigue abierta hasta que actúen. Pregúntales hoy qué versión tienes.
- El PHP antiguo sigue saliendo caro. PHP 8.1 y anteriores esta vez solo recibieron parches en código fuente. La próxima vez puede que no haya ninguno. El soporte de PHP 8.2 termina el 31 de diciembre de 2026.
- Los contenedores y las compilaciones propias necesitan un responsable. Nadie los actualiza automáticamente. Alguien tiene que saber que existen y cómo reconstruirlos.
Nuestra monitorización automática funciona las 24 horas, y nuestros ingenieros responden cuando detecta un incidente.
Si necesitas lo mismo para tus servidores
Revisamos tu versión de PHP y la actualizamos en un día laborable. Escríbenos.
Para un mantenimiento continuo, mira soporte de servidores, soporte web y DevOps. Si tu app móvil se comunica con un backend en PHP, ese backend necesita la misma actualización; lo cubrimos dentro del soporte de apps móviles. Para saber si queda algo más abierto, encarga un test de penetración.
Fuentes
- Anuncio y medidas de mitigación del equipo de PHP: https://www.php.net/archive/2026.php
- Avisos de seguridad: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w y https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available