PHP lanza parches de emergencia para fallos críticos de ejecución remota de código PHP2Shell

El proyecto PHP lanzó actualizaciones de seguridad de emergencia el 21 de octubre de 2026 para abordar dos vulnerabilidades críticas conocidas colectivamente como PHP2Shell. Estos fallos residen en el núcleo del motor de ejecución de PHP, y no en aplicaciones individuales, lo que permite a los atacantes ejecutar código arbitrario en servidores web sin necesidad de autenticación. El lanzamiento se produjo un día antes de lo previsto después de que se filtraran detalles de las vulnerabilidades en línea, lo que impulsó una acción inmediata por parte del equipo de seguridad de PHP.

Qué sucedió

Las vulnerabilidades, identificadas como CVE-2026-109618 y CVE-2026-109619, tienen una calificación de severidad CVSS v4.0 de 9.2. Afectan a prácticamente todas las versiones de PHP desde PHP 5.4 en adelante. Las correcciones están disponibles en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Dado que estos errores existen en el propio motor del lenguaje, incluso una página estática "Hello World" servida por una instalación vulnerable de PHP está en riesgo. El mayor peligro recae sobre los servidores que utilizan mod_php de Apache, donde una sola solicitud no autenticada puede desencadenar la explotación antes de que se ejecute cualquier código de aplicación.

Investigadores de Wiz, Calif y OpenAI descubrieron y reportaron los fallos. Su trabajo, asistido por herramientas de IA, aceleró la identificación de exploits funcionales para código que había permanecido en PHP durante más de una década. Antes de que se lanzara el parche oficial, Cloudflare observó intentos tempranos de explotación contra sus clientes. Para cuando se publicaron los parches, la firma de seguridad watchTowr confirmó intentos de explotación activos para ambos CVE, aunque no se habían confirmado públicamente intrusiones exitosas específicas en ese momento. Servicios importantes, incluidos BambooHR y varias plataformas gubernamentales neerlandesas, desconectaron sistemas como medida preventiva.

Cómo funciona

Estas vulnerabilidades permiten a los atacantes leer memoria del proceso de trabajo de PHP y potencialmente lograr la ejecución remota de código. Este acceso a la memoria puede exponer datos sensibles como contraseñas, claves API y tokens de autenticación de otras solicitudes sin que el atacante haya obtenido primero privilegios de ejecución de código. El perfil de riesgo varía según la configuración del servidor. Mientras que mod_php es altamente susceptible a la explotación inmediata, PHP-FPM ofrece cierta resistencia natural porque termina los procesos de trabajo cuando las solicitudes fallan durante la configuración. Sin embargo, los investigadores demostraron que uno de los fallos aún podría alcanzar la ejecución de código en PHP-FPM bajo condiciones específicas que involucran operaciones dentro de la aplicación en ejecución.

El proceso de divulgación se vio interrumpido cuando una firma de investigación publicó accidentalmente un video de prueba de concepto y un proveedor publicó imágenes de contenedores parcheadas horas antes del lanzamiento oficial. Esta exposición prematura obligó al equipo de PHP a acelerar su cronograma. Los problemas subyacentes surgieron de mecanismos complejos de gestión de memoria y manejo de sesiones que formaban parte de PHP desde hacía años. Una auditoría externa de 2024 había señalado inicialmente indicios del fallo de desbordamiento de memoria detrás de CVE-2026-109618, pero no se estableció un vector de ataque concreto hasta que investigaciones recientes asistidas por IA aclararon la ruta de explotación.

Detalles clave

• Versiones afectadas: Todas las versiones de PHP desde 5.4 hasta 8.5.11, 8.4.26, 8.3.35 y 8.2.34 son vulnerables.
• Versiones corregidas: Actualice inmediatamente a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35.
• Riesgo máximo: Los servidores que usan Apache mod_php son los más vulnerables a la ejecución remota de código sin autenticación.
• Mitigaciones parciales: Para CVE-2026-109619, establecer session.upload_progress.enabled=0 reduce el riesgo, pero no soluciona completamente el problema.
• Soporte heredado: PHP 8.1 y anteriores han alcanzado el fin de su vida útil; hay backports de código fuente disponibles para PHP 7.4, 8.0 y 8.1 para quienes compilan desde el código fuente.
• Señales de detección: Busque solicitudes multipart extrañas, errores de límite de memoria, respuestas HTTP 500 repetidas y reinicios inesperados de los procesos de trabajo de PHP.

Por qué importa

Para ingenieros de software y líderes de TI, este incidente destaca la diferencia crítica entre la seguridad a nivel de aplicación y las vulnerabilidades a nivel de tiempo de ejecución. Actualizar frameworks como Laravel o WordPress no protege contra PHP2Shell porque el fallo existe en el intérprete subyacente. Esto significa que incluso las aplicaciones bien auditadas están expuestas si el entorno del servidor no está parcheado. La velocidad con la que la investigación asistida por IA convirtió bugs teóricos de larga data en exploits funcionales también subraya la necesidad de ciclos de parcheo rápidos. Esperar a una ventana de mantenimiento programada ya no es una estrategia viable para fallos críticos de tiempo de ejecución.

La interrupción causada por filtraciones prematuras e intentos de explotación activos demuestra la fragilidad de la divulgación coordinada en el panorama moderno de amenazas. Las organizaciones deben tener planes sólidos de respuesta a incidentes que incluyan la capacidad de actualizar rápidamente componentes de infraestructura. Confiar únicamente en ajustes de configuración como estrategia de mitigación es peligroso, ya que los desarrolladores principales de PHP declararon explícitamente que solo la actualización proporciona protección completa. Este evento sirve como recordatorio de que las dependencias de infraestructura requieren el mismo nivel de vigilancia que el código de aplicación.

Qué puede hacer

• Identifique todos los servidores que ejecutan PHP y verifique sus números de versión actuales contra las versiones corregidas listadas arriba.
• Actualice el paquete de tiempo de ejecución de PHP mediante su gestor de paquetes del sistema o reconstruya las imágenes de contenedor con las versiones parcheadas.
• Reinicie todos los servidores web, grupos de PHP-FPM y procesos de trabajo de PHP de larga duración para asegurar que se cargue el nuevo binario.
• Si la actualización inmediata no es posible, aplique mitigaciones parciales como deshabilitar el progreso de carga de sesiones y aplicar límites estrictos de memoria, pero planee parchear lo antes posible.
• Monitoree los registros buscando indicadores de compromiso, incluyendo envíos extraños de formularios multipart y picos súbitos de errores 500.
• Verifique que el registro de cambios del paquete de su distribución Linux incluya las correcciones relevantes de CVE, ya que las cadenas de versión pueden no reflejar siempre el estado del parche en distribuciones LTS.