PHP2Shell: la falla crítica de PHP que permite tomar el control de un servidor (y qué hacer hoy)

En corto: PHP2Shell son dos fallas críticas en el motor de PHP (CVE-2026-109618 y CVE-2026-109619, calificación 9.2 de 10) que permiten a un atacante, sin usuario ni contraseña, ejecutar código en tu servidor con una sola petición web manipulada. Afectan a cualquier sitio o sistema hecho en PHP, incluidos WordPress, Drupal y Joomla, y la única solución completa es actualizar PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 y reiniciar sus procesos. Si tu sistema corre PHP 8.1 o anterior, el problema es mayor: no hay versión oficial que lo corrija.

PHP mueve cerca del 69% de los sitios web cuyo lenguaje de servidor se conoce, según W3Techs. Por eso, cuando aparece una falla en el motor mismo y no en un plugin, la exposición es enorme. Esta guía explica qué pasó, qué tan grave es y qué tiene que hacer tu equipo, o tu proveedor, esta misma semana.

Qué es PHP2Shell

PHP2Shell es el nombre que la comunidad de seguridad le dio a dos vulnerabilidades corregidas por el proyecto PHP el 21 de octubre de 2026:

• CVE-2026-109618, corrupción por falta de memoria. Cuando PHP se queda sin memoria a la mitad de preparar una petición, deja datos internos a medio construir. Después, la limpieza de la petición los trata como si fueran válidos y abre un camino para ejecutar código.
• CVE-2026-109619, estado global «viejo». Información de una petición sobrevive a la memoria que ya se liberó. Si el mismo proceso de PHP atiende la siguiente petición, puede usar esos restos antes de reiniciarlos. Eso permite leer memoria del servidor y, en el peor caso, ejecutar código.

Las encontró primero el equipo de investigación de Calif, que las reportó a PHP en agosto, y de forma independiente Wiz Research. La publicación coordinada estaba prevista para el 22 de octubre, pero los detalles se filtraron en redes dos días antes y PHP tuvo que adelantar la publicación del parche.

Por qué es tan grave

Hay cuatro razones que la ponen por encima de una vulnerabilidad típica:

1. Ocurre antes de que corra tu aplicación. El ataque viaja dentro de la petición HTTP y PHP la procesa antes de ejecutar tu código. Tu login, tu validación y tus permisos no alcanzan a intervenir. Como resume Datadog Security Labs, cualquier script PHP expone el camino vulnerable, incluso uno que solo imprime una respuesta.
2. No requiere autenticación ni interacción. Basta con que el servidor sea alcanzable desde internet.
3. Afecta a todas las formas de correr PHP en web: Apache con mod_php, PHP-FPM (el más común con Nginx), php-cgi, LiteSpeed y FrankenPHP. PHP considera que el riesgo más alto está en mod_php, donde ya se demostró el ataque completo.
4. También filtra memoria. Además de ejecutar código, una de las rutas permite leer la memoria del proceso. Ahí puede haber contraseñas de base de datos, tokens, llaves de API y certificados.

Wiz demostró la ejecución remota sin autenticación contra las imágenes oficiales de WordPress, Drupal y Joomla. Censys contó unos 42 millones de servicios PHP expuestos a internet, de los cuales poco más de 10 millones se habían parchado en los días siguientes a la publicación.

Actualizar WordPress o sus plugins no te protege. La falla está en PHP, una capa más abajo.

Cronología

Fecha (2026)	Qué pasó
1 y 11 de agosto	Calif encuentra las fallas y las reporta al equipo de seguridad de PHP.
17 de octubre	Los honeypots de AWS registran un intento de explotación, cuatro días antes del parche.
20 de octubre	Se filtran los detalles en redes. PHP anuncia una publicación de emergencia.
21 de octubre	PHP publica 8.5.12, 8.4.27, 8.3.36 y 8.2.35, más parches en código fuente para 7.4, 8.0 y 8.1. watchTowr reporta explotación en sus honeypots.
23 de octubre	PHP publica un aviso informativo de una falla relacionada (CVE-2026-115560) que requiere una configuración poco común.
26 de octubre	La CISA de Estados Unidos agrega ambas fallas a su catálogo de vulnerabilidades explotadas y da a las agencias federales hasta el 29 de octubre para corregirlas. PHP también actualiza sus versiones para Windows por otra falla, en la librería Brotli (CVE-2026-111497).
29 de octubre	Unit 42 de Palo Alto Networks confirma una cadena real: PHP2Shell combinado con una falla del kernel de Linux para obtener acceso total en equipos de administración expuestos a internet.

¿Ya la están explotando?

Sí hay actividad real, aunque el panorama todavía se está aclarando:

• Hay intentos confirmados desde antes del parche (AWS) y en honeypots de varias empresas. La CISA la considera explotada, y en su criterio cuentan tanto los intentos como los ataques exitosos.
• Hay al menos una cadena de ataque confirmada de forma independiente, la que documentó Unit 42 el 29 de octubre.
• No hay evidencia pública de compromisos masivos al cierre de octubre. Varias empresas de seguridad reportaron miles de intentos fallidos, y algunas publicaron y luego retiraron atribuciones de ataques exitosos.

La lectura correcta no es «no pasa nada». Explotar estas fallas de forma confiable es técnicamente difícil, pero ya hay código público, la ventana entre la filtración y el parche fue de horas, y quien ya entró a un servidor no suele avisar. Trátala como urgente.

Versiones afectadas y corregidas

Rama de PHP	¿Afectada?	Qué hacer
8.5	Anteriores a 8.5.12	Actualizar a 8.5.12
8.4	Anteriores a 8.4.27	Actualizar a 8.4.27
8.3	Anteriores a 8.3.36	Actualizar a 8.3.36
8.2	Anteriores a 8.2.35	Actualizar a 8.2.35 (esta rama termina su soporte el 31 de diciembre de 2026)
7.4, 8.0 y 8.1	Todas	Sin versión oficial: usar el paquete parchado de tu distribución o proveedor de soporte extendido, o migrar
7.3 o anterior (incluido PHP 5)	Todas	Sin corrección: migrar o aislar de internet

El problema de fondo es el software viejo. Según W3Techs, más de un tercio de los sitios con PHP todavía corren las versiones 5 o 7, que ya no reciben versiones oficiales.

Ojo con dos trampas:

• La versión de la terminal no siempre es la que sirve tu sitio. php -v muestra la versión de línea de comandos, que puede ser distinta de la de PHP-FPM o mod_php. Revisa la que atiende las peticiones web.
• Las distribuciones de Linux parchan sin cambiar el número de versión. Ubuntu, Debian o Red Hat pueden incluir la corrección en una versión que «parece» vieja. Confirma en el historial de cambios del paquete que mencione CVE-2026-109618 y CVE-2026-109619.

Qué hacer hoy: lista de acciones

1. Inventario

Haz la lista de todo lo que corre PHP en tu empresa, no solo el sitio principal. Incluye micrositios y landings de campañas viejas, el WordPress del blog, sistemas internos, paneles de hosting como cPanel o Plesk, intranets, herramientas que alguien instaló «para probar» y equipos o software de terceros que traen PHP adentro. Lo que no está en la lista no se parcha.

2. Prioriza lo expuesto a internet

Empieza por los servidores públicos y, dentro de ellos, por los que usan Apache con mod_php.

3. Actualiza y reinicia

Instala la versión corregida de tu rama y reinicia todos los procesos de PHP: el servicio de PHP-FPM, Apache o el contenedor. Si no reinicias, los procesos viejos siguen corriendo el código vulnerable.

Para confirmar qué versión atiende de verdad tus peticiones web, una forma rápida es crear un archivo temporal con <?php phpinfo();, abrirlo una vez y borrarlo de inmediato, porque expone información sensible del servidor.

4. Si estás en hosting compartido

No puedes parchar PHP tú mismo, pero sí puedes:

• Preguntarle por escrito a tu proveedor si ya aplicó la corrección de CVE-2026-109618 y CVE-2026-109619.
• Cambiar la versión de PHP de tu sitio desde el panel a una rama soportada (8.3 o 8.4 son buenas opciones) y probar que todo funcione.
• Si tu sitio solo funciona con PHP 7 o 5, tomarlo como la señal definitiva para modernizarlo.

5. Si no puedes actualizar hoy: mitigaciones temporales

El aviso oficial de PHP es claro: estas medidas reducen la exposición, no la eliminan. Aplícalas solo como puente mientras actualizas.

; En php.ini o en la configuración del pool de PHP-FPM.
; No sirve con ini_set() ni con .user.ini: debe cargarse antes de procesar la petición.
session.upload_progress.enabled = 0

; Límites bajos de tamaño de petición (32M si necesitas subir archivos; 8M si no)
post_max_size = 32M
upload_max_filesize = 16M

; Solo en PHP 8.5
fatal_error_backtraces = 0

Después de cambiarlo, reinicia todos los procesos de PHP. Además:

• Limita el tamaño de las peticiones también en Nginx, Apache o tu proxy, incluidas las que no traen un Content-Length válido.
• Pon el servidor detrás de un WAF (Cloudflare, AWS WAF, Akamai u otro) con las reglas para PHP2Shell activas. Los principales proveedores ya las publicaron.
• Si es un sistema viejo que no se puede actualizar, sácalo de internet o déjalo accesible solo por VPN.

El aviso de PHP menciona otra medida (memory_limit=-1), pero quita el tope de memoria de PHP. Úsala solo si ya tienes límites de memoria por contenedor o cgroup que maten únicamente al proceso afectado.

6. Busca señales de que ya entraron

Si tu servidor estuvo expuesto con una versión vulnerable, revisa:

• Procesos de PHP que lanzan otros programas. Un php-fpm, php-cgi, apache2 o httpd que ejecuta sh, bash, cmd.exe, powershell, curl, wget, python o perl es la señal más directa. Un proceso de PHP nunca debería abrir una terminal mientras procesa una subida de archivos.
• Errores raros en los logs. Fíjate en mensajes de memoria agotada del tipo «Allowed memory size … exhausted» que aparecen en «Unknown on line 0», es decir, antes de que corra cualquier script. También en caídas de procesos (segmentation fault) y en ráfagas de errores 500.
• Peticiones extrañas. Busca subidas de archivos con un campo PHP_SESSION_UPLOAD_PROGRESS en sitios que no lo usan, cuerpos muy grandes o con cientos de campos, y cookies PHPSESSID anormalmente largas o con datos binarios.
• Rastros de persistencia. Archivos nuevos en la carpeta pública (sobre todo .php en carpetas de subidas), tareas programadas (cron) nuevas, usuarios nuevos y conexiones de salida que no reconoces.

Si encuentras algo: aísla el servidor, guarda los logs antes de tocar nada y no lo «limpies» a mano sin una revisión forense.

7. Rota tus secretos

Como una de las rutas permite leer la memoria del proceso, en cualquier servidor que estuvo expuesto sin parche conviene cambiar las contraseñas de base de datos, las llaves de API, los tokens y los certificados que usaba esa aplicación, aunque no veas señales de intrusión.

La lección para dirección

PHP2Shell no es la primera ni será la última falla de este tipo. Los propios investigadores advierten que el patrón de fondo puede repetirse en otras partes del motor. Lo que separa a una empresa que lo resuelve en una tarde de una que lo descubre meses después casi nunca es la tecnología. Son tres hábitos:

1. Saber qué tienes. Un inventario vivo de sistemas, versiones y responsables.
2. Poder actualizar sin miedo. Si actualizar PHP «rompe todo», el problema ya existía: es deuda técnica que cobra intereses.
3. Tener un plan para lo viejo. Todo sistema que ya no recibe parches es una puerta abierta con fecha de caducidad vencida.

Cómo te ayudamos en GEDX

En GEDX usamos la IA como copiloto para acelerar lo repetitivo, como inventariar servidores, revisar configuraciones, cruzar versiones contra avisos de seguridad y buscar señales en logs. Las decisiones las toma un ingeniero que entiende tu operación. Hacemos hardening de servidores y aplicaciones, modernización de sistemas heredados y revisiones con Centinela, nuestro escáner de vulnerabilidades con reporte ejecutivo.

Si no sabes con certeza qué versión de PHP corre tu sitio, o si tienes sistemas en PHP 7 o anterior, escríbenos y revisamos contigo tu exposición y el camino más corto para cerrarla.

---

Fuentes

• PHP · Security advisory: critical RCE vulnerabilities y notas de versión (21-oct-2026)
• PHP 8.4.27 · Notas de la versión de seguridad
• watchTowr · CVE-2026-109618: FAQ y cronología
• Datadog Security Labs · PHP2Shell: detección, análisis y remediación
• Unit 42 (Palo Alto Networks) · Threat Brief, actualizado al 29-oct-2026
• Huntress · Rapid Response: php2shell
• Varonis · PHP2Shell: One Upload, Full Server
• Akamai · Understanding PHP2Shell
• The Record · CISA agrega las fallas de PHP a su catálogo KEV
• W3Techs · Uso de PHP en sitios web (noviembre 2026)