Actualización · PHP (motor/intérprete) · RCE sin autenticación con explotación activa

Esto es una actualización de nuestro aviso anterior, «PHP (motor/intérprete) · Ejecución remota de código sin autenticación» (28 de octubre de 2026). Desde entonces hay dos hechos nuevos y relevantes: el proyecto PHP ha liberado parches de urgencia y la explotación ya está confirmada en el mundo real. Si usted administra un servidor con PHP —o su aplicación corre sobre uno—, el mensaje de hoy no es «vigile», sino «actualice ya».

Descripción

Qué es. PHP es el intérprete (el programa que lee y ejecuta el código) más extendido para construir páginas y aplicaciones web dinámicas. Las dos vulnerabilidades, bautizadas conjuntamente como PHP2Shell (un juego de palabras: «de PHP a shell», es decir, a línea de órdenes del sistema), están en el propio motor, no en el código de cada web. Se identifican como CVE-2026-109618 y CVE-2026-109619 (CVE es el identificador internacional estándar de cada vulnerabilidad).

Por qué preocupa. El fallo permite ejecución remota de código sin autenticación (en inglés, unauthenticated RCE): un atacante que no dispone de usuario ni contraseña puede, enviando peticiones manipuladas por la red, llegar a ejecutar órdenes en el servidor con los permisos del proceso web. El detalle que lo agrava es que la exposición no depende del código de la aplicación: no hace falta un formulario vulnerable ni un punto de entrada especial. Si el servidor ejecuta una versión afectada del motor, puede ser atacable incluso con una página que apenas haga nada.

A quién y a qué versiones afecta. La superficie es amplia y abarca las principales formas de desplegar PHP: PHP-FPM, php-cgi, FrankenPHP, LiteSpeed y, de forma destacada, Apache con mod_php (el módulo que integra PHP dentro del servidor web Apache), donde el riesgo es mayor porque el ataque puede activarse antes de que llegue a ejecutarse el código de la aplicación. Están afectadas todas las ramas anteriores a las versiones corregidas. Las ramas PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto; para ellas solo existen backports (parches adaptados) mínimos de código fuente para 7.4, 8.0 y 8.1, o los paquetes que publiquen las distribuciones de Linux y los proveedores con soporte extendido.

Mecánica

Ambos fallos comparten una misma raíz: PHP puede dejar su memoria interna en un estado incoherente cuando una petición termina de forma anómala, y después trata esos datos corruptos como si fueran válidos. Son errores de manejo de memoria, la clase de problema que con más frecuencia acaba permitiendo ejecutar código.

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

Según el análisis técnico publicado, el problema está en la rutina interna que inserta elementos en las tablas internas de PHP: incrementa los contadores de entradas antes de reservar la memoria de la clave. Si esa reserva supera el límite de memoria (memory_limit) y falla, queda una entrada «contada» pero sin inicializar, que la limpieza posterior de la petición procesa como si fuera legítima. Enviando campos de formulario cuidadosamente dimensionados (por ejemplo, un nombre de campo muy largo con sintaxis de array anidada), un atacante puede provocar ese fallo en el momento justo y encadenarlo hasta que la limpieza acabe llamando a system() con una orden elegida por él. Esto se ha demostrado sobre Apache con mod_php, y ocurre durante la inicialización de la petición, antes de que corra ningún código de la aplicación.

CVE-2026-109619 — estado global obsoleto (use-after-free)

Aquí el problema es que cierto estado interno asociado a una petición puede sobrevivir después de que su memoria haya sido liberada. Una petición posterior atendida por el mismo worker (el proceso que atiende varias peticiones en serie) puede leer esos restos antes de que la inicialización normal los reinicie. Es el patrón clásico de use-after-free («uso después de liberar», CWE-416): usar un puntero a memoria que ya no es válida. Dos vías concretas son el estado de los backtraces de errores fatales (solo en PHP 8.5) y, sobre todo, el seguimiento del progreso de subida de ficheros (session.upload_progress), que está activado por defecto y funciona aunque la aplicación nunca inicie una sesión.

Además de la ejecución de código, esta segunda vulnerabilidad puede provocar divulgación de memoria: un atacante podría extraer información sensible que el proceso tenga en RAM en ese momento —contraseñas, tokens, claves de API o incluso certificados— en función de las peticiones concurrentes y del comportamiento del servidor. Para que el ataque prospere, las peticiones del atacante deben alcanzar el mismo worker; un pool de procesos grande reduce la probabilidad de éxito, pero no elimina el fallo.

Respuesta del creador

Proyecto PHP. El equipo de seguridad de PHP publicó primero un preaviso (20 de octubre de 2026) y al día siguiente las versiones de emergencia. En su comunicado insiste en que solo la actualización es una solución completa y que las medidas de configuración reducen la exposición, pero no dejan la instalación a salvo. La desarrolladora del núcleo Gina Peter Banyard subrayó que ninguna mitigación bloquea del todo los ataques y que aplicar los parches oficiales es la única defensa permanente.

Autoridades. La agencia estadounidense CISA añadió ambas vulnerabilidades a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV) el 26 de octubre de 2026, con fecha límite del 29 de octubre para que las agencias federales civiles las corrigieran, bajo la directiva BOD 26-04. El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) instó a las organizaciones a actualizar de inmediato o retirar los sistemas afectados hasta parchearlos.

Industria. Proveedores como Cloudflare informaron de que ya observaban ataques tempranos antes de que salieran los parches y desplegaron reglas temporales de WAF (Web Application Firewall, el cortafuegos que filtra tráfico web), advirtiendo de que son una protección provisional y no sustituyen a actualizar. Investigadores que operan redes de señuelos (honeypots) también registraron explotación a partir del 21 de octubre. Conviene tratar con cautela las cifras de impacto que circulan en repositorios comunitarios y notas de prensa, que varían según la fuente.

Parches y mitigaciones

Actualice ya

Las versiones corregidas, publicadas el 21 de octubre de 2026, son:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Para las ramas sin soporte (8.1 y anteriores) solo hay backports mínimos de código fuente para 7.4, 8.0 y 8.1, o los paquetes de su distribución o proveedor con soporte extendido. PHP 8.2 llega a su fin de vida el 31 de diciembre de 2026, de modo que planificar el salto a una rama con soporte vuelve a ser una cuestión de seguridad, no solo de mantenimiento.

No basta con instalar el paquete. Conviene reiniciar Apache, PHP-FPM y cualquier worker persistente para asegurar que el proceso carga ya el motor parcheado. Si depende de una distribución de Linux o de un proveedor con soporte extendido, revise el changelog del paquete, porque algunos mantenedores aplican el parche sin reflejarlo de forma obvia en el número de versión.

Mitigaciones provisionales (no cierran el problema)

Si no puede actualizar de inmediato, estas medidas reducen la exposición, pero el propio PHP advierte de que no protegen por completo:

• Para CVE-2026-109618: fijar memory_limit=-1 de forma que la aplicación no pueda sobrescribirlo (por ejemplo con php_admin_value), mantener post_max_size bajo y limitar el tamaño de las peticiones en el servidor web o el proxy. Evitar RLIMIT_AS o RLIMIT_DATA como sustitutos de los límites de memoria, porque pueden activar las rutas vulnerables.
• Para CVE-2026-109619: desactivar session.upload_progress.enabled=0 y reiniciar todos los workers; en PHP 8.5, además, desactivar fatal_error_backtraces=0 y reiniciar. Ocultar los diagnósticos con error_reporting, display_errors o @ no sirve.

Después de parchear, vigile

La corrección introduce un límite duro de memoria y alcanzarlo puede terminar procesos y saltarse los manejadores de apagado. Merece la pena monitorizar señales compatibles con intentos de explotación: peticiones multipart anómalas seguidas de errores de límite de memoria, oleadas de errores HTTP 500, cookies PHPSESSID inusualmente grandes, segmentation faults o reinicios inexplicables de workers. La señal más fiable de compromiso es un proceso web que lanza una shell.

Un tercer frente relacionado

El proyecto ha asignado además CVE-2026-115560, un problema distinto ligado al progreso de subida de sesiones con un cambio concreto del serializer, que a fecha de este aviso no tiene parche y se abordará en una versión posterior. Como contención provisional sirve la misma medida: desactivar session.upload_progress.enabled.

Fuentes

• PHP — Archivo de noticias 2026 (avisos de seguridad del 20-21 de octubre)
• BleepingComputer — PHP ships emergency patches for critical PHP2Shell flaws
• BleepingComputer — CISA confirms PHP2Shell vulnerabilities now exploited in attacks
• Datadog Security Labs — PHP2Shell: critical vulnerabilities in PHP (detection, analysis, remediation)
• watchTowr — CVE-2026-109618: Exploited Remote Code Execution in PHP (FAQ)
• Security Affairs — U.S. CISA adds PHP flaws (PHP2Shell) to its Known Exploited Vulnerabilities catalog
• The Register — PHP2Shell exploitation coverage
• Help Net Security — PHP2Shell PHP vulnerabilities patched (CVE-2026-109618, CVE-2026-109619)
• Hispasec / Una al día — PHP publica parches de urgencia por dos fallos críticos PHP2Shell con intentos de explotación