Vulnerabilidad de seguridad en PHP CVE-2026-109618: cómo cerrarla

El 21 de octubre de 2026, el proyecto PHP cerró dos vulnerabilidades de seguridad críticas: CVE-2026-109618 y CVE-2026-109619. Ambas permiten a atacantes sin autenticación ejecutar código en el servidor web a través de la red (CVSS 9,2). La única solución completa es actualizar a PHP 8.2.35, 8.3.36, 8.4.27 u 8.5.12 y reiniciar después todos los procesos de PHP.

Aquí leerá cómo comprobar en pocos minutos si su sitio web está afectado, instalar la actualización y demostrar que ya no queda ningún proceso PHP antiguo en ejecución. Instalamos las actualizaciones en nuestros propios servidores esa misma tarde; los pasos de comprobación de abajo proceden de ese trabajo.

¿Qué debo hacer ahora?

Usted gestiona su propio servidor o un servidor virtual:

1. Comprobar la versión de PHP (sección siguiente).
2. Instalar la actualización para cada versión de PHP instalada.
3. Reiniciar PHP-FPM o Apache.
4. Demostrar que ya no queda ningún proceso PHP antiguo en ejecución.
5. Buscar rastros de un ataque si el servidor estuvo expuesto durante mucho tiempo.

Su sitio web está alojado en un proveedor de hosting (hosting compartido, hosting WordPress):

1. Consultar la versión de PHP de su sitio en el panel de hosting o en WordPress.
2. Preguntar al proveedor si la actualización se ha instalado y si PHP se ha reiniciado.
3. Si su sitio sigue funcionando con PHP 8.1 o anterior: cambiar en el panel a PHP 8.3 o superior.

¿Qué ha pasado?

El proyecto PHP publicó el 21 de octubre de 2026 a las 14:00 UTC las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12. El aviso en php.net se titula «Critical remote code execution vulnerabilities, update now». Para usted esto significa que desde esa tarde las vulnerabilidades están documentadas públicamente y que cualquier servidor sin actualizar es un objetivo conocido.

¿Qué versiones de PHP están afectadas?

Están afectadas todas las versiones anteriores a 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Son seguras exactamente estas cuatro versiones y cualquier versión posterior.

Para PHP 8.1 y anteriores, php.net remite al proveedor correspondiente. Si un proveedor ha portado la corrección a esas versiones, debe demostrarlo él mismo. El camino seguro es cambiar a PHP 8.3 o superior, ya que, según php.net, PHP 8.2 solo recibe actualizaciones de seguridad hasta el 31 de diciembre de 2026.

¿Cómo compruebo mi versión de PHP?

Lo decisivo es la versión con la que funciona su sitio web, no la de la línea de comandos. Ambas pueden ser distintas, porque a menudo hay varias versiones de PHP instaladas en paralelo.

• Panel de hosting (Plesk, cPanel): la versión de PHP suele figurar en los ajustes del dominio correspondiente.
• WordPress: «Herramientas → Salud del sitio → Información → Servidor» muestra la versión con la que el sitio funciona realmente.
• Servidor propio (Debian, Ubuntu): php-fpm8.4 -v muestra la versión del servicio FPM, dpkg -l 'php8.4*' los paquetes instalados. En Plesk, cada versión está en /opt/plesk/php/<Version>/bin/php.

Algunas distribuciones incorporan la corrección en su propio número de versión, por ejemplo con un sufijo como ~deb12u1. En ese caso, lo que cuenta es el aviso de seguridad de la distribución, no el número original de PHP por sí solo.

¿Qué gravedad tiene la vulnerabilidad para mi sitio web?

La vulnerabilidad es grave, porque un ataque no necesita ni una cuenta ni un clic de la víctima. Todos los datos de esta sección proceden de los dos avisos de seguridad y del aviso de php.net (fuentes abajo).

• Apache con mod_php: aquí el ataque está demostrado por completo. Una solicitud sin autenticación puede desencadenarlo antes de que se ejecute siquiera el código de su aplicación. Por eso un plugin de seguridad en WordPress no ayuda.
• PHP-FPM (habitual con nginx y en muchos proveedores de hosting) y php-cgi: también en riesgo. Para FPM, la vulnerabilidad está acreditada en el código fuente, pero no se ha demostrado un ataque completo.
• FrankenPHP y LiteSpeed: también figuran en la lista de instalaciones en riesgo.

CVE-2026-109618 se desencadena, por ejemplo, mediante un formulario manipulado con carga de archivos (multipart) que hace que PHP agote la memoria. Un atacante que lo consigue se ejecuta con los permisos de la cuenta del servidor web. Con ello puede, por lo general, modificar archivos del sitio web y leer los accesos a la base de datos desde la configuración.

¿Es un zero day?

Según los datos publicados, no en sentido estricto. Ni los avisos de seguridad ni php.net indican que las vulnerabilidades se explotaran antes del parche. Sin embargo, el 20 de octubre el proyecto PHP se había reservado la posibilidad de publicar antes si aparecían ataques. Desde el 21 de octubre los detalles técnicos son públicos, y la experiencia dice que el plazo hasta los primeros ataques es corto.

¿Cómo cierro la vulnerabilidad de seguridad de PHP?

Cierra la vulnerabilidad en tres pasos: instalar la actualización, reiniciar los procesos de PHP y medir el resultado. El segundo paso es el que más se olvida.

1. Instalar la actualización de PHP

En Debian y Ubuntu, la actualización llega a través del gestor de paquetes; con un panel de hosting (Plesk, cPanel), mediante su función de actualización:

sudo apt update
sudo apt install --only-upgrade 'php8.4*'

Sustituya 8.4 por su versión y repita el paso para cada versión de PHP instalada. Incluso una versión que ahora mismo no use ningún sitio web puede seguir ejecutándose como servicio.

2. Reiniciar PHP-FPM

Una actualización solo sustituye los archivos del disco. Los procesos de PHP en ejecución siguen trabajando con la versión antigua y vulnerable en memoria. Por eso, después de cada actualización hay que reiniciar:

sudo systemctl restart php8.4-fpm   # PHP-FPM
sudo systemctl restart apache2      # nur bei mod_php

3. Comprobar que realmente funciona la versión nueva

La forma más fiable es buscar procesos que aún tengan cargado un archivo PHP eliminado, es decir, antiguo:

sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'php.*(deleted)'
sudo grep -l 'libphp.*(deleted)' /proc/*/maps 2>/dev/null

Si ambas salidas quedan vacías, ya no hay ningún proceso PHP en ejecución con la versión antigua. En Debian y Ubuntu, sudo needrestart -r l muestra además qué servicios siguen usando bibliotecas antiguas. Con este método encontramos en nuestros servidores procesos que, sin reinicio, habrían seguido ejecutando código antiguo.

4. Buscar rastros

Si su servidor estuvo accesible durante mucho tiempo sin actualizar, merece la pena echar un vistazo a estos tres lugares:

• Registros: el aviso sobre CVE-2026-109619 menciona los registros de Apache, PHP-FPM y del proxy inverso, por ejemplo advertencias de PHP antes del propio script o «Maximum execution time exceeded». Según el aviso, sin embargo, la ausencia de una entrada no es prueba de seguridad.
• Archivos modificados: find /var/www -name '*.php' -newermt '2026-10-21' lista los archivos PHP modificados desde el 21 de octubre. Sus propios despliegues también aparecen ahí; es sospechoso todo lo que no pueda atribuir.
• Carpeta de cargas: los archivos PHP en carpetas que solo deberían contener imágenes y documentos (en WordPress wp-content/uploads) son una señal de alarma.

¿Qué hacer si no puedo actualizar de inmediato?

Entonces puede reducir la superficie de ataque, pero no cerrarla. Según php.net, con estas mitigaciones una instalación sigue siendo «no segura». Son un puente hasta la actualización. Todos los puntos proceden de los dos avisos de seguridad, y cada ajuste solo surte efecto tras reiniciar los procesos de PHP.

• Limitar las entradas de formularios:
  • Mantener post_max_size pequeño y limitar el tamaño de las solicitudes ya en el servidor web o en el proxy.
  • Reducir max_input_vars y max_input_nesting_level.
  • Limitar el número de cargas de archivos y de partes de formulario.
• Bloquear las cargas de archivos donde no se necesiten: si la aplicación no usa formularios multipart, el servidor web puede rechazarlos.
• Desactivar el progreso de carga: session.upload_progress.enabled=0. También tiene sentido después del parche si no necesita esa función.
• Hacer que los workers vivan poco: pm.max_requests=1 en PHP-FPM limita cuánto tiempo sobrevive el estado antiguo en un proceso. Esto cuesta rendimiento.
• Eliminar el límite de memoria (suena mal, pero es así): memory_limit=-1 es el ajuste más importante contra CVE-2026-109618, pero expresamente incompleto. Le quita al atacante el límite predecible en el que provoca la falta de memoria. El precio: una sola solicitud puede entonces ocupar tanta memoria como tenga el servidor.
• Sin RLIMIT_AS ni RLIMIT_DATA: estos límites hacen fracasar la solicitud de memoria y conducen precisamente a la ruta vulnerable.

Preguntas frecuentes sobre la vulnerabilidad de seguridad de PHP

¿Afecta la vulnerabilidad de PHP a WordPress?

Sí, si el sitio funciona con una versión de PHP sin parchear. La vulnerabilidad está en PHP mismo, no en WordPress, un plugin o un tema. Una actualización de WordPress no la cierra.

¿Debo actualizar por separado cada versión de PHP instalada?

Sí. Cada rama (8.2, 8.3, 8.4, 8.5) es un paquete propio con su propio servicio. En servidores con panel de hosting suele haber varias versiones conviviendo, y cada una necesita su actualización y su reinicio.

¿Basta con reiniciar el servidor web?

Con PHP-FPM, no: reiniciar nginx o Apache no recarga PHP. Debe reiniciar el servicio FPM de cada versión, por ejemplo php8.3-fpm y php8.4-fpm.

¿Cómo sé que mi proveedor de hosting ha reiniciado PHP?

Desde fuera, no se puede saber con certeza. Pregunte expresamente por la actualización y el reinicio. En WordPress, la Salud del sitio muestra el nuevo número de versión tras el reinicio.

¿Existe una configuración que cierre la vulnerabilidad por completo?

No. Ambos avisos de seguridad señalan la actualización como única solución completa.

Ayuda con la aplicación de parches

¿Gestiona varios servidores o un proyecto PHP a medida y quiere estar seguro de que ya no queda nada funcionando con la versión antigua? En una auditoría de código y seguridad revisamos su aplicación y su entorno de ejecución. Para una valoración rápida, puede contactarnos a través del formulario de contacto.

Fuentes

• GitHub Security Advisory GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
• GitHub Security Advisory GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (21.10.2026)
• php.net: Upcoming Critical PHP Security Release (20.10.2026)
• php.net: PHP 8.2.35 Released (con la indicación del fin del soporte el 31.12.2026)

Situación a 22 de octubre de 2026. Información técnica general sin garantía; compruebe los pasos en su sistema antes de aplicarlos.