Parchear PHP: guía para corregir vulnerabilidades críticas

El 21 de octubre de 2026, PHP publicó parches de emergencia para dos vulnerabilidades críticas que permiten ejecutar código en el servidor sin necesidad de autenticación. Decidí parchear PHP en mis dos VPS esa misma tarde, antes de que cayera la noche, porque los datos que llegaban eran alarmantes. Esta es la guía de lo que hice, paso a paso, por si te sirve.

Por qué tienes que parchear PHP ahora mismo

Las dos vulnerabilidades se llaman CVE-2026-109618 y CVE-2026-109619, apodadas colectivamente «PHP2Shell». Ambas tienen una puntuación CVSS v4.0 de 9,2 sobre 10, que es la máxima categoría crítica. Lo que las hace especialmente peligrosas es dónde ocurren: en el propio motor de PHP, antes de que WordPress, un plugin de seguridad o cualquier sistema de login tenga siquiera la oportunidad de intervenir. No hay plugin que te salve. No hay contraseña suficientemente fuerte. El problema está en la capa más baja.

Parchear PHP es, según Datadog, la única solución real. Las mitigaciones que circulan por foros, como desactivar session.upload_progress en el archivo php.ini, no protegen completamente. Un cortafuegos web puede dificultar los ataques, pero no los bloquea del todo. Además, hay un detalle que me parece relevante si usas hosting gestionado: proveedores como CloudLinux o cPanel pueden haber aplicado el parche sin cambiar el número de versión visible. Si tu panel sigue mostrando PHP 8.3.35, puede que ya esté parcheado. Pregunta a tu proveedor. Hosting y alojamiento web

Cómo funcionan los fallos, explicado sin tecnicismos

CVE-2026-109618 aprovecha situaciones de agotamiento de memoria. Cuando PHP se queda sin memoria durante una petición, puede dejar datos a medias que el siguiente visitante reutiliza sin saberlo. El atacante lo explota para lanzar comandos. CVE-2026-109619 funciona de forma parecida pero mediante estado global obsoleto entre peticiones: restos del procesamiento anterior que no se limpiaron correctamente. En el segundo caso, la subida de archivos con barra de progreso, activada por defecto mediante session.upload_progress, es una vía de ataque especialmente documentada.

El alcance real del problema: cifras que asustan

PHP sustenta entre el 70 y el 80 por ciento de los sitios web cuyo lenguaje de servidor es conocido. Eso incluye WordPress, Drupal, Joomla y Laravel. Palo Alto Networks identificó más de 22,6 millones de instancias de PHP expuestas a Internet y potencialmente vulnerables en el momento en que se publicaron los parches. No es un problema de nicho. Afecta a instalaciones que usan Apache con mod_php, PHP-FPM, php-cgi, FrankenPHP y LiteSpeed. CISA considera que mod_php es el escenario de mayor riesgo.

Parchear PHP no es opcional: con 22,6 millones de servidores expuestos, esperar un día puede ser demasiado.

El 26 de octubre de 2026, CISA añadió ambas vulnerabilidades a su catálogo de vulnerabilidades explotadas conocidas. Ordenó a las agencias federales civiles proteger sus sistemas antes del 29 de octubre. Pero lo que más me impresionó al leer los informes fue otro dato: Amazon Web Services detectó los primeros intentos de explotación el 17 de octubre, cuatro días antes de que existiera ningún parche. El investigador Adel Karimi registró 35 ejecuciones de shell con éxito en honeypots con PHP 8.4.26. Los ataques eran reales antes de que supiéramos que el fallo existía. Vulnerabilidades críticas de PHP: analisis de PHP2Shell

Señales de que ya podrían haberte atacado

Antes de tocar nada, conviene revisar si el servidor ya ha sido comprometido. Las señales más claras son: PHP o el servidor web lanzando shells o descargando herramientas externas, que es la prueba más directa de explotación. También hay que fijarse en errores de memoria agotada al inicio de una petición, en procesos de PHP que se caen sin motivo aparente, o en peticiones POST muy grandes que incluyan campos como PHPSESSID o PHP_SESSION_UPLOAD_PROGRESS en los logs de acceso.

El Threat Intelligence Lab de la Universidad de Delft rastreó más de 50.000 peticiones de explotación procedentes de más de 600 direcciones IP distribuidas en 70 países. De esas, 171 enviaron código de explotación real o droppers de malware, no solo sondeos. Dicho de otro modo: no todos los que llaman a la puerta están mirando; algunos ya traen la palanca. Si encuentras cualquiera de esas señales en tus logs, el orden de prioridades cambia: primero aislar, luego parchear.

Cómo parchear PHP paso a paso en un VPS Ubuntu

Antes de ejecutar ningún comando, lo primero es saber con exactitud qué versión tiene cada sitio. No la que crees que tiene: la real. En mis dos servidores con Ubuntu 22.04 y panel HestiaCP usé php -v para la versión activa en la línea de comandos. Además grep -rHoE «php[0-9].[0-9]-fpm» /home//conf/web//apache2.conf para localizar la versión que cada sitio web usaba en Apache. En uno de los servidores apareció una sorpresa: tres sitios corrían PHP 8.2 y 8.3 sin parchear. El resto del servidor ya iba en 8.4.

Después de revisar versiones, toca hacer la copia de seguridad. Sin excepciones. Usé mysqldump –all-databases –single-transaction para volcar todas las bases de datos, tar czf para comprimir los directorios de configuración. Dpkg -l para guardar la lista de paquetes instalados. Todo ello con sha256sum para verificar la integridad de cada archivo generado. Si la tarea de copia es larga, conviene lanzarla dentro de screen o con nohup. Si la conexión SSH se cae a mitad, el volcado queda a medias y es inútil. Descarga la copia fuera del servidor antes de continuar.

Actualizar PHP sin romper los sitios web

Con la copia fuera del servidor, el proceso de actualización en sí suele ser rápido. En Ubuntu con los repositorios de Ondřej Surý, que es la fuente habitual para versiones modernas de PHP, basta con apt update seguido de apt upgrade php8.4 php8.4-fpm, repitiendo para cada versión instalada. Luego hay que reiniciar el servicio correspondiente: systemctl restart php8.4-fpm, o apache2 si se usa mod_php. Después de reiniciar, comprueba que los sitios responden, que los logs no muestran errores nuevos y que php -v devuelve la versión parcheada. Las versiones parcheadas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

Parchear PHP también significa abandonar las versiones antiguas

PHP 8.1 y versiones anteriores no reciben parche oficial para PHP2Shell. Han llegado al fin de su vida útil. CISA es bastante directa al respecto: sin soporte, la recomendación es desconectar esos sistemas o migrarlos a una versión mantenida. Sé que eso no siempre es fácil. Hay aplicaciones viejas, clientes que no quieren tocar lo que funciona, entornos de staging olvidados. Pero un servidor con PHP 7.4 expuesto a Internet en este momento es, básicamente, un servidor sin defensa frente a PHP2Shell. No hay parche que instalar porque no existe.

También hay que tener en cuenta que el 24 de octubre de 2026, tres días después de los parches de emergencia, el equipo de seguridad de PHP informó de un tercer fallo RCE adicional: CVE-2026-115560, todavía sin parche en ese momento, explotable en sistemas con una combinación inusual de configuración y código de aplicación. Dicho esto, afecta a un perfil de instalación más específico. Pero vale la pena seguir los canales oficiales de PHP en los próximos días. Este tipo de vulnerabilidades suele venir en oleadas.

Qué hacer si gestionas varios servidores o sitios de clientes

Si tienes bajo tu responsabilidad varios servidores, la tentación es actualizar todos a la vez. Yo lo haría de forma escalonada: primero el que tiene más tráfico o más exposición a Internet, comprueba que todo funciona durante unas horas. Luego continúa con los demás. Por otro lado, si gestionas sitios de clientes, avísales aunque no lo pidan. No porque sea obligatorio, sino porque saberlo les genera confianza. Además, asegúrate de documentar qué versión tenía cada servidor antes y después: es información útil para auditorías y para ti mismo si algo falla.

Parchear PHP es urgente, pero hay que hacerlo bien

La urgencia es real. Con más de 22,6 millones de instancias expuestas y ataques documentados antes incluso de que existieran los parches, no hay margen para dejarlo para la semana que viene. Sin embargo, parchear PHP con prisas y sin copia de seguridad es un riesgo distinto pero igual de real. Un servidor roto por una actualización mal aplicada puede costar más tiempo que el ataque mismo. El orden importa: revisar versiones, hacer copia, actualizar, reiniciar, verificar y, finalmente, desactivar o migrar las versiones sin soporte.

¿Tienes PHP 8.1 o anterior en algún rincón de tu infraestructura? Es el momento de mirarlo. No como tarea pendiente, sino hoy. A veces los servidores más olvidados son los más expuestos precisamente porque nadie los vigila. Y en este caso, ser invisible no es ninguna protección.

Fuentes: SecureLayer7 · watchTowr