Alerta de seguridad — 21 de octubre de 2026. El proyecto PHP ha publicado actualizaciones extraordinarias para corregir dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, capaces de permitir ejecución remota de código sin autenticación bajo determinadas condiciones. El riesgo no se limita a un CMS concreto: afecta al intérprete PHP que ejecuta las aplicaciones. Esta guía explica cómo verificar las versiones, por qué los paquetes pueden tardar en llegar y cómo planificar una actualización segura sin confundir mitigaciones parciales con parches definitivos.

Qué ha confirmado el proyecto PHP

En su aviso oficial del 21 de octubre, PHP identifica como versiones corregidas 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Avisa expresamente de que deben revisarse las instalaciones que sirven peticiones web mediante PHP-FPM, Apache mod_php, php-cgi, FrankenPHP o LiteSpeed. El equipo considera particularmente elevado el riesgo de mod_php, pero eso no significa que PHP-FPM sea inmune.

También hay que diferenciar «explotación posible» de «compromiso confirmado»: una versión vulnerable obliga a actuar, pero por sí sola no demuestra que una web haya sufrido una intrusión.

Entender las dos vulnerabilidades

CVE-2026-109618: corrupción de memoria durante errores de memoria insuficiente

PHP puede interrumpir una petición por agotamiento de memoria mientras algunos datos internos solo están parcialmente inicializados. Durante su limpieza, el intérprete puede tratar memoria inválida como si fuera válida. El aviso técnico analiza condiciones relacionadas con esa secuencia y el procesamiento de peticiones. La corrección debe aplicarse al intérprete, no a una plantilla o un plugin de WordPress.

CVE-2026-109619: estado global obsoleto

Ciertos datos asociados a una petición pueden permanecer referenciados después de liberarse su memoria. Otra petición gestionada por el mismo proceso puede intentar reutilizar ese estado antes de inicializarlo correctamente. El advisory oficial describe las condiciones y diferencias entre los modos de ejecución. No debe suponerse que todos los servidores PHP-FPM y mod_php comparten exactamente el mismo vector de ataque.

Tabla de versiones corregidas

RamaVersión corregidaObservación
PHP 8.58.5.12Actualizar dentro de la rama
PHP 8.48.4.27Actualizar dentro de la rama
PHP 8.38.3.36Actualizar dentro de la rama
PHP 8.28.2.35Fin del soporte ordinario previsto para el 31 de diciembre de 2026
PHP 8.1 o anterioresSin actualización ordinaria del proyecto PHPMigrar o verificar parches mantenidos por el proveedor

Algunas distribuciones mantienen versiones anteriores con parches retroportados. Por eso es necesario consultar los avisos de seguridad de la distribución y el historial del paquete, no decidir únicamente por el número que muestra php -v.

Por qué apt dice «última versión» cuando PHP ya ha publicado el parche

Hay una cadena de distribución: primero se libera el código corregido; después las distribuciones y repositorios terceros compilan, prueban y publican paquetes para cada entorno. Un resultado como «el paquete instalado ya es el más reciente» significa que es el más reciente dentro de los repositorios configurados. No demuestra por sí solo que incorpore las correcciones del 21 de octubre.

Una comprobación orientativa, sin modificar los paquetes instalados, es:

sudo apt update
apt-cache policy php8.3-fpm
apt list --upgradable 2>/dev/null | grep -E '^php'

Adapta el ejemplo a la rama que utilices. Comprueba tanto la versión instalada como la candidata y revisa si el proveedor ofrece un parche retroportado. No conviene intentar resolver el problema saltando precipitadamente a otra rama que también esté sin parchear. Tampoco hay que usar patrones amplios de paquetes sin revisar previamente qué acciones propondrá el gestor.

Procedimiento recomendado para administradores

  1. Inventario: localiza versiones, servidores, procesos PHP-FPM, pools, contenedores y aplicaciones expuestas.
  2. Copia recuperable: realiza instantáneas o copias verificadas y conserva acceso administrativo alternativo antes de actualizar.
  3. Paquetes oficiales o mantenidos: identifica una actualización corregida o un parche retroportado confirmado.
  4. Prueba controlada: en entornos con varios nodos, actualiza uno y comprueba las aplicaciones antes de continuar. No mantengas indefinidamente nodos expuestos esperando una ventana perfecta.
  5. Reinicio efectivo: reinicia los procesos que mantienen PHP cargado. Un paquete actualizado no protege a los workers que siguen ejecutando binarios antiguos.
  6. Verificación: comprueba paquetes, procesos, versiones de los pools, respuestas HTTP y registros.
  7. Revisión de seguridad: busca indicadores de compromiso y conserva las pruebas relevantes si se detectan anomalías.

Comandos de consulta para una instalación PHP-FPM, adaptando siempre la rama:

php -v
systemctl status php8.3-fpm --no-pager
ps -eo pid,lstart,args | grep '[p]hp-fpm'
dpkg-query -W 'php8.3*' 2>/dev/null

Importante: php -v comprueba el ejecutable de línea de comandos, no necesariamente el PHP que sirve una web. Verifica la asociación real entre el servidor web, el pool y el ejecutable. Evita dejar un phpinfo() público que revele detalles de configuración.

Medidas provisionales: qué reducen y qué no

El proyecto PHP afirma que ninguna mitigación es completa. Las siguientes medidas se describen en la documentación oficial y deben evaluarse cuidadosamente según el uso de cada aplicación.

Para CVE-2026-109619

Desactivar session.upload_progress.enabled mediante configuración aplicada antes del procesamiento de la petición y reiniciar todos los workers bloquea una de las rutas confirmadas, pero no cubre todas las variantes. En PHP 8.5, fatal_error_backtraces=0 bloquea otra vía concreta. También se aconseja eliminar ajustes inválidos u obsoletos que causen diagnósticos durante la inicialización. Ocultar los avisos de error no resuelve el fallo.

Para CVE-2026-109618

El aviso propone medidas temporales como memory_limit=-1, límites de post_max_size bajos y restricciones adicionales de tamaño y complejidad de peticiones en el servidor web o proxy. Sin embargo, retirar el límite de memoria de PHP puede permitir que una petición consuma gran cantidad de RAM y degrade la disponibilidad del servidor. La documentación recomienda considerar límites de memoria a nivel de contenedor o cgroup, y advierte de que otros límites del proceso no son equivalentes. Estas medidas no deben aplicarse de forma ciega a múltiples aplicaciones con necesidades distintas.

¿Es mejor pasar directamente a PHP 8.4 o 8.5?

No necesariamente durante una emergencia. Lo decisivo es instalar una compilación realmente corregida. Cambiar a PHP 8.5.11, por ejemplo, no soluciona estos dos CVE, mientras que 8.5.12 sí incorpora la corrección. Un salto de rama también puede afectar a extensiones, dependencias, plugins, temas y código antiguo.

Si una aplicación ya funciona en una rama soportada, actualizar primero a la revisión de seguridad de esa misma rama suele reducir el riesgo de incompatibilidad. Después se puede preparar la migración a una rama más moderna mediante pruebas de regresión. Las instalaciones PHP 8.1 y anteriores requieren un plan prioritario de modernización o soporte ampliado verificable.

Paneles, CMS y WordPress: capas distintas

Un panel de alojamiento puede ayudar a actualizar paquetes y a seleccionar la versión de PHP por sitio, pero no sustituye la comprobación de qué motor está ejecutando cada petición. Del mismo modo, actualizar WordPress, sus plugins o un CMS desarrollado a medida es necesario para su propia seguridad, aunque no arregla una vulnerabilidad situada en el núcleo del intérprete PHP.

En un alojamiento con varias versiones de PHP hay que revisar cada SAPI y rama instalada que ejecute cargas reales. Una web aislada en un pool antiguo puede permanecer expuesta aunque los demás sitios hayan recibido el parche.

Vigilancia de posibles intrusiones

Busca archivos inesperados, modificaciones de código no explicadas, nuevas tareas programadas, cambios en servicios, procesos anómalos, picos de tráfico saliente y errores inusuales. Una señal aislada no prueba una intrusión, pero requiere investigación. Si hay indicios sólidos de compromiso, preserva registros y evidencias antes de limpiar o reinstalar; coordina la respuesta con el responsable de seguridad.

Un WAF, límites de peticiones y el endurecimiento de las interfaces administrativas pueden reducir exposición, pero no hacen seguro un PHP vulnerable. Confirma también que las actualizaciones automáticas incluyen los repositorios utilizados y que los servicios se reinician cuando corresponde.

Preguntas frecuentes

¿El fallo afecta solo a Apache mod_php?

No. PHP recomienda actualizar todas las instalaciones que atienden peticiones web. El mayor riesgo demostrado para mod_php no equivale a inmunidad de FPM.

¿Basta con reiniciar FPM?

No. Primero debe haberse instalado realmente el binario corregido o parche retroportado. Reiniciar una versión vulnerable no la corrige.

¿Es seguro confiar en que «0 paquetes actualizados» significa que ya estamos protegidos?

No. Puede reflejar retraso del repositorio. Comprueba los avisos del proveedor y la versión candidata.

¿Las mitigaciones temporales sustituyen el parche?

No. PHP lo descarta de forma expresa.

Conclusión

La prioridad es disponer de una actualización corregida, cargarla en todos los procesos de PHP que sirven tráfico y verificar su efecto real. La segunda prioridad es documentar las dependencias que impiden reaccionar deprisa: ramas antiguas, aplicaciones sin pruebas, repositorios que tardan en publicar y falta de observabilidad. Una buena respuesta no consiste solo en ejecutar apt update, sino en saber qué se ha corregido, dónde y con qué evidencia.

Fuentes oficiales