PHP publicará el 21 de octubre un parche de emergencia por dos RCE críticas (CVSS 9.2). Si tu sitio corre en PHP, prepara el servidor hoy.
El equipo de seguridad de PHP adelantó una versión urgente para el 21 de octubre de 2026 a las 14:00 UTC (9:00 a. m. hora de Colombia). Se trata de los CVE-2026-109618 y CVE-2026-109619, reportados por watchTowr y calificados 9.2 sobre 25 en CVSS v4.0. Las versiones afectadas no están confirmadas del todo; la alerta del equipo de PHP y de CERT-EU es tratar el parche como si afectara a cualquier sitio en PHP, incluido PHP 5 (según BleepingComputer).
Qué se sabe hoy del fallo crítico de PHP
Lo verificado hasta el momento:
- La fecha de lanzamiento se anunció el 20 de octubre en el archivo de anuncios de php.net, confirmada en la discusión del PHP Foundation y en oss-security.
- El embargo se rompió antes de tiempo en Hacker News; de ahí que la fecha se adelantara.
- watchTowr confirmó a BleepingComputer que son dos RCE reales. Sin detalles públicos de explotación todavía, el margen entre el anuncio y los primeros exploits puede ser mínimo.
- CERT-EU pidió a las organizaciones prepararse para parchar de inmediato, sin periodo de gracia real.
Implicación concreta: un atacante con acceso a enviar datos procesados por PHP (una aplicación web, un endpoint de API, un gestor de archivos) podría ejecutar código en el servidor. Si el sitio corre en un plan compartido, el impacto no se limita a tu dominio: el hosting ve el riesgo de su infraestructura completa.
Cómo prepararte hoy (checklist antes de las 14:00 UTC)
Paso 1: identificar en qué versión exacta corre cada aplicación. En el servidor, con SSH:
php -v
php -m # extensiones cargadas
php --ini # qué php.ini usa cada SAPI
Si usas Drupal, también:
composer show | grep php
drush status | grep -i 'drupal\|php'
Paso 2: anotar la ruta real del binario que usa el web server, no solo la del CLI. Nginx con PHP-FPM y Apache con mod_php pueden usar versiones distintas:
php-fpm -v
ps aux | grep -E 'php-fpm|apache|httpd'
Paso 3: confirmar el plan de actualización de tu proveedor. Si el sitio está en hosting compartido colombiano o regional, revisa el panel (cPanel, Plesk) y el estado del proveedor: muchos ofrecen un selector de versión de PHP que puedes cambiar tú mismo; otros actualizan de forma centralizada y solo avisan.
Paso 4: agendar ventana de mantenimiento. Aunque el parche llega a las 9:00 a. m. hora de Colombia, conviene parchar cuando haya poco tráfico: madrugada o domingo. Un sitio comercial no se parcha a media jornada de ventas sin plan B.
Paso 5: preparar rollback antes de tocar nada. Backup de código, base de datos y archivos subidos; y anotar la versión de PHP anterior para poder volver:
# ejemplo en cPanel/WHM o en servidor con múltiples builds
/usr/bin/php82 -v # versión actual
Si el hosting permite cambiar de versión desde el panel, el rollback es ese mismo selector, en reversa.
Cómo aplicar el parche sin caídas en producción
El orden que funciona en la práctica:
- Staging primero. Clona el sitio (o apunta el dominio de pruebas) a la versión de PHP nueva y recorre las rutas críticas: login, checkout, formularios, subida de archivos, cron.
- Revisa los errores de PHP, no solo la pantalla blanca. Activa logs temporales:
; php.ini (temporal, solo staging)
error_reporting = E_ALL
display_errors = On
log_errors = On
- Mira deprecations y warnings en Drupal o WordPress. Un RCE no se corrige en la app, pero el salto de versión sí puede romper extensiones antiguas:
# Drupal: revisar módulos no mantenidos
composer why-not drupal/core
- Cambia la versión en producción solo cuando el pase de staging salga limpio.
- Deja display_errors en Off en producción (nunca expongas rutas internas al visitante) y observa los logs 10 minutos después del cambio:
tail -f /var/log/php-fpm/error.log
tail -f /var/log/nginx/error.log
Si tu hosting no actualiza PHP a tiempo
Tres opciones, de menor a mayor costo:
- Selector de versión del panel. Si el proveedor ya ofrecía PHP 8.3 o 8.4, ahí es donde está el parche más rápido una vez publicado.
- PHP por proyecto. Algunos hosts permiten binarios distintos por dominio; deja el sitio principal en 8.4 y el legado en su versión hasta migrarlo.
- Migrar el sitio. Si solo quedan PHP 7.x sin soporte, el parche de hoy no te salva: esas líneas llevan años sin parches de seguridad. Ahí la conversación ya no es "¿a qué versión?" sino "¿dónde lo reubico?". En Saibher hemos migrado sitios de PHP 7 y de Drupal 7 a Drupal 11 con Composer y PHP 8.4 precisamente para salir de ese ciclo de parches de emergencia (puedes revisar nuestras opciones de servicios).
Qué revisar después de actualizar
- El phpinfo del sitio confirma la versión nueva (ocúltalo después):
php -i | head -20. - Los cron jobs y tareas programadas (Drupal cron, WP-Cron, colas de workers) siguen corriendo.
- Los plugins o módulos con dependencias nativas (imagick, intl, gd) cargan sin errores.
- Si hay apps PHP a medida dentro del mismo servidor (APIs, scripts legacy), repite la prueba en cada una.
- Vuelve a revisar en 48 horas: los exploits suelen llegar después del día cero.
Si tras el parche algo se rompió y no puedes revertir por tiempo, recuerda que el hosting comparte el riesgo: reportar al proveedor y trabajar con ellos suele ser más rápido que diagnosticar solo.
Preguntas frecuentes
¿Parchar el servidor es suficiente si mi sitio está en hosting compartido?
No depende solo de ti. En hosting compartido la versión de PHP la define el proveedor; tu trabajo es confirmar cuál corre tu sitio y exigir o activar el upgrade. Si el proveedor no ofrece una versión parchada, evalúa migrar el sitio.
¿Debo actualizar aunque no use PHP directamente?
Si el CMS corre en PHP, sí. Drupal, WordPress, Joomla, Magento y la mayoría de apps PHP a medida dependen del binario del servidor; el exploit no distingue entre "tu código" y el core del CMS.
¿Qué versión de PHP debería usar después del parche?
La última estable con soporte activo (hoy PHP 8.4). Las ramas 8.1, 8.2 y 8.3 siguen recibiendo parches de seguridad hasta sus fechas de fin de vida, pero el salto a 8.4 evita repetir esta carrera cada trimestre. Verifica compatibilidad de extensiones y del CMS antes.
¿Cuánto tarda una ventana de mantenimiento típica?
Para un sitio Drupal con Composer, cambiar la versión de PHP en el panel y validar el pase de staging: minutos. Para una app a medida con dependencias nativas o PHP 7 heredado, puede tomar horas porque incluye pruebas de regresión; si el presupuesto de tiempo no da hoy, prioriza aislar lo expuesto (firewall, WAF) mientras migras.
¿Cómo me entero de la próxima vulnerabilidad crítica de PHP?
El archivo de anuncios de php.net, la lista oss-security de Openwall y los avisos de drupal.org son las tres fuentes que suelen llegar antes que los medios. Suscríbete a ellas y revisa el estado de soporte de tu versión cada trimestre, no solo cuando hay emergencia.
El siguiente paso concreto: hoy, antes de las 9:00 a. m. hora de Colombia, corre php -v en cada servidor, anota las versiones y confirma con tu hosting cómo se va a aplicar el parche.
