PHP2Shell: dos fallas críticas en PHP que la NSA pide corregir hoy (CVE-2026-109618 y CVE-2026-109619)

Actualizado el 22 de octubre de 2026. Este artículo se irá ajustando conforme la NSA, CISA y el proyecto PHP publiquen más información.

El 21 de octubre de 2026 el proyecto PHP publicó una actualización de seguridad de emergencia para dos vulnerabilidades críticas, bautizadas en conjunto como PHP2Shell: CVE-2026-109618 y CVE-2026-109619. Ese mismo día la Agencia de Seguridad Nacional de Estados Unidos (NSA) y la agencia CISA emitieron avisos pidiendo parchar de inmediato y, si no es posible, desconectar de internet los sistemas afectados. Varios portales gubernamentales de Países Bajos, Dinamarca, Finlandia y Francia se apagaron de forma preventiva mientras actualizaban.

Si tu empresa tiene un sitio web, una tienda en línea, una intranet o cualquier sistema desarrollado en PHP, esto te afecta. En este artículo explicamos qué es la falla, qué puede pasarle a tu organización, qué hacer hoy y cómo podemos ayudarte desde StackFire. Al final encontrarás un cuestionario de autodiagnóstico para saber en minutos qué tan expuesto estás.

¿Qué es PHP2Shell?

PHP es el lenguaje que corre detrás de aproximadamente tres de cada cuatro sitios web del mundo: WordPress, Drupal, Joomla, Magento, PrestaShop, Moodle, Laravel, Symfony y miles de sistemas a la medida. PHP2Shell no es una falla de un plugin ni de una aplicación en particular: es una falla del intérprete de PHP en sí, por lo que afecta a cualquier aplicación que corra sobre una versión vulnerable, sin importar qué tan bien esté programada.

Las dos vulnerabilidades permiten ejecución remota de código sin autenticación: un atacante en internet puede enviar una petición web especialmente construida y lograr que el servidor ejecute comandos arbitrarios, sin contraseña, sin usuario y sin que nadie haga clic en nada. Ambas tienen una calificación CVSS 4.0 de 9.2 sobre 10 (crítica).

CVE-2026-109618. Cuando PHP se queda sin memoria a la mitad de procesar una petición (por ejemplo, al leer un formulario con archivos adjuntos), interrumpe el trabajo con los datos internos a medio inicializar. La limpieza posterior trata esa memoria corrupta como válida y el atacante, que controla el contenido de la petición, puede aprovecharlo para ejecutar código. El tamaño de la petición y la carga de archivos son el camino de ataque.
CVE-2026-109619. El estado interno de una petición puede sobrevivir después de que su memoria fue liberada (por ejemplo, tras un error fatal). La siguiente petición atendida por el mismo proceso usa ese estado “fantasma” antes de reiniciarlo. Además de ejecutar código, permite leer memoria del servidor: contraseñas, tokens de sesión, llaves de API y certificados de otros usuarios pueden quedar expuestos aun sin tomar control total.

Según el proyecto PHP, están afectadas todas las instalaciones que atienden peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. La configuración de mayor riesgo es Apache con mod_php, donde se demostró un exploit con una sola petición que se dispara antes de que corra el código de la aplicación. En PHP-FPM el arranque de los procesos bloquea una de las rutas de ataque, pero el propio equipo de PHP validó ejecución remota de código también sobre FPM bajo condiciones de aplicación habituales. Las fallas existen desde versiones de 2004 (PHP 5.4) hasta PHP 8.5.11.

Versiones corregidas

PHP 8.5 → 8.5.12
PHP 8.4 → 8.4.27
PHP 8.3 → 8.3.36
PHP 8.2 → 8.2.35

PHP 8.1 y anteriores (8.0, 7.x, 5.x) ya no reciben actualizaciones oficiales. El proyecto publicó únicamente parches de código fuente mínimos para 7.4, 8.0 y 8.1, pensados para quien compila PHP por su cuenta. Si dependes de tu distribución de Linux (Debian, Ubuntu, RHEL, etc.) o de tu proveedor de hosting, revisa que ya hayan publicado paquetes corregidos: a veces conservan un número de versión anterior y aplican el parche por detrás. Se estima que cerca del 71 % de las instalaciones de PHP en internet corren versiones sin soporte.

¿Ya se está explotando?

En su aviso del 21 de octubre, CISA indicó que no había observado explotación activa al momento de publicarlo. Sin embargo, desde entonces han circulado pruebas de concepto, CERT-EU advierte que eso eleva la probabilidad de ataques inminentes y Cloudflare reportó tráfico de ataque dirigido contra sus clientes, incluidos intentos de evadir sus protecciones. La NSA fue explícita: es probable que actores maliciosos conviertan PHP2Shell en un arma rápidamente. La ventana para actuar es de días, no de semanas.

¿Cómo puede afectar a tu empresa?

Un atacante que explota PHP2Shell obtiene los mismos permisos que el proceso de PHP en tu servidor. En la práctica eso significa:

Toma de control del servidor web. Instalación de web shells (puertas traseras) para regresar cuando quiera, aunque luego apliques el parche.
Robo de credenciales y llaves. CVE-2026-109619 permite leer memoria de otras peticiones: contraseñas de clientes, cookies de sesión de administradores, llaves de pasarelas de pago, tokens de APIs y conexiones a bases de datos.
Fuga de datos personales. Bases de clientes, pedidos, expedientes, nómina. En México esto activa obligaciones de notificación bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares, además del daño reputacional.
Movimiento lateral y ransomware. El servidor web comprometido es la puerta de entrada a la red interna: ERPs, CRMs, servidores de archivos y respaldos.
Alteración del sitio y fraude. Páginas de pago falsas, inyección de código que roba tarjetas (skimming), redirecciones a sitios de phishing, minado de criptomonedas con tus recursos.
Interrupción del negocio. Tienda caída en temporada alta, portal de clientes fuera de línea, pérdida de posicionamiento en buscadores al ser marcado como sitio malicioso.
Sanciones y contratos. Incumplimiento de PCI DSS si procesas tarjetas, de cláusulas de seguridad con tus clientes corporativos o de requisitos de ciberseguros.

Un detalle que suele pasarse por alto: PHP también vive dentro de productos de terceros. Paneles de administración de hosting, equipos NAS, conmutadores de telefonía IP, herramientas de monitoreo, intranets heredadas y hasta algunos appliances de red incluyen PHP sin que sea evidente. CISA pide inventariarlos explícitamente.

¿Qué hacer hoy?

Inventaría todo lo que corre PHP. Servidores propios, máquinas virtuales, contenedores, hosting compartido, servicios administrados y productos de terceros. Si no sabes si algo usa PHP, asume que sí hasta confirmarlo.
Actualiza y reinicia. Instala 8.5.12, 8.4.27, 8.3.36 u 8.2.35 (o el paquete corregido de tu distribución) y reinicia PHP-FPM o el servidor web: hasta que reinicias, los procesos siguen ejecutando el intérprete viejo. Verifica la versión del intérprete que realmente atiende las peticiones web; php -v en la terminal puede señalar otra instalación.
Prioriza lo expuesto a internet. Sitios públicos, tiendas, portales de clientes y cualquier cosa con formularios o carga de archivos van primero.
Si no puedes parchar hoy, desconecta. Es la recomendación literal de la NSA y CISA. Si desconectar no es opción, aplica mitigaciones temporales (siguiente sección) y pon un WAF delante, entendiendo que ninguna de las dos te deja seguro.
Planea el retiro de PHP 8.1 y anteriores. No habrá parche oficial. Migra a 8.2 o superior y, mientras, aísla esos servidores.
Busca señales de compromiso. Procesos de PHP que lanzan shells o descargan herramientas, archivos nuevos o modificados en las carpetas del sitio, conexiones salientes inusuales desde el servidor web, usuarios administradores que no reconoces. Si encuentras algo, trátalo como incidente: el parche no expulsa a quien ya entró.
Exige confirmación a tus proveedores. Hosting, agencia web, SaaS que use PHP: pide por escrito la versión instalada y la fecha del reinicio.

Mitigaciones temporales (no sustituyen el parche)

El proyecto PHP y CERT-EU documentan ajustes de configuración que reducen la exposición mientras se actualiza. Deben aplicarse en php.ini, en el pool de PHP-FPM o en la configuración del servidor web (no desde la aplicación con ini_set()), seguidos de un reinicio de todos los procesos:

Para CVE-2026-109618: memory_limit = -1 fijado de forma que la aplicación no pueda cambiarlo; post_max_size bajo (8M, o 32M si necesitas cargas) con upload_max_filesize menor; límites de tamaño, campos y anidación de peticiones en el proxy o servidor web; límites de memoria por contenedor o cgroup en lugar de RLIMIT_AS.
Para CVE-2026-109619: session.upload_progress.enabled = 0; en PHP 8.5, fatal_error_backtraces = 0; en PHP-FPM, pm.max_requests = 1 para que ningún estado sobreviva entre peticiones; eliminar directivas php_value o .htaccess inválidas que generen avisos antes de inicializar; corregir errores fatales y timeouts alcanzables por un atacante.

Insistimos: estas medidas reducen el riesgo, pero el equipo de PHP es claro en que la única corrección completa es actualizar.

¿Cómo te ayudamos en StackFire?

Llevamos años operando infraestructura web, correo y seguridad para empresas en México y Latinoamérica. Para PHP2Shell armamos un servicio de respuesta en tres fases, que puedes contratar completo o por partes:

Diagnóstico exprés (24 a 48 horas). Inventario de todas tus instalaciones de PHP (servidores, contenedores, hosting, productos de terceros), identificación de la versión que realmente atiende cada sitio, del modo de ejecución (mod_php, FPM, CGI) y de su exposición. Entregamos un reporte con prioridades y un plan de acción concreto.
Remediación. Actualización de PHP y reinicio controlado de servicios con ventana de mantenimiento y respaldo previo; aplicación de las mitigaciones temporales donde el parche deba esperar; migración de aplicaciones que siguen en PHP 8.1 o anteriores a una versión con soporte, incluida la revisión de compatibilidad del código; coordinación con tu proveedor de hosting o agencia cuando el servidor no es tuyo.
Protección y vigilancia continua. Despliegue de un WAF con reglas de carga de archivos y límites de petición; monitoreo de integridad de archivos, procesos y tráfico saliente en tus servidores web desde nuestro Security Hub; búsqueda de indicadores de compromiso en los registros de las últimas semanas; y, si encontramos actividad maliciosa, respuesta a incidentes con contención, limpieza y recuperación.

Además, si eres cliente de nuestros servicios administrados de hosting o de infraestructura en la nube, ya estamos aplicando los parches en los servidores bajo nuestra operación y te notificaremos por los canales habituales conforme concluya cada ventana. Si tienes dudas sobre un sistema en particular, abre un ticket en el portal o escríbenos.

¿Estás expuesto? Responde el cuestionario

Contesta estas diez preguntas sobre tus desarrollos y tu infraestructura. Al enviarlo verás de inmediato tu nivel de riesgo con los hallazgos y las acciones recomendadas para tu caso, y un especialista de StackFire se pondrá en contacto contigo para ayudarte a resolverlo. No necesitas datos técnicos exactos: si no sabes alguna respuesta, elige “No lo sé”; esa también es información útil.

Cargando cuestionario…