21 Oct 2026 · 11:32 Jarvis Ciberplaneta Vulnerabilidades 9 min de lectura

php2shell cve-2026-109618 cve-2026-109619 php rce vulnerabilidad seguridad

PHP2Shell: dos fallas críticas amenazan servidores PHP

PHP2Shell: una alerta crítica que exige preparar el parche ahora

El proyecto PHP anunció una actualización de seguridad extraordinaria para el 21 de octubre de 2026 a las 14:00 UTC. La publicación corregirá dos vulnerabilidades críticas, ambas calificadas con CVSS v4.0 9.2. Informes coordinados de CERT-EU y firmas de investigación las identifican como CVE-2026-109618 y CVE-2026-109619, conocidas colectivamente como PHP2Shell.

El riesgo es excepcional por tres razones: las fallas se encontrarían en el propio intérprete PHP, podrían permitir ejecución remota de código sin autenticación y la información comenzó a circular antes del levantamiento previsto del embargo. El nombre PHP2Shell proviene de una herramienta de explotación mostrada en una captura filtrada; no corresponde al nombre oficial de una única vulnerabilidad.

Al momento de publicar esta alerta, las versiones corregidas y los detalles técnicos completos todavía no habían sido liberados por PHP. Por eso, cualquier afirmación sobre funciones internas, parámetros, cadenas de explotación o versiones exactas debe tratarse como preliminar hasta que aparezca el aviso oficial. La acción correcta no es improvisar una mitigación, sino identificar la exposición, preparar una ventana de emergencia y aplicar las versiones oficiales apenas estén disponibles.

Qué está confirmado y qué sigue pendiente

El aviso oficial de PHP confirma la existencia de dos vulnerabilidades críticas, la puntuación CVSS 9.2 para cada una y la publicación programada para el miércoles 21 de octubre de 2026 a las 14:00 UTC. PHP también advirtió que podría adelantar la liberación si aparecían detalles públicos o evidencia de explotación.

CERT-EU asocia la alerta con CVE-2026-109618 y CVE-2026-109619 y señala que la puntuación es consistente con un escenario de ejecución remota de código no autenticada. Informes independientes indican que una de las fallas fue reproducida por investigadores, pero los equipos responsables han evitado publicar información que facilite ataques antes de la distribución de los parches.

Confirmado por PHP: dos fallas críticas, ambas CVSS v4.0 9.2, con actualización de emergencia prevista para hoy.
Identificación pública: CVE-2026-109618 y CVE-2026-109619, citadas por CERT-EU y múltiples equipos de seguridad.
Impacto reportado: posible ejecución remota de código sin autenticación.
Alcance exacto: pendiente del aviso técnico y de la matriz oficial de versiones.
Explotación: existen reportes públicos de intentos tempranos, pero el estado debe reevaluarse con los avisos oficiales y la telemetría de cada proveedor.

Mitigaciones disponibles antes del parche

Actualización del 21 de octubre de 2026: ya existen medidas temporales para reducir la superficie de ataque durante las horas previas a la actualización oficial. Deben aplicarse en la capa de infraestructura, antes de que la solicitud llegue a PHP. Ninguna reemplaza el parche y las reglas WAF solo cubren vectores conocidos.

1. Aislar el servicio o publicar una página estática

La alternativa más segura es retirar temporalmente de Internet el servicio PHP. Detenga PHP-FPM —o el contenedor que ejecuta PHP— y haga que Nginx o Apache entregue una página estática de mantenimiento. El modo de mantenimiento de WordPress, Magento u otra aplicación no es suficiente, porque PHP procesa la solicitud antes de que el framework o CMS muestre ese aviso.

2. Bloquear temporalmente multipart/form-data

Sansec recomienda impedir que las solicitudes multipart/form-data lleguen al intérprete. Esta barrera corta el vector conocido asociado al procesamiento de cargas, pero también bloquea formularios y subidas legítimas. Debe probarse en un entorno controlado y retirarse después de actualizar PHP.

Nginx — dentro de cada bloque server que envía solicitudes a PHP:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Valide antes de recargar:

nginx -t && systemctl reload nginx

Apache — en el VirtualHost o directorio que sirve PHP, con mod_rewrite habilitado:

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

Después de activar la regla, compruebe inicios de sesión, checkout, formularios de contacto, paneles administrativos y cargas de archivos. Algunos sistemas envían formularios sin archivos como multipart.

3. Colocar el origen detrás de Cloudflare y cerrar el acceso directo

Cloudflare desplegó reglas WAF de emergencia contra los vectores de explotación conocidos, también para clientes del plan gratuito. Esta protección es una barrera provisional, no una garantía de cobertura completa. Además, no sirve si el atacante puede conectarse directamente a la IP de origen.

Active el proxy de Cloudflare y los conjuntos de reglas administradas disponibles.
Configure el firewall del origen para aceptar HTTP/HTTPS únicamente desde los rangos oficiales de Cloudflare.
Compruebe IPv4 e IPv6, balanceadores, puertos alternativos y registros DNS históricos que puedan revelar el origen.
Revise los eventos WAF y mantenga el bloqueo local en el servidor cuando sea compatible con la aplicación.

4. Convertir el sitio en solo lectura

Cuando no sea posible desconectar el servicio, una reducción adicional consiste en permitir únicamente GET y HEAD desde la capa web. Esto impide inicios de sesión, compras, cambios y formularios, pero conserva páginas estáticas o catálogos de consulta.

Nginx:

if ($request_method !~ ^(GET|HEAD)$) {
    return 503;
}

Esta medida debe considerarse defensa en profundidad y no prueba de inmunidad, porque el alcance técnico completo se conocerá con el aviso del fabricante.

Qué configuraciones no deben tratarse como solución

No confíe únicamente en desactivar session.upload_progress.enabled, cambiar memory_limit, deshabilitar file_uploads o activar el modo de mantenimiento del CMS. Investigadores y miembros del equipo de PHP han advertido que los cambios INI sugeridos inicialmente no cubren las vulnerabilidades completas. Tampoco una regla WAF genérica garantiza bloquear variantes nuevas.

Orden de preferencia mientras llega el parche: aislar o apagar PHP; si no es viable, bloquear multipart en el servidor y cerrar el origen detrás de Cloudflare; añadir modo de solo lectura; vigilar telemetría; y actualizar inmediatamente cuando PHP publique las versiones corregidas.

Análisis Técnico

Vector de Ataque

PHP procesa solicitudes dinámicas para una parte considerable de los servicios web, incluidos gestores de contenido, tiendas electrónicas, aplicaciones empresariales y desarrollos a medida. Una vulnerabilidad en el núcleo del lenguaje puede quedar expuesta a través de aplicaciones distintas que comparten la misma infraestructura, aunque el código de cada sitio no tenga una falla propia.

Los reportes disponibles describen una cadena capaz de llegar a ejecución de código desde una solicitud remota. Sin embargo, antes del aviso completo del fabricante no debe asumirse que todo despliegue PHP es explotable de la misma manera. La exposición real dependerá de la versión, del modo de ejecución —por ejemplo, PHP-FPM, Apache module o CGI—, de las extensiones habilitadas, de la configuración y de si una entrada controlada por el atacante alcanza el componente vulnerable.

CiberPlaneta no publica una prueba de concepto ni instrucciones de explotación. En una ventana de riesgo previa al parche, difundir detalles operativos puede acelerar ataques contra organizaciones que todavía no tienen una actualización disponible.

Impacto Operacional y de Seguridad

Si la ejecución remota no autenticada se confirma en los términos reportados, un atacante podría ejecutar procesos con los privilegios del servicio web, leer o modificar datos accesibles por la aplicación, implantar una web shell, robar secretos de configuración, alterar contenido y utilizar el servidor como punto de apoyo para desplazarse hacia otros sistemas.

El impacto no se limita a sitios WordPress, Magento, Drupal, Joomla, WooCommerce o Shopware. La vulnerabilidad se atribuye a PHP, por lo que también pueden quedar expuestas aplicaciones propias, APIs y paneles internos publicados mediante una versión afectada. Los equipos deben inventariar el intérprete y la plataforma de ejecución, no solo el nombre del CMS.

Confidencialidad: posible acceso a bases de datos, archivos, claves de API, credenciales y sesiones.
Integridad: modificación de aplicaciones, contenido, configuraciones y mecanismos de autenticación.
Disponibilidad: interrupción del servicio, cifrado, borrado o uso abusivo de recursos.
Persistencia: instalación de web shells, tareas programadas, usuarios o componentes maliciosos.
Movimiento lateral: uso del servidor web comprometido para alcanzar redes internas y servicios asociados.

Productos y versiones potencialmente afectados

Los reportes preliminares plantean un impacto amplio desde ramas antiguas de PHP, pero la matriz definitiva debe obtenerse del aviso oficial que acompañará la actualización. PHP mantiene actualmente ramas soportadas de PHP 8; las versiones sin soporte no deben considerarse seguras ni deben esperarse correcciones oficiales para ellas.

Las organizaciones que todavía ejecuten PHP 5, PHP 7 o ramas antiguas de PHP 8 deben preparar una migración urgente a una versión soportada. Si un proveedor de hosting, appliance o aplicación incorpora PHP de forma administrada, corresponde exigirle por escrito la versión corregida, el horario de despliegue y la evidencia de aplicación.

Recomendaciones y Mitigación

Acciones inmediatas antes de la liberación

Aislar o apagar PHP-FPM en servicios no esenciales y entregar una página estática desde Nginx o Apache.
Bloquear temporalmente multipart/form-data en el servidor web, probar las funciones críticas y vigilar respuestas 403.
Activar las reglas WAF de emergencia de Cloudflare y cerrar el acceso directo al origen mediante firewall.
Aplicar modo de solo lectura en la capa web, permitiendo únicamente GET y HEAD cuando la continuidad sea indispensable.
Inventariar todos los servidores y contenedores con PHP, registrar versión y modo de ejecución, y preparar la instalación inmediata de la actualización oficial.
Aumentar la observación de procesos del servidor web, archivos nuevos o modificados, conexiones salientes, creación de usuarios, tareas programadas y cambios en configuraciones PHP.

Acciones después de publicar el parche

Aplicar las versiones corregidas oficiales y reiniciar los procesos PHP o contenedores necesarios para cargar los binarios nuevos.
Verificar el runtime real: no basta con actualizar paquetes si un contenedor, servicio o proceso antiguo continúa en ejecución.
Volver a escanear el inventario y documentar excepciones, activos fuera de soporte y sistemas que no pudieron actualizarse.
Realizar hunting retrospectivo en activos expuestos: buscar web shells, archivos PHP inesperados, procesos hijos del servicio web, conexiones anómalas, cuentas nuevas y cambios de configuración.
Rotar secretos si existe evidencia o sospecha razonable de compromiso; parchear no elimina una intrusión previa.
No confiar exclusivamente en el WAF. Las reglas perimetrales pueden reducir intentos conocidos, pero no reemplazan la corrección del intérprete.

También debe evitarse adoptar como solución definitiva cualquier ajuste de configuración divulgado antes del análisis oficial. Distintos investigadores han advertido que algunas recomendaciones tempranas no bloquean todas las rutas posibles. Cuando el fabricante publique su boletín, las medidas provisionales deben contrastarse y reemplazarse por instrucciones verificadas.

Plan de respuesta recomendado

Identificar: listar cada instancia PHP, su versión, exposición y propietario.
Priorizar: comenzar por sistemas accesibles desde Internet y por aplicaciones con datos sensibles.
Corregir: instalar la versión oficial, reiniciar servicios y comprobar el binario realmente cargado.
Validar: confirmar funcionamiento, versión, monitoreo y ausencia de paquetes o imágenes antiguas.
Investigar: revisar evidencia de compromiso, no solo el éxito de la actualización.
Comunicar: registrar activos corregidos, excepciones, riesgos aceptados y plazos de remediación.

Referencias Oficiales y Técnicas

Esta alerta será actualizada cuando PHP publique las versiones corregidas y los detalles técnicos definitivos.