PHP2Shell: lo que se sabe sobre las fallas críticas de PHP y cómo proteger sus servidores

El miércoles 21 de octubre de 2026, el proyecto PHP publicó una actualización de emergencia para corregir dos vulnerabilidades críticas que, juntas, pasaron a conocerse como PHP2Shell. Las fallas permiten que un atacante, sin usuario ni contraseña, ejecute código en el servidor y lea partes de la memoria que pueden contener contraseñas, tokens de acceso y claves de API.

El alcance es enorme. PHP es el lenguaje detrás de cerca del 70% de los sitios cuya tecnología de servidor se conoce, según W3Techs, incluidas plataformas como WordPress, Drupal, Joomla y Magento. Y, a diferencia de una falla en un plugin o en un sistema específico, el problema está en el propio PHP: actualizar el CMS, el tema o los plugins no lo resuelve.

En este post reunimos lo que se sabe hasta ahora, explicamos las fallas en un lenguaje accesible y enumeramos lo que los equipos de tecnología y los responsables de sitios web deben hacer.

Qué es PHP2Shell

PHP2Shell es el nombre que recibe el conjunto de dos vulnerabilidades registradas como CVE-2026-109618 y CVE-2026-109619. Ambas recibieron una puntuación de 9,2 sobre 10 en la escala de gravedad CVSS (versión 4.0), lo que las sitúa en el rango crítico. El nombre hace referencia al objetivo de quien explota la falla: obtener un shell, es decir, la capacidad de ejecutar comandos en el servidor.

Según la PHP Foundation, las dos fallas están en partes de PHP que prácticamente toda solicitud utiliza: la gestión de memoria y el manejo de errores. Eso es lo que hace que el problema sea tan amplio.

CVE-2026-109618: cuando la memoria se agota en el peor momento

Cada vez que alguien accede a una página hecha en PHP, el servidor arma una serie de estructuras internas para procesar esa solicitud. La primera falla ocurre cuando la memoria disponible se agota en medio de ese proceso. PHP interrumpe el procesamiento, pero la etapa de limpieza que viene después trata los datos aún incompletos como si fueran válidos.

Un atacante puede provocar esa falta de memoria a propósito, por ejemplo con solicitudes de envío de formularios y archivos (multipart) diseñadas para consumir memoria sin superar los límites aparentes de la configuración. Así corrompe la memoria del proceso y puede llegar a la ejecución de código.

CVE-2026-109619: el "estado fantasma" entre solicitudes

Los servidores PHP suelen reutilizar el mismo proceso (worker) para atender varias solicitudes seguidas. La segunda falla ocurre cuando una solicitud termina de forma abrupta, por un error fatal o por falta de memoria, y deja referencias a un área de memoria que ya fue liberada. La siguiente solicitud atendida por el mismo proceso puede usar esas referencias antes de que PHP las reinicie.

Este tipo de error, conocido como use-after-free (uso de memoria después de liberarla), permite tanto leer datos que pertenecían a otra solicitud como ejecutar código. Uno de los caminos confirmados pasa por la función de seguimiento del progreso de carga en sesiones (session.upload_progress), que viene activada por defecto en PHP.

Cuál es el impacto práctico

Si se explota con éxito, la vulnerabilidad permite:

Ejecutar código en el servidor con los permisos del usuario que ejecuta el servidor web, sin ninguna autenticación.
Leer la memoria del proceso PHP, que puede contener contraseñas de bases de datos, tokens de autenticación y claves de API.
A partir de ahí, instalar accesos ocultos, modificar el sitio, robar datos o usar el servidor como punto de partida para atacar otros sistemas de la red.

La explotación no es trivial: depende de la versión, de las extensiones instaladas, de la configuración del servidor y del comportamiento de la aplicación. Pero los investigadores ya demostraron ataques funcionales, y es probable que las técnicas se vuelvan más accesibles con el tiempo.

Quién está en riesgo

Según el comunicado oficial de PHP, toda instalación de PHP que atiende solicitudes web está en riesgo, incluidas:

Apache con mod_php: el escenario de mayor riesgo. Hay una explotación demostrada en la que una solicitud sin autenticación desencadena el ataque incluso antes de que se ejecute el código de la aplicación.
PHP-FPM: el modelo más común en servidores con Nginx. La explotación se validó en condiciones específicas de la aplicación.
php-cgi, FrankenPHP y LiteSpeed.

El código vulnerable existe desde PHP 5.4, lanzado en 2012. En la práctica, esto incluye prácticamente todas las versiones en uso hoy.

La empresa de seguridad Calif, una de las responsables del descubrimiento, afirma haber confirmado ejecución remota de código sin autenticación en versiones específicas de WordPress, Drupal, Joomla y Magento. Esto no significa que esas plataformas tengan una falla propia: se ven afectadas porque funcionan sobre el PHP vulnerable.

Versiones corregidas

PHP 8.5: actualizar a la 8.5.12.
PHP 8.4: actualizar a la 8.4.27.
PHP 8.3: actualizar a la 8.3.36.
PHP 8.2: actualizar a la 8.2.35. Esta rama tiene soporte solo hasta el 31/12/2026.
PHP 7.4, 8.0 y 8.1: no hay nueva versión oficial, solo una corrección mínima publicada en el código fuente.
PHP 5.4 a 7.3: no hay corrección. Son versiones sin soporte.

Algunas observaciones importantes:

Las distribuciones Linux y los proveedores de soporte extendido recibieron las correcciones con antelación. En los paquetes de distribución, la corrección puede llegar manteniendo el número de versión anterior. Por eso, lo correcto es consultar el boletín de seguridad del proveedor (Ubuntu, Debian, Red Hat y otros), y no solo el número de versión.
Para PHP 7.4, 8.0 y 8.1, el equipo de PHP publicó correcciones mínimas en el código fuente, dirigidas a quienes compilan PHP por su cuenta. Aun así, la recomendación es migrar a una versión con soporte.
PHP 8.2 deja de recibir correcciones de seguridad el 31 de diciembre de 2026. Quien usa esta rama debe planificar la migración desde ya.

Cronología

Agosto de 2026: investigadores de Calif y de Wiz, trabajando de forma independiente y con el apoyo de modelos de inteligencia artificial, encuentran las fallas y las reportan al equipo de seguridad de PHP.
17 de octubre: Amazon registra el primer intento de explotación en sus servidores señuelo (honeypots), cuatro días antes de la divulgación.
20 de octubre: los identificadores de las fallas se filtran en internet, junto con un video de demostración publicado por error. PHP publica un aviso anticipado, y CERT-EU, el centro de respuesta a incidentes de la Unión Europea, emite una alerta.
21 de octubre, madrugada: Cloudflare activa reglas de firewall de aplicaciones web (WAF) contra las formas de ataque conocidas, incluso para los clientes del plan gratuito.
21 de octubre, 14:00 UTC: PHP lanza las versiones corregidas, un día antes de lo previsto debido a la filtración.
22 de octubre: el CTIR Gov, centro de prevención y respuesta a incidentes cibernéticos del gobierno federal de Brasil, orienta a los organismos de la administración pública a actualizar PHP de inmediato.

¿La falla ya está siendo explotada?

Sí. Diversas empresas de seguridad informan intentos de ataque:

Amazon afirma que PHP2Shell ya se explota de forma amplia y recomienda investigar los sistemas expuestos a partir del 17 de octubre.
Hadrian informó explotación a gran escala horas antes de la corrección, en su mayoría por el camino del progreso de carga en sesiones.
Cloudflare, Patchstack y watchTowr también registraron intentos.

Según una estimación citada por Tenable, más de 1,3 millones de servidores accesibles desde internet pueden ser vulnerables.

Circulan en internet códigos que prometen explotar las fallas. La PHP Foundation informó que, en el momento del lanzamiento de las correcciones, ninguno de los que analizó funcionaba realmente. Pero atención: los códigos de explotación no verificados pueden contener malware y no deben ejecutarse en ningún entorno de la empresa.

El papel de la inteligencia artificial en el descubrimiento

PHP2Shell también llama la atención por la forma en que se encontró. PHP atribuyó el descubrimiento a investigadores de Calif, Wiz y OpenAI, entre otros, y tanto Calif como Wiz afirman haber usado modelos de inteligencia artificial para analizar el código de PHP.

Wiz calificó las fallas como "entre las vulnerabilidades más graves descubiertas en PHP y, posiblemente, en la historia del software". OpenAI, por su parte, afirmó que PHP2Shell está entre varias vulnerabilidades relevantes que encontró y que espera un aumento marcado de hallazgos similares en los próximos meses.

Esto tiene dos caras. La IA ayuda a los defensores a encontrar fallas antiguas que pasaron años inadvertidas en un código usado por millones de sistemas. Al mismo tiempo, la misma tecnología acelera el trabajo de quienes quieren atacar: entre la filtración de los primeros datos y los primeros intentos de explotación masiva pasaron pocas horas.

La ventana entre la divulgación de una falla y los ataques es cada vez más corta, y la capacidad de actualizar sistemas con rapidez dejó de ser un diferencial para convertirse en una necesidad. El tema se relaciona con otra discusión que trajimos recientemente al blog: quién fiscaliza la inteligencia artificial.

Qué hacer ahora

1. Descubra dónde se está ejecutando PHP

Haga una lista de todos los servidores, sitios, sistemas internos y servicios que usan PHP, incluidos los olvidados: sitios antiguos de campañas, entornos de pruebas expuestos a internet, paneles administrativos e intranets.

En alojamiento compartido o administrado, la actualización de PHP suele ser responsabilidad del proveedor. Contáctelo y pida la confirmación de que la corrección fue aplicada.

Para verificar la versión en un servidor:

php -v

La versión que muestra la terminal puede ser diferente de la que usa el servidor web. Revise también los paquetes instalados, que incluyen PHP-FPM y el módulo de Apache:

# Ubuntu y Debian
dpkg -l | grep php

# Red Hat, Rocky Linux, AlmaLinux y similares
rpm -qa | grep php

2. Actualice y reinicie

Actualice a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete corregido de su distribución. Después, reinicie todos los procesos de PHP (PHP-FPM, Apache o equivalente). Sin el reinicio, los procesos antiguos siguen ejecutándose con el código vulnerable en memoria.

Si usa el repositorio comunitario rpms.remirepo.net, el propio PHP recomienda migrar a los paquetes de la distribución o compilar desde el código fuente, porque el repositorio no tendría la actualización disponible el día del lanzamiento.

3. Si no puede actualizar ahora, reduzca la exposición

PHP es directo: no existen mitigaciones completas, y actualizar es la única opción segura. Las medidas siguientes reducen caminos de ataque conocidos, pero no hacen que una instalación sea segura. Úselas solo como puente hasta la actualización.

; Bloquea el camino confirmado por el progreso de carga en sesiones (CVE-2026-109619)
session.upload_progress.enabled = 0

; Solo en PHP 8.5: bloquea el camino por el backtrace de error fatal (CVE-2026-109619)
fatal_error_backtraces = 0

; Reduce el tamaño máximo de las solicitudes (CVE-2026-109618)
; 8M para aplicaciones sin carga de archivos, 32M si hay carga de archivos
post_max_size = 8M

Otros cuidados recomendados por PHP y por los organismos de respuesta a incidentes:

Aplique la configuración en php.ini, en el pool de PHP-FPM o en la configuración del servidor web. No use ini_set() ni el archivo .user.ini, que entran en acción demasiado tarde.
Para la CVE-2026-109618, PHP sugiere memory_limit=-1, aplicado de forma que la aplicación no pueda sobrescribirlo (por ejemplo, con php_admin_value). La medida aumenta el riesgo de agotamiento de recursos, así que combínela con límites de memoria por contenedor o cgroup.
Limite, en el servidor web o en el proxy, el tamaño de las solicitudes y el número de campos, encabezados y partes de carga. Bloquee las solicitudes multipart donde la aplicación no recibe archivos.
En PHP-FPM, pm.max_requests = 1 hace que cada proceso atienda una sola solicitud, lo que elimina la reutilización de estado, a costa del rendimiento.
Reinicie todos los procesos después de cualquier cambio.
Coloque las aplicaciones detrás de un WAF con reglas para PHP2Shell o restrinja el acceso desde internet hasta la corrección, como recomiendan el CTIR Gov y CERT-EU.

4. Verifique si hubo una intrusión

Como hubo intentos de ataque incluso antes de la corrección, actualizar no basta para quien estuvo expuesto. Conviene:

Revisar los registros de acceso a partir del 17 de octubre, en busca de volúmenes inusuales de solicitudes multipart, errores de falta de memoria y reinicios inesperados de procesos.
Buscar archivos PHP nuevos o modificados en directorios públicos, una señal típica de webshells (archivos que le dan al atacante control remoto del servidor).
Cambiar contraseñas, tokens y claves de API que estaban accesibles para PHP en servidores expuestos, ya que la falla permite leer la memoria del proceso.

5. Planifique la salida de versiones sin soporte

Las versiones sin soporte no reciben correcciones y seguirán siendo vulnerables a esta y a las próximas fallas. Si su aplicación aún funciona con PHP 8.1 o anterior, PHP2Shell es el argumento que faltaba para priorizar la migración. Y PHP 8.2 estará en la misma situación el 31 de diciembre de 2026.

Lecciones para quienes desarrollan y mantienen sistemas

Episodios como PHP2Shell, al igual que Log4Shell en 2021, refuerzan algunos principios que valen para cualquier tecnología:

El inventario es la base de la seguridad. No se puede proteger lo que no se sabe que existe.
La actualización necesita un proceso. Una rutina, responsables y ventanas de mantenimiento definidas marcan la diferencia entre corregir en horas o en semanas.
Defensa en capas. Un WAF, la segmentación de red, los privilegios mínimos para el usuario del servidor web y los secretos guardados fuera del código reducen el daño cuando aparece una falla.
Las versiones sin soporte son deuda de seguridad. Cada mes de retraso en la migración aumenta el riesgo.

Para profundizar, lea también nuestros posts sobre seguridad de la información en plataformas web y alojamiento seguro en AWS.

Si su empresa necesita apoyo para mapear aplicaciones en PHP, planificar la actualización o revisar la seguridad de sus sistemas, hable con nosotros.

Fuentes:

PHP: Security advisory: critical remote code execution vulnerabilities, update now (en inglés), 21 de octubre de 2026.
PHP en GitHub: boletines técnicos GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp (en inglés).
Tenable: php2shell (CVE-2026-109618, CVE-2026-109619): frequently asked questions (en inglés).
SecurityWeek: PHP2Shell patches land as first exploitation attempts hit sensors (en inglés).
Qualys: Two critical PHP flaws could hand attackers your web servers (en inglés).
Convergência Digital: Governo manda fazer atualização urgente e até tirar do ar sites por conta das vulnerabilidades no PHP (en portugués), 22 de octubre de 2026.

PHP2Shell: lo que se sabe sobre las fallas críticas de PHP y cómo proteger sus servidores.