Vulnerabilidad PHP octubre 2026: CVE-2026-109618 y CVE-2026-109619 explicadas y qué hacer ahora

El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones de seguridad urgentes para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación CVSS 9.2. Pueden permitir la ejecución remota de código sin autenticación: un atacante que pueda enviar una petición web a su servidor podría ejecutar su propio código en él, sin iniciar sesión. El consejo del equipo de PHP es breve: actualice ya.

Esta guía explica, en lenguaje sencillo, a quién afecta, qué versiones corrigen el problema, cómo comprobar y actualizar sus propios servidores y qué hacer si no puede actualizar hoy. Todo lo que aquí se indica se basa en los anuncios oficiales de PHP; consúltelos para ver los detalles más recientes.

Qué ha pasado, en palabras sencillas

PHP mueve una gran parte de la web: WordPress, WooCommerce, Laravel, Drupal, Magento e innumerables sistemas empresariales a medida. Los dos fallos están dentro del propio PHP, no en una aplicación concreta, y por eso afectan a tantos sitios a la vez.

• CVE-2026-109618, «RCE mediante corrupción por falta de memoria (OOM)»: cuando PHP se queda sin memoria en el momento equivocado, los datos de la petición pueden quedar a medio preparar, y el paso de limpieza puede tratar después esos datos dañados como válidos.
• CVE-2026-109619, «RCE mediante estado global obsoleto»: datos internos de una petición pueden seguir existiendo después de liberarse su memoria, y una petición posterior atendida por el mismo proceso puede usarlos antes de que se reinicien.

Según PHP, todas las instalaciones de PHP que atienden peticiones web están en riesgo, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es mayor en Apache con mod_php, donde el equipo de PHP afirma que se ha demostrado un exploit en el que una petición sin autenticar activa el ataque antes de que se ejecute cualquier código de su aplicación. Eso significa que una aplicación bien programada no le protege: la corrección tiene que hacerse en PHP.

Qué versiones lo corrigen

Su rama de PHP	Actualice como mínimo a	Notas
8.5	8.5.12	En 8.5 hay un ajuste temporal adicional (ver más abajo).
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	PHP 8.2 llega al fin de su vida útil el 31 de diciembre de 2026. Planifique una actualización.
8.1, 8.0, 7.4 y anteriores	Sin versión oficial	Ya no tienen soporte. Consulte versiones antiguas de PHP.
Versiones de prueba 8.6	8.6.0 RC4	No aptas para producción.

Paso 1: compruebe qué versión de PHP usa realmente su sitio

Muchos servidores tienen instalada más de una versión de PHP. La versión que ve en la línea de comandos no siempre es la que sirve su sitio web, así que compruebe la que usa la web.

• Panel de control del hosting: en cPanel busque MultiPHP Manager o Select PHP Version; Plesk la muestra en la sección PHP Settings del dominio.
• WordPress: vaya a Herramientas → Salud del sitio → Información → Servidor.
• Laravel o cualquier aplicación PHP: una página temporal con <?php phpinfo(); muestra la versión exacta y qué API de servidor se usa (por ejemplo FPM/FastCGI o Apache 2.0 Handler, que es mod_php). Elimínela justo después.
• Línea de comandos: php -v, y para PHP-FPM php-fpm8.3 -v (use su número de versión).

Importante: las distribuciones Linux como Ubuntu, Debian, Red Hat y sus proveedores LTS suelen corregir fallos de seguridad sin cambiar el número de versión principal. PHP indica que las distribuciones recibieron los parches por adelantado. Si su PHP procede de su distribución, busque los dos números CVE en el aviso de seguridad o en el registro de cambios del paquete de ese proveedor, en lugar de comparar números de versión.

Paso 2: actualizar PHP

Hosting compartido o gestionado

Su empresa de hosting controla PHP. Muchas aplicarán el parche automáticamente; pida a su proveedor que confirme que su versión de PHP incluye las correcciones de CVE-2026-109618 y CVE-2026-109619. Si usa PHP 8.1 o anterior, pida pasar a una versión con soporte (8.3 u 8.4 es una opción segura para la mayoría de los sitios) y pruebe su sitio después.

Su propio servidor Ubuntu o Debian

1. Instale las actualizaciones: sudo apt update && sudo apt upgrade. Si usa un repositorio de PHP de terceros, el mismo comando descarga sus nuevos paquetes.
2. Reinicie PHP para que se detengan los procesos antiguos: sudo systemctl restart php8.3-fpm (su versión), o sudo systemctl restart apache2 si usa mod_php.
3. Vuelva a comprobar (Paso 1) y pruebe las páginas principales, los formularios, los inicios de sesión y los pagos.

Red Hat, Rocky, AlmaLinux, CentOS Stream

Ejecute sudo dnf upgrade (o el comando de su módulo o repositorio de PHP), reinicie después php-fpm o httpd y haga pruebas.

Docker y contenedores

Actualizar el servidor no basta: reconstruya sus imágenes sobre una imagen base de PHP corregida (por ejemplo una nueva compilación de php:8.3-fpm o php:8.4-apache que incluya 8.3.36 u 8.4.27), súbalas, vuelva a desplegar y asegúrese de que no quede ningún contenedor antiguo en ejecución.

Windows

Descargue la versión corregida desde la página de descargas de PHP, sustituya los archivos antiguos y reinicie IIS o su servidor web.

Sea cual sea la configuración, reinicie todos los procesos de PHP. Los procesos antiguos de PHP-FPM o Apache siguen ejecutando el código vulnerable hasta que se reinician.

Si no puede actualizar hoy

PHP deja claro que solo actualizar es una solución completa. Los ajustes siguientes reducen algunas vías de ataque, pero no hacen que un servidor sea seguro. Aplíquelos en php.ini, en el pool de FPM o en la configuración del servidor web, no con ini_set() ni .user.ini, y reinicie todos los procesos.

• Para CVE-2026-109619: establezca session.upload_progress.enabled=0. En PHP 8.5, establezca también fatal_error_backtraces=0.
• Para CVE-2026-109618: establezca memory_limit=-1 de forma que las aplicaciones no puedan cambiarlo (por ejemplo con php_admin_value), y fije un valor bajo de post_max_size: 8M si no necesita subidas de archivos, 32M si las necesita, con upload_max_filesize por debajo. Use límites de memoria del contenedor o de cgroup como barrera de seguridad, pero no use RLIMIT_AS ni RLIMIT_DATA.
• Elimine los ajustes no válidos u obsoletos que hacen que PHP muestre avisos al inicio de cada petición, y corrija los errores y tiempos de espera que un atacante podría provocar. Ocultar los avisos no sirve.

Estos ajustes pueden afectar al funcionamiento de su aplicación, sobre todo a las subidas de archivos. Pruébelos y considérelos solo un puente temporal hasta la actualización real.

Seguimiento del 23 de octubre: progreso de subida en sesiones

El 23 de octubre, PHP publicó un aviso informativo sobre un problema relacionado y menos probable (CVE-2026-115560). Solo afecta a las aplicaciones que cambian session.serialize_handler en tiempo de ejecución con ini_set() mientras el progreso de subida en sesiones está activado. PHP recomienda mantener session.upload_progress.enabled=0 hasta la próxima versión de corrección de errores habitual. Si ya lo aplicó el 21 de octubre, déjelo como está.

¿Usa PHP 8.1, 8.0, 7.4 o anterior? Cómo pasar de PHP 7.4 a 8

Estas versiones ya no reciben actualizaciones del proyecto PHP, así que no hay una versión corregida oficial. Debido a la gravedad, el equipo de seguridad de PHP publicó adaptaciones mínimas del código fuente (backports) para 7.4, 8.0 y 8.1 para quienes compilan PHP por su cuenta, y algunos proveedores de Linux y de soporte LTS ofrecen paquetes con esas correcciones. Para la mayoría de las empresas, la respuesta correcta es actualizar a PHP 8.3 u 8.4. Eso suele implicar actualizar el framework, los plugins y parte del código, así que planifíquelo en lugar de hacerlo con prisas en un sitio en producción:

1. Copie el sitio a un servidor de pruebas (staging).
2. Cambie el entorno de pruebas a la nueva versión de PHP y ejecute sus pruebas, o recorra las páginas clave si no tiene pruebas.
3. Corrija el código obsoleto y actualice los paquetes de Composer y los plugins.
4. Cambie producción en una hora tranquila, con una copia de seguridad y una forma de volver atrás.

Lista de comprobación rápida

1. Haga una lista de todos los servidores, sitios y contenedores que ejecutan PHP, incluidos los de pruebas y los sitios antiguos olvidados.
2. Compruebe la versión de PHP y cómo está instalada (hosting, paquete de la distribución, imagen Docker, código fuente).
3. Actualice a 8.5.12, 8.4.27, 8.3.36, 8.2.35 o al paquete con parche de su proveedor.
4. Reinicie todos los procesos de PHP y los servidores web.
5. Confirme la versión o el parche y, después, pruebe los inicios de sesión, los formularios, las subidas de archivos y los pagos.
6. Si no puede actualizar hoy, aplique los ajustes temporales y fije una fecha para terminar.
7. Planifique abandonar PHP 8.1 o anterior, y dejar 8.2 antes del 31 de diciembre de 2026.

Cómo puede ayudarle UnlockLive

Desarrollamos y mantenemos sistemas PHP, Laravel y WordPress desde 2008. Nuestro servicio urgente de actualización de seguridad PHP revisa todos sus servidores, aplica la corrección de la forma adecuada para su configuración (hosting, VPS, cPanel o Docker), lo reinicia todo, prueba el sitio y le envía un breve informe escrito. Si usa una versión antigua de PHP, podemos actualizarla de forma segura, primero en una copia de pruebas.

¿No sabe si le afecta? Envíenos la dirección de su sitio o reserve una llamada gratuita de 30 minutos, y un ingeniero le dirá qué hacer.