¿Qué es PHP2Shell? Vulnerabilidades críticas de PHP (CVE-2026-109618 / 109619) y cómo respondió Partnerfy

Respuesta breve: PHP2Shell es el nombre que reciben dos vulnerabilidades de seguridad críticas del núcleo de PHP, corregidas el 21 de octubre de 2026: CVE-2026-109618 y CVE-2026-109619. Ambas obtuvieron una puntuación de 9,2 (crítica) en la escala CVSS v4.0. En el peor de los casos, el atacante no necesita ninguna cuenta: le bastan solicitudes HTTP especialmente diseñadas para ejecutar código en el servidor web (RCE). El problema no está en su aplicación, sino en el propio PHP. Eso significa que incluso un código impecable de WordPress o Laravel, o un sencillo sitio “Hola, mundo”, corre peligro si funciona con una versión vulnerable de PHP. La única solución completa es actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 (o al paquete con parche de su distribución) y reiniciar todos los procesos de trabajo (workers) de PHP. En Partnerfy no esperamos al parche oficial: unas tres horas antes de su publicación aplicamos una mitigación temporal en nuestros servidores, hicimos copias de seguridad completas de las cuentas y reforzamos nuestras defensas capa por capa. En este artículo explicamos cómo salió a la luz la vulnerabilidad, en qué consiste técnicamente, qué debe hacer usted y qué hemos hecho nosotros.

Este artículo está dirigido a propietarios de empresas y equipos técnicos cuyo sitio web, plataforma de comercio electrónico o software a medida funciona con PHP. Los detalles técnicos se basan en el anuncio oficial de seguridad del proyecto PHP, en los avisos de seguridad de PHP en GitHub (GHSA) y en las publicaciones de los investigadores que descubrieron los fallos. Cuando las fuentes se contradicen, lo indicamos expresamente. La situación evoluciona con rapidez. Este artículo está actualizado a fecha de la noche del 21 de octubre de 2026.

¿Qué es PHP2Shell y por qué es tan grave?

PHP es uno de los lenguajes del lado del servidor más utilizados en la web. WordPress, WooCommerce, Drupal, Joomla, Magento y Laravel funcionan con PHP. Tres características hacen que PHP2Shell sea tan grave:

• No requiere autenticación. El atacante no necesita registrarse en su sitio, conocer una contraseña ni rellenar un formulario. Le bastan solicitudes especialmente diseñadas.
• Puede activarse antes de que se ejecute el código de su aplicación. Según el proyecto PHP, el riesgo es mayor en las instalaciones de Apache con mod_php. En ellas se demostró que una solicitud no autenticada desencadena el ataque antes de que se ejecute cualquier código de la aplicación. Ni los plugins actualizados, ni el código limpio, ni los controles de seguridad dentro de la aplicación cierran esta vía.
• El alcance es extremadamente amplio. Según el proyecto PHP, la exposición abarca “todas las instalaciones de PHP que atienden solicitudes web”: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Según Wiz, uno de los equipos que descubrieron los fallos, todas las versiones de PHP publicadas en la última década, remontándose hasta la 5.4, están afectadas por al menos una de las dos vulnerabilidades. Esa afirmación sobre el alcance es de Wiz; el aviso oficial de PHP solo enumera las ramas con soporte 8.2–8.5.

Los veredictos son contundentes. Wiz describe los hallazgos como “algunas de las vulnerabilidades más graves descubiertas en PHP”. Según declaraciones recogidas por la prensa, el Centro Nacional de Ciberseguridad del Reino Unido (NCSC) recomendó desconectar los sistemas que no se pudieran parchear de inmediato. CERT-EU aconsejó igualmente aislar las aplicaciones expuestas a internet hasta disponer de un parche. El investigador de seguridad Kevin Beaumont resumió bien el panorama: “La situación de PHP provocará una gran cantidad de incidentes”.

¿Cómo salió a la luz? La cronología

La historia de PHP2Shell comienza en 2024 y desemboca en una de las semanas de ciberseguridad más turbulentas de 2026. Todas las horas se indican en UTC.

En el momento de la publicación, ninguna fuente pública ha confirmado que un servidor concreto haya sido comprometido con éxito a través de estos fallos. Pero los intentos ya han comenzado y los investigadores prevén que el asunto tenga una larga cola. En palabras del especialista en respuesta a incidentes Hal Pomeranz: “Esto va a tener una larga cola”.

El factor IA: la distancia entre parche y exploit ya se mide en horas

Otro detalle convierte a PHP2Shell en una historia muy propia de 2026: los modelos de IA intervinieron tanto en el descubrimiento del fallo como en la búsqueda de la forma de explotarlo. El equipo Codex Security de OpenAI notificó uno de los hallazgos de forma independiente. Wiz, por su parte, escribe: “Los modelos de IA de vanguardia redujeron sustancialmente esa barrera y convirtieron un fallo de larga data en un exploit”. Un error que en 2024 se quedó en lo teórico se convirtió en un arma en 2026 con la ayuda de las máquinas. Para quienes defienden los sistemas, el mensaje es claro: el reloj empieza a correr en el momento en que se publica un parche, y el lujo de “ya lo miraremos el fin de semana” ha desaparecido.

¿Qué ocurre por dentro? Dos fallos, dos causas raíz distintas

Ambas vulnerabilidades son errores de seguridad de la memoria. Las dos están relacionadas con la forma en que PHP gestiona los errores fatales (en particular, los de falta de memoria) que se producen mientras procesa una solicitud. Pero sus mecanismos son distintos.

CVE-2026-109618: datos “a medio construir” en el momento en que se agota la memoria

Cuando se supera el límite de memoria durante una solicitud (out-of-memory, OOM), PHP sale bruscamente de su contexto actual mediante un mecanismo llamado longjmp() y aborta la solicitud. El aviso oficial describe así el problema: en determinados puntos, la memoria de la solicitud pasa a ser accesible antes de haberse inicializado por completo. Si una asignación de memoria falla justo en ese instante, PHP no tiene en cuenta correctamente esa salida anticipada y la memoria queda en un estado no válido. Después, la rutina de cierre de la solicitud lee esos datos a medio construir y actúa en función de ellos. El resultado es la corrupción de la memoria y, si el ataque se diseña correctamente, la ejecución de código.

Piense en la cocina de un restaurante: un camarero está anotando una comanda cuando lo llaman de repente y la comanda queda a medias. El equipo de cierre da por hecho que está completa y ejecuta lo que pone en ella. Si un atacante puede rellenar esa comanda a medias a su antojo, acaba dirigiendo la cocina.

¿Cómo consigue el atacante dar justo con ese instante? Las técnicas enumeradas en el aviso se basan en el formato multipart/form-data, que se utiliza para subir archivos:

• Las solicitudes multipart que no declaran una longitud de contenido utilizable pueden eludir la comprobación inicial de post_max_size.
• Una sola parte multipart puede contener un número ilimitado de encabezados.
• Los campos de archivo vacíos no cuentan para el límite de max_file_uploads, pero aun así crean matrices de metadatos de archivos.
• Los nombres de campo anidados multiplican el trabajo de construcción de matrices.

En resumen, el atacante diseña una solicitud que lleva a PHP al límite de su memoria justo en el peor momento. Como señala Wiz, PHP analiza las solicitudes multipart al inicio de la solicitud, antes de que haya terminado la inicialización normal de los módulos. Apache mod_php, por su parte, ejecuta la rutina de cierre de forma incondicional, aunque falle el inicio de la solicitud. Por eso la cadena completa puede culminar sin que se ejecute una sola línea del código de su aplicación. La RCE completa se ha confirmado a través de HTTP contra mod_php en una configuración prefork típica con varios workers, con los límites predeterminados de entrada y de memoria de PHP. PHP-FPM es otro caso, porque el proceso worker se termina cuando falla el inicio de la solicitud: el análisis del código fuente indica que FPM también puede verse afectado, pero todavía no se ha demostrado un exploit completo contra FPM para este fallo.

CVE-2026-109619: el “fantasma” de la solicitud anterior

Los procesos worker de PHP no atienden una sola solicitud y terminan: el mismo proceso sirve muchas solicitudes, una tras otra. PHP mantiene un estado global, como el estado de errores, de sesión, de objetos y de extensiones. El aviso explica que parte de ese estado lo conserva el worker, pero en realidad apunta a memoria que pertenece a una sola solicitud. Si una solicitud termina en un momento inesperado, esos punteros quedan atrás. La siguiente solicitud que llega al mismo worker toca ese estado obsoleto antes de que la inicialización normal haya podido restablecerlo. Se trata de un error clásico de use-after-free (uso de memoria ya liberada). Con una disposición del heap diseñada estratégicamente, puede conducir a la ejecución remota de código completa.

La analogía: en un hotel, la tarjeta del huésped anterior sigue funcionando y el nuevo huésped entra antes de que se haya limpiado la habitación. Las pertenencias del huésped anterior siguen dentro.

Este fallo tiene además una vertiente de fuga de datos. Según Wiz, la divulgación de memoria puede incluir contraseñas, tokens de autenticación, claves de API y certificados pertenecientes a otras solicitudes o al propio servidor. Una de las vías confirmadas es la función de progreso de carga de la sesión (session upload progress). Esta función está activada de forma predeterminada y la aplicación ni siquiera necesita llamar a session_start(): la gestión de la sesión puede entrar en acción antes de la inicialización normal de la sesión. El aviso también enumera, como segunda vía confirmada, la de la traza de errores fatales (fatal error backtrace) de PHP 8.5. La RCE a través del ciclo de vida de la sesión se ha confirmado tanto en mod_php como en PHP-FPM.

Una nota importante: según las descripciones oficiales de PHP, CVE-2026-109618 se refiere a datos a medio construir en el momento en que se agota la memoria, mientras que CVE-2026-109619 se refiere a un estado obsoleto que queda entre solicitudes. Algunas fuentes (entre ellas Wiz) asignan las técnicas de ataque a los números CVE de otra manera. En este artículo seguimos los avisos de seguridad de PHP en GitHub.

¿A quién afecta? Tabla de versiones

Da igual qué aplicación utilice. Wiz realizó sus demostraciones con las imágenes oficiales de WordPress, Drupal y Joomla. No porque estas plataformas sean vulnerables en sí mismas, sino porque todas funcionan con PHP. Actualizar el núcleo de WordPress o sus plugins no corrige esta vulnerabilidad; lo que hay que actualizar es el propio PHP, en el servidor.

Para dar una idea de la escala: según el análisis de Mallory basado en datos de Shodan, a 20 de octubre había en internet unos 884 000 servidores que anunciaban PHP 8.1 o una versión anterior en sus encabezados HTTP. Estas versiones no pueden recibir parches oficiales. Se trata de un recuento de encabezados, no de una cifra verificada de sistemas afectados, pero muestra lo larga que puede llegar a ser esa cola.

¿Qué hizo Partnerfy? Una defensa en 6 capas que no esperó al parche

Cuando se filtró la noticia de la vulnerabilidad, el panorama estaba clarísimo: el parche oficial aún tardaría horas y los atacantes ya se estaban preparando. Además, como todo el mundo intentaba descargar actualizaciones al mismo tiempo, los repositorios de paquetes sufrían una carga enorme y se bloqueaban. Por eso no nos conformamos con “esperemos al parche”. Construimos nuestra defensa capa por capa.

1. Respuesta temprana: una mitigación temporal horas antes del parche oficial

Nuestro equipo de DevOps siguió de cerca la noticia de la filtración y las primeras evaluaciones técnicas y, unas tres horas antes de que se publicara el parche oficial, desactivó session.upload_progress.enabled en todo el servidor. Esta es precisamente la mitigación temporal que PHP recomienda para CVE-2026-109619. Y no nos limitamos a cambiar el ajuste: lo cambiamos en el lugar correcto. El equipo de PHP exige que este ajuste se aplique en el nivel de la configuración principal (php.ini / configuración del servidor), no mediante ini_set() ni .user.ini. Nuestro cambio se hizo exactamente en ese nivel y se verificó en la configuración activa.

2. La capa perimetral: filtrar los ataques antes de que lleguen al servidor

Nuestro sitio web corporativo, partnerfy.co, y los proyectos que servimos tras Cloudflare están protegidos por la red perimetral (edge) de Cloudflare. A primera hora del 21 de octubre, Cloudflare desplegó de forma predeterminada su primer conjunto de reglas WAF contra los vectores conocidos de PHP2Shell. Gracias a ello, una parte significativa de las solicitudes sospechosas se filtra antes incluso de llegar a nuestros servidores. Como, según se ha informado, los atacantes han estado modificando sus cargas útiles para sortear las reglas iniciales, nunca consideramos que esta capa sea suficiente por sí sola; las demás capas están justo detrás.

3. Configuración de PHP reforzada: cortar el siguiente paso del atacante

Aplicamos a la configuración de PHP de nuestros servidores un refuerzo de la seguridad (hardening) mucho antes de esta crisis. Las funciones que ejecutan comandos del sistema (system, popen, proc_open y similares) están desactivadas, y también la inclusión remota de archivos (allow_url_include). Seamos francos: en teoría, una RCE a nivel de memoria podría sortear estas restricciones. Pero en el mundo real, lo primero que suele hacer un atacante es abrir una shell de comandos, descargar herramientas o dejar una web shell. Estas restricciones hacen que esos pasos críticos posteriores a la explotación sean mucho más difíciles y mucho más ruidosos. Y el ruido acaba delatando al atacante.

4. Aislamiento de cuentas: aunque se abra una puerta, el pasillo sigue cerrado

Cada cuenta de nuestros servidores funciona dentro de su propia “jaula” aislada en el sistema de archivos. Aunque el peor escenario se materialice en una cuenta, la capacidad del atacante para moverse lateralmente hacia los archivos y procesos de otras cuentas queda muy limitada. Que se rompa un eslabón no significa que se rompa toda la cadena.

5. Copias de seguridad para escenarios de desastre: preparados para lo peor

Antes de la ventana de aplicación del parche, hicimos copias de seguridad completas de las cuentas de nuestros servidores. El objetivo es sencillo: si algo sale mal, la pregunta no es “¿qué hemos perdido?”, sino “¿a qué punto de restauración limpio volvemos?”. Una buena estrategia de seguridad no consiste solo en bloquear ataques, sino también en poder volver rápidamente a un estado limpio aunque un ataque tenga éxito.

6. Parches, reinicios y búsqueda de indicios

A medida que los paquetes oficiales con parche llegan a los canales de las distribuciones, los aplicamos en nuestros servidores y luego reiniciamos todos los workers de PHP. El reinicio es innegociable: los workers antiguos que siguen en ejecución continúan usando el código antiguo. Como el parche introduce un nuevo límite estricto de memoria, también estamos revisando nuestros ajustes de memoria a la luz de ese cambio.

Al mismo tiempo, revisamos a fondo nuestros registros (logs) de acceso en busca de los indicios descritos por los investigadores. Un ejemplo concreto: unas tres horas después de la publicación del parche, desde una única dirección IP en la nube llegó a la raíz de nuestro sitio y a rutas como /api y /app una serie de solicitudes POST que se hacían pasar, una tras otra, por distintos bots de motores de búsqueda y de IA (CCBot, Amazonbot, ClaudeBot y otros). Todas y cada una de estas solicitudes fueron rechazadas con un 403 por la capa de seguridad del servidor antes de que pudieran llegar a nuestra aplicación. No podemos afirmar con certeza que fueran intentos de PHP2Shell, pero el momento y el patrón de identidades falsas coinciden con el escaneo masivo que comenzó tras el parche. En el momento de la publicación, no hemos detectado ningún indicio de compromiso en nuestros sistemas.

El enfoque de Partnerfy: nunca confiamos la seguridad a una sola cerradura. Filtrado en el perímetro, refuerzo en el servidor, aislamiento entre cuentas, copias de seguridad en la retaguardia y respuesta rápida en primera línea. Si se supera una capa, la siguiente ya está de guardia.

¿Qué debe hacer usted? Lista de comprobación paso a paso

1. Averigüe su versión de PHP

Si utiliza cPanel, puede comprobarla en la pantalla “MultiPHP Manager” o “Select PHP Version”; si tiene acceso al servidor, use php -v. Atención: la versión de PHP de la línea de comandos puede ser distinta de la que ejecuta su sitio web. El método más fiable es preguntar a su proveedor de hosting qué versión de PHP utiliza su sitio, o comprobarlo con una página temporal de phpinfo() y eliminarla inmediatamente después. Si tiene hosting compartido, la actualización le corresponde a su proveedor de hosting, no a usted. Pregúntele hoy mismo: “¿Han aplicado el parche de PHP2Shell?”.

2. Actualice y reinicie

Versiones objetivo: 8.5.12, 8.4.27, 8.3.36 u 8.2.35. En los paquetes de las distribuciones Linux, el número de versión puede ser distinto. Como también recomienda Debian, busque el número CVE en el registro de cambios (changelog) del paquete en lugar de fiarse del número de versión. Después de actualizar, reinicie Apache, PHP-FPM y cualquier worker de PHP de larga duración.

3. Si no puede actualizar de inmediato: mitigaciones temporales

Empecemos por la advertencia del propio proyecto PHP: estas medidas “reducen la exposición a determinadas vías de ataque, pero no hacen que una instalación sea segura”. La única solución completa es actualizar.

4. Si usa una versión antigua de PHP: la actualización no puede esperar

PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del proyecto PHP. Para un sitio que funcione con estas versiones, la verdadera solución no es un parche, sino un cambio de versión. Recuerde: el soporte de PHP 8.2 también termina el 31 de diciembre de 2026. Pasar hoy a 8.2.35 le sacará del apuro, pero si entra en 2027 con 8.2, no habrá parche para usted en la próxima crisis. Si su código heredado no funciona en versiones más recientes de PHP, es señal de que ha llegado el momento de un proyecto de modernización de software.

5. Busque indicios de compromiso

Indicios que los investigadores recomiendan comprobar después de aplicar el parche:

• Solicitudes multipart inusuales seguidas de inmediato por errores de límite de memoria o ráfagas de respuestas HTTP 500
• Cookies PHPSESSID inesperadamente grandes o mal formadas
• Reinicios o bloqueos inexplicables de workers de PHP
• Procesos php-fpm, httpd o apache2 que inician una shell, un intérprete o una herramienta de descarga (como sh, bash, curl o wget)
• Archivos nuevos en la raíz web (web shells), nuevas tareas cron, nuevas cuentas de usuario

Como el ataque se produce por debajo de la capa de aplicación, puede dejar muy pocos rastros en los registros de su aplicación. Revise los registros del servidor web y de PHP. Si algo parece sospechoso, aísle el servidor, conserve los registros y luego investigue. Dado que CVE-2026-109619 también puede provocar la divulgación de memoria, en caso de duda también conviene renovar las contraseñas de las bases de datos, las claves de API y los secretos de sesión.

La lección de esta crisis: la seguridad no es un producto, es un reflejo

PHP2Shell ha dejado tres cosas muy claras. Primero, por muy limpia que sea su aplicación, su seguridad nunca será mayor que la de la plataforma sobre la que funciona. Segundo, en la era de la IA, la distancia entre parche y exploit se ha reducido a horas. Tercero, cuando hay filtraciones y rupturas de embargo, el enfoque de “nos ceñimos al calendario oficial” se derrumba. Ganan los equipos que leen la noticia en la primera hora, aplican la mitigación temporal, tienen listas sus copias de seguridad y nunca confían su defensa a una sola cerradura.

En Partnerfy, este reflejo viene de serie en nuestros servicios de hosting gestionado y administración de servidores, ciberseguridad y copias de seguridad y recuperación ante desastres. Como empresa de software con sede central en Sakarya y oficinas en Turquía, Alemania, Rusia e Irlanda, podemos ayudarle a determinar con qué versión de PHP funciona su sitio, si está expuesto a PHP2Shell y cómo prepararse para el fin del soporte de PHP 8.2. Póngase en contacto con nosotros y revisemos juntos su sitio.

Fuentes

• PHP: anuncio de seguridad del 21 de octubre de 2026
• GHSA-w8hw-w9fx-j79w: CVE-2026-109618 (RCE mediante corrupción por OOM)
• GHSA-6wmf-4rv5-p3rp: CVE-2026-109619 (RCE mediante estado global obsoleto)
• The PHP Foundation: la versión de seguridad de PHP de hoy y cómo estamos reforzando la seguridad de PHP
• Wiz: investigación sobre PHP2Shell
• Help Net Security: corregidas las vulnerabilidades PHP2Shell
• The Hacker News: PHP publica parches de emergencia para dos fallos críticos

Preguntas frecuentes