(CVE-2026-109618 y CVE-2026-109619)

Qué ha pasado, a quién afecta, cómo parchear y cómo protegerse si no se puede

Introducción

El pasado 21 de octubre de 2026 se publicaron dos vulnerabilidades críticas en el núcleo de PHP que han afectado a servidores de todo el mundo. Muchas organizaciones se vieron obligadas a aplicar parches de urgencia e incluso a apagar o aislar servicios temporalmente mientras se actualizaban sus sistemas.

PHP es la base de una enorme parte de la web: gestores de contenido, tiendas online, paneles de hosting y aplicaciones a medida. Por eso, un fallo en el propio intérprete, y no en una aplicación concreta, tiene un alcance tan grande.

En este artículo explicamos de qué se trata esta vulnerabilidad, a qué versiones afecta, cuáles se pueden parchear, qué hacer cuando no hay actualización disponible y cómo prevenir futuros ataques de este tipo.

Nota: la situación evoluciona rápidamente. Las cifras y versiones de este artículo corresponden al 25 de octubre de 2026; conviene revisar siempre el aviso oficial de PHP antes de actuar.

Índice

1. Introducción
2. ¿Qué ha pasado? Cronología
3. ¿En qué consisten las vulnerabilidades?
4. Versiones afectadas y versiones corregidas
5. Cómo solucionarlo con la actualización
6. Sistemas sin actualización disponible
7. Cómo detectar si hemos sido atacados
8. Prevención: cómo reducir el riesgo ante futuras vulnerabilidades
9. Conclusión
10. Fuentes

2. ¿Qué ha pasado? Cronología

• 20 de octubre: detalles de los dos fallos se filtraron públicamente antes de la divulgación coordinada. Algunos proveedores de hosting aplicaron medidas preventivas ese mismo día.
• 21 de octubre: el equipo de PHP publicó versiones de seguridad de emergencia y el aviso oficial. Distribuciones Linux y proveedores LTS ya habían recibido los parches por adelantado.
• 21 de octubre: varias firmas de seguridad reportaron explotación activa en Internet.
• 22 de octubre: hasta esa fecha, CISA no había añadido estos CVE a su catálogo de vulnerabilidades explotadas conocidas (KEV), según el análisis de watchTowr.

A este conjunto de fallos se le conoce como PHP2Shell. Ambos tienen una puntuación CVSS v4.0 de 9.2 (crítica).

3. ¿En qué consisten las vulnerabilidades?

Ambas permiten a un atacante sin autenticación ejecutar código de forma remota (RCE) en el servidor, con los privilegios del proceso PHP.

CVE-2026-109618: corrupción por falta de memoria

Cuando PHP se queda sin memoria durante el procesamiento de una petición, abandona el contexto actual de forma abrupta. Esto puede dejar datos de la petición a medio inicializar, y la rutina de limpieza posterior los trata como si fueran válidos. Una petición multipart manipulada puede provocar esta situación y, con Apache mod_php, puede ocurrir antes de que se ejecute cualquier código de la aplicación.

CVE-2026-109619: estado global obsoleto

PHP conserva un estado global que apunta a memoria perteneciente a una petición. Si ese estado no se reinicia antes de liberar la memoria, una petición posterior atendida por el mismo proceso puede usar ese estado obsoleto. Según el equipo de PHP, esto está relacionado con el seguimiento del progreso de subida de sesiones y, en PHP 8.5, con las trazas de errores fatales.

Por qué es tan grave

• No requiere credenciales ni cuenta de usuario.
• El ataque ocurre antes de que intervenga la lógica de la aplicación, por lo que la autenticación de la app no protege.
• Afecta a todos los modos de ejecución: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
• Aplicaciones como WordPress, Drupal, Magento o cualquier framework heredan el riesgo del intérprete.

4. Versiones afectadas y versiones corregidas

Según los análisis publicados, el fallo afecta a versiones desde PHP 5.4 hasta 8.5.11.

Rama	Versiones vulnerables	Versión corregida	¿Soporte oficial?
PHP 8.5	anteriores a 8.5.12	8.5.12	Sí
PHP 8.4	anteriores a 8.4.27	8.4.27	Sí
PHP 8.3	anteriores a 8.3.36	8.3.36	Sí
PHP 8.2	anteriores a 8.2.35	8.2.35	Solo seguridad; fin de vida el 31/12/2026
PHP 8.1 y anteriores	todas	Sin versión oficial	No (fin de vida)

Cuáles se pueden parchear: las ramas 8.2, 8.3, 8.4 y 8.5 tienen parche oficial. Para las ramas sin soporte, el equipo de seguridad de PHP facilitó backports mínimos en código fuente para PHP 7.4, 8.0 y 8.1, pensados para quienes compilan PHP ellos mismos. Además, algunas distribuciones y proveedores LTS pueden ofrecer paquetes con el arreglo retroportado.

5. Cómo solucionarlo con la actualización

PHP lo deja claro: no existe una mitigación completa; actualizar es la única opción segura.

Paso 1: inventariar

Localizar todas las instalaciones de PHP, no solo los servidores web evidentes. Revisar también paneles de hosting (cPanel, Plesk), appliances internos, contenedores, imágenes Docker y binarios incluidos en aplicaciones (php.exe, php-cgi.exe).

Comprobar la versión instalada:

php -v
php-fpm -v

Paso 2: actualizar según el sistema

• Paquetes de la distribución (Debian, Ubuntu, RHEL, Alma, Rocky…): actualizar con el gestor de paquetes y comprobar el número de paquete del proveedor, ya que muchas distribuciones mantienen su numeración con parches retroportados.
• Repositorios de terceros (por ejemplo Sury u Remi): actualizar desde ellos a la versión corregida de la rama que se use.
• Contenedores: reconstruir las imágenes con la imagen base de PHP corregida y volver a desplegar; no basta con actualizar el host.
• Compilación desde código fuente: usar las versiones 8.2.35, 8.3.36, 8.4.27 u 8.5.12 de la página oficial de descargas.
• Windows: descargar los binarios actualizados de php.net.

Paso 3: reiniciar los procesos

Tras actualizar hay que reiniciar PHP-FPM, Apache o el servidor que corresponda. Un proceso que sigue cargado en memoria con la versión antigua sigue siendo vulnerable.

Paso 4: verificar

Confirmar la versión en ejecución (no solo la instalada) y revisar que no queden instalaciones olvidadas.

6. Sistemas sin actualización disponible

Es el caso de versiones antiguas (8.1 y anteriores) o aplicaciones que no soportan una versión más moderna de PHP. Las medidas de este apartado reducen la exposición a rutas de ataque concretas, pero no hacen seguro el sistema. Son un puente hasta migrar.

Opciones por orden de preferencia

1. Migrar a una rama soportada (8.3, 8.4 u 8.5) aunque suponga trabajo de compatibilidad.
2. Obtener un paquete con el parche retroportado de la distribución o de un proveedor de soporte extendido (LTS).
3. Compilar con los backports oficiales de PHP para 7.4, 8.0 u 8.1 si el equipo tiene capacidad de mantener sus propias compilaciones.
4. Aislar el sistema si ninguna de las anteriores es posible.

Mitigaciones temporales recomendadas por los proveedores

Para CVE-2026-109618 (memoria):

• Fijar memory_limit=-1 de forma que las aplicaciones no puedan modificarlo. Esto evita llegar al error de falta de memoria dentro de PHP, pero debe compensarse limitando recursos en otro nivel (por ejemplo, con límites del contenedor o del sistema operativo).
• Establecer un valor bajo en post_max_size.
• Aplicar límites en el servidor web o proxy inverso: tamaño total de la petición, número y tamaño de partes multipart, tamaño de cabeceras y profundidad de anidamiento.

Para CVE-2026-109619 (estado global):

• Desactivar session.upload_progress.enabled=0.
• En PHP 8.5, desactivar fatal_error_backtraces=0.
• Reiniciar todos los workers.
• Eliminar configuraciones por petición inválidas u obsoletas que generen avisos antes de inicializar la petición.

Estos ajustes deben hacerse en php.ini o en la configuración del pool de PHP-FPM.

Medidas de contención adicionales

• No exponer el servicio a Internet: ponerlo detrás de VPN o restringir el acceso por IP.
• Regla de WAF o proxy inverso que bloquee peticiones multipart anómalas o de gran tamaño.
• Segmentación de red: que el servidor no pueda llegar a sistemas internos sensibles.
• Restringir la salida a Internet del servidor para dificultar la descarga de herramientas por parte de un atacante.
• Ejecutar PHP con un usuario sin privilegios y con el sistema de ficheros lo más restringido posible.
• Monitorización reforzada mientras la migración está pendiente.

7. Cómo detectar si hemos sido atacados

Dado que hubo explotación activa desde el mismo día de la publicación e incluso antes, conviene asumir que un servidor expuesto y sin parchear puede haber sido objetivo de ataque.

Qué buscar

• Procesos hijo anómalos lanzados directamente por los procesos PHP (php-fpm, php-cgi, httpd, apache2), por ejemplo shells (sh, bash), curl, wget, intérpretes o herramientas de red.
• Conexiones salientes inesperadas desde el servidor web.
• Ficheros nuevos o modificados en directorios web, especialmente .php en carpetas de subidas o temporales (webshells).
• Peticiones POST multipart inusuales en los logs del servidor web: tamaños grandes, muchas partes, o muchos reinicios de workers con errores de memoria.
• Cron jobs o usuarios nuevos y cambios en claves SSH.

Qué hacer si hay indicios

1. Aislar el servidor de la red.
2. Conservar logs y, si es posible, una copia forense antes de limpiar.
3. Rotar todas las credenciales accesibles desde el servidor (bases de datos, API keys, certificados, claves SSH).
4. Reconstruir desde una imagen limpia y actualizada en lugar de «limpiar» el sistema comprometido.
5. Revisar posibles movimientos laterales hacia otros sistemas.

8. Prevención: cómo reducir el riesgo ante futuras vulnerabilidades

Ninguna organización puede evitar que aparezcan fallos en el software, pero sí puede reducir mucho su impacto y su ventana de exposición.

Gestión de parches y ciclo de vida

• Mantener un inventario actualizado de todo el software y sus versiones.
• Definir plazos de parcheo según criticidad: horas o días para fallos críticos con explotación activa.
• Planificar la migración de versiones antes de su fin de vida. PHP 8.2, por ejemplo, deja de recibir parches de seguridad el 31 de diciembre de 2026.
• Suscribirse a los avisos de seguridad de PHP, de la distribución y de los proveedores de las aplicaciones.

Arquitectura y aislamiento

• Usar contenedores o máquinas separadas por aplicación y con privilegios mínimos.
• Ejecutar cada sitio con su propio usuario y pool de PHP-FPM.
• Montar el código de la aplicación en solo lectura siempre que sea posible.
• Segmentar la red para que un servidor web comprometido no llegue a las bases de datos u otros sistemas internos más allá de lo estrictamente necesario.
• Filtrar el tráfico saliente (egress) de los servidores.

Capas de protección

• WAF o proxy inverso delante de las aplicaciones, con límites de tamaño de petición, partes multipart, cabeceras y anidamiento. Es una capa de defensa adicional, no un sustituto del parche.
• IPS y protección de aplicaciones web en el firewall perimetral, con firmas actualizadas.
• Reducir la superficie expuesta: no publicar paneles de administración, entornos de pruebas ni servicios innecesarios.

Detección y respuesta

• Centralizar los logs del servidor web, del sistema y del firewall en una plataforma de análisis (en nuestro caso, FortiAnalyzer ayuda a correlacionar tráfico sospechoso con equipos concretos).
• Alertar de procesos hijo anómalos en los procesos PHP mediante EDR o reglas de auditoría del sistema.
• Tener un plan de respuesta a incidentes probado, incluyendo cómo aislar un servidor y cómo reconstruirlo rápidamente.
• Mantener copias de seguridad fuera de línea y verificar que se pueden restaurar.

Una advertencia sobre disable_functions

Desactivar funciones peligrosas como exec o system es una buena práctica general, pero no protege frente a este tipo de fallos, porque la ejecución de código se consigue corrompiendo la memoria del propio intérprete. Es una capa útil, no una solución.

9. Conclusión

PHP2Shell es un recordatorio de que un fallo en el componente base de una plataforma puede afectar a miles de aplicaciones a la vez, y de que el tiempo entre la publicación y la explotación se mide ahora en horas.

Las ideas clave son:

• Actualizar es la única solución completa: PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, y reiniciar los procesos después.
• Las versiones 8.1 y anteriores no tienen parche oficial; hay que migrar, buscar un paquete retroportado o compilar con los backports oficiales.
• Si no se puede actualizar de inmediato, limitar la exposición, aplicar las mitigaciones temporales y vigilar el servidor con atención.
• Conviene asumir que pudo haber explotación en sistemas expuestos y revisarlos.
• A largo plazo, la mejor defensa es tener inventario, ciclo de vida controlado, aislamiento, defensa en capas y buena monitorización.

La próxima vulnerabilidad crítica llegará. Lo que marcará la diferencia será cuánto tardemos en saber qué tenemos expuesto y en actuar.

10. Fuentes

• Aviso de seguridad oficial de PHP (21 de octubre de 2026): https://www.php.net/archive/2026.php#2026-10-21-5
• Versiones publicadas en GitHub: php-8.5.12, php-8.4.27 y php-8.2.35 en https://github.com/php/php-src/releases
• Avisos GitHub Security Advisories: GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp
• Análisis de runZero, Datadog Security Labs, watchTowr, Google Cloud y proveedores de hosting