PHP2Shell (CVE-2026-109618 y CVE-2026-109619): qué deben hacer ahora las empresas que usan PHP

Un técnico con un portátil trabajando en un rack de servidores

El 21 de octubre de 2026, el proyecto PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades que «pueden permitir la ejecución remota de código sin autenticación». Dicho claramente: cualquiera que pueda enviar una petición HTTP a tu sitio web puede llegar a ejecutar su propio código en tu servidor. No necesita ninguna contraseña, y en algunas configuraciones el ataque funciona antes de que tu aplicación haya ejecutado una sola línea. Los dos fallos se conocen como PHP2Shell, y PHP les asigna a ambos una puntuación de 9,2 (CVSS 4.0, en una escala de 10).

Esta guía es para quienes tienen que actuar: propietarios de sitios web y tiendas online en PHP, responsables de TI y cualquiera que tenga un proveedor que gestione PHP en su nombre. Se escribió el 22 de octubre de 2026, el día después de la publicación, a partir de los propios avisos del proyecto PHP, las recomendaciones de las agencias nacionales de ciberseguridad y las cifras que han publicado los proveedores. Donde las fuentes no coinciden, lo decimos.

En resumen

Actualiza el propio PHP y después reinícialo. Actualizar WordPress, Drupal, Laravel o un plugin no corrige esto. El fallo está en PHP, por debajo de tu aplicación.
Toda instalación de PHP que sirva peticiones web está dentro del alcance, según PHP: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera Apache con mod_php la configuración de mayor riesgo.
Casi la mitad de los sitios web en PHP usan una rama para la que el proyecto PHP ya no publica versiones (según nuestra lectura de los datos de W3Techs, más abajo). Para ellos no hay ningún paquete oficial que instalar.
Los ajustes y los cortafuegos dan tiempo, no seguridad. PHP enumera medidas provisionales y dice que «no hacen que una instalación sea segura».
Si no puedes parchear hoy, las agencias de Estados Unidos, el Reino Unido y la UE dan el mismo consejo: desconecta el sistema de internet hasta que puedas.

Qué ha pasado, por orden

19 de agosto de 2026. Investigadores de Wiz encuentran el primero de los fallos, según su divulgación, y los comunican al equipo de seguridad de PHP el 24 de agosto. Los avisos de PHP reconocen también a investigadores de varias empresas más.
20 de octubre. Los números CVE se filtran en internet dos días antes de la divulgación prevista. PHP adelanta un día su publicación, al 21 de octubre a las 14:00 UTC, y pide a todo el mundo que se prepare.
21 de octubre, 03:02 UTC. Cloudflare activa reglas de cortafuegos para todos los clientes que usan su WAF, incluido el plan gratuito. Más tarde informa de que ha «observado tráfico de ataque dirigido a nuestros clientes» y de que ha visto a atacantes «modificando el payload del ataque para intentar eludir nuestras protecciones».
21 de octubre, hacia las 14:00 UTC. PHP publica las correcciones y su aviso. Ese mismo día, CISA en Estados Unidos, el NCSC del Reino Unido, CERT-EU y una declaración conjunta de la Comisión Europea, ENISA, CERT-EU, Europol y los CSIRT nacionales de la UE piden todos a las organizaciones que parcheen de inmediato.

¿Cómo de grave es?

Hay tres cosas que lo distinguen del parche mensual habitual.

Al atacante le basta con una petición. No necesita iniciar sesión, y nadie tiene que hacer clic en ningún enlace. El aviso de PHP describe un exploit demostrado contra Apache con mod_php «en el que una petición sin autenticar puede desencadenar el ataque antes de que se ejecute ningún código de la aplicación». Wiz demostró ataques contra versiones actuales de WordPress, Drupal y Joomla, y señala que «incluso una simple aplicación “Hello World” que se ejecute en una versión de PHP afectada puede ser vulnerable». El código ejecutado de esta forma tiene los permisos de la cuenta del servidor web, que en la mayoría de los sitios puede leer la configuración de la aplicación: la contraseña de la base de datos, las claves de API y las credenciales de correo y de pago. Para el segundo fallo, CVE-2026-109619, PHP confirma además la divulgación de memoria: datos de la memoria del servidor que se filtran al exterior, incluso sin llegar a la ejecución completa de código.

La base instalada es enorme. Según W3Techs, PHP se usa en el 69,3% de los sitios web cuyo lenguaje del lado del servidor se conoce (cifras del 22 de octubre de 2026). Unit 42, de Palo Alto Networks, contabiliza más de 22,6 millones de instancias expuestas potencialmente vulnerables, según su propio escaneo de internet, e informa de que al menos un gobierno europeo desconectó su sitio web por precaución.

El desarrollo de exploits avanza rápido. CERT-EU informa de que las primeras pruebas de concepto «han empezado a circular». La empresa de seguridad watchTowr dice que sus honeypots han registrado explotación desde el 21 de octubre. Cloudflare informa de tráfico de ataque. Y Wiz dice que sus investigadores usaron modelos de IA en todo el proceso, de modo que un solo investigador hizo en una semana lo que «a un equipo de primer nivel mundial le habría llevado meses». Los atacantes que adapten un exploit a tu versión de PHP tienen las mismas herramientas.

Para ser justos, también hay otra cara: cuando CISA publicó su alerta el 21 de octubre, no había observado explotación, y ninguno de los dos fallos figuraba aún en su catálogo Known Exploited Vulnerabilities (vulnerabilidades explotadas conocidas). Red Hat califica el problema de «importante» y no de crítico, porque un servidor estándar con Red Hat Enterprise Linux ejecuta PHP-FPM, donde la explotación es más difícil. Más difícil no significa imposible: PHP confirma que una de las vías del segundo fallo también funciona en PHP-FPM. Nada de esto cambia lo que debes hacer. Solo cambia el margen de aviso que vas a tener.

¿Qué versión usas? Las cifras

W3Techs también publica qué versiones de PHP usan los sitios web, contando los sitios que revelan su versión. Juntando sus dos tablas del 22 de octubre de 2026:

Rama de PHP	Cuota de los sitios web en PHP	Corrección del proyecto PHP
8.3, 8.4, 8.5	en torno al 34%	Sí: 8.3.36, 8.4.27, 8.5.12
8.2	en torno al 18%	Sí: 8.2.35. Pero la propia 8.2 llega al fin de su vida el 31 de diciembre de 2026
8.0, 8.1	en torno al 14%	Ninguna versión. 8.0 y 8.1: solo backport en código fuente
7.x	26,9%	Ninguna versión. 7.4: solo backport en código fuente; 7.3 y anteriores: nada
5.x y anteriores	7,8%	Nada

Así que en torno al 48% de los sitios web en PHP usan una rama para la que el proyecto PHP no publica ninguna versión corregida, y otro 18% recibe ahora su corrección y pierde el soporte dentro de diez semanas.

Dos salvedades. W3Techs solo ve los sitios que muestran su versión. Y una distribución de Linux puede haber parcheado por su cuenta una rama antigua: Ubuntu lo ha hecho, como verás más abajo. El número de versión por sí solo no te dice si estás protegido. Te lo dice la versión del paquete de tu proveedor.

Paso 1: localiza todo el PHP que usas

No puedes parchear lo que no tienes inventariado, y PHP se esconde bien. El NCSC del Reino Unido pide a las organizaciones que localicen todos sus sistemas con PHP, empezando por los expuestos a internet, y añade: «no limitar la búsqueda a las versiones obsoletas de PHP». La declaración conjunta de la UE advierte de que algunos productos «pueden verse afectados por estas vulnerabilidades aunque no parezcan usar PHP directamente».

Dónde buscar:

Sitios web y tiendas: WordPress y WooCommerce, Drupal, Joomla, Magento y Adobe Commerce, Shopware, PrestaShop, TYPO3, y todo lo construido sobre Laravel o Symfony.
Los olvidados: micrositios de campañas, una versión antigua en otro idioma, servidores de preproducción y de pruebas accesibles desde internet, el webmail o el helpdesk que alguien instaló hace años.
Contenedores: cada imagen construida a partir de una imagen base php lleva su propio PHP. Actualizar el host no le sirve de nada.
Paneles de control de alojamiento: cPanel, Plesk y paneles similares incluyen sus propias compilaciones de PHP además de la del sistema. Cada versión habilitada en el panel hay que actualizarla por separado.
Productos con PHP dentro: appliances, herramientas de monitorización, CRM, helpdesks e interfaces de administración de proveedores. El NCSC neerlandés mantiene una lista pública de estos productos con su estado, proveedor por proveedor.
Proveedores: tu empresa de alojamiento, tu agencia, cualquier servicio en el que sepas que hay PHP por debajo. Pregúntales por escrito qué versiones de PHP usan tus sistemas y cuándo se parchearán.

Para cada uno, anota la versión de PHP, cómo se ejecuta PHP (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, un contenedor), si es accesible desde internet y quién puede parchearlo.

Paso 2: parchea en el orden correcto

Empieza por lo que sea accesible desde internet y, dentro de eso, por las configuraciones con Apache y mod_php.

En una rama con soporte (de la 8.2 a la 8.5). Actualiza a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete de tu distribución que contenga la corrección. PHP dice que las distribuciones de Linux recibieron los parches con antelación. Confirmado hasta ahora:

Ubuntu: paquetes corregidos para todas las versiones de la 14.04 a la 26.10. En la 22.04 y posteriores llegan con las actualizaciones normales; en la 20.04 y anteriores necesitan una suscripción a Ubuntu Pro, que es gratuita para un máximo de cinco máquinas (aviso de Canonical).
Debian: php8.4 8.4.27 para Debian 13 (DSA-6574-1) y php8.2 8.2.35 para Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: el boletín de seguridad de Red Hat RHSB-2026-013 enumera los paquetes por versión.
El repositorio Remi, muy usado para tener versiones más recientes de PHP en sistemas de la familia Red Hat: el 21 de octubre, CERT-EU señaló que no tenía paquetes el día de la publicación y recomendó pasar a los paquetes de la distribución o compilar desde el código fuente. Comprueba si se ha puesto al día antes de confiar en él.

En PHP 7.4, 8.0 u 8.1. El proyecto PHP no publica ninguna versión para estas ramas. Su equipo de seguridad preparó backports mínimos en código fuente para las tres, que sirven si compilas PHP tú mismo. Si no, la corrección tiene que venir de tu proveedor (Ubuntu Pro cubre PHP 7.4 en Ubuntu 20.04, por ejemplo) o de actualizar PHP a una versión superior. El consejo de CISA para quien esté en la 8.1 o anterior y no pueda actualizar es tajante: desconectar el sistema hasta que esté parcheado o actualizado a una versión superior.

En PHP 7.3 o anterior. Del proyecto PHP no llega nada. Salvo que algún proveedor siga parcheando tu compilación, la elección está entre actualizar a una versión superior o desconectar el sistema.

Reinicia después de actualizar. Instalar un paquete no sustituye el PHP que ya está en ejecución. El aviso de Ubuntu lo dice sin rodeos: la aplicación «probablemente tendría que reiniciarse». Reinicia PHP-FPM, Apache, LiteSpeed o el contenedor en cada servidor. Después comprueba la versión que ejecuta realmente el servidor web, no solo php -v en la línea de comandos, que puede ser otra compilación.

Contenedores: reconstruye tus imágenes a partir de una imagen base parcheada y vuelve a desplegarlas. Un host parcheado que ejecuta una imagen antigua sigue expuesto.

Alojamiento gestionado: pide a tu proveedor la fecha y la versión, y después compruébalo tú mismo.

Paso 3: si no puedes parchear hoy

El aviso de PHP enumera medidas provisionales y las presenta con una advertencia: «reducen la exposición a vías de ataque concretas, pero no hacen que una instalación sea segura». En resumen, para quien gestione tus servidores:

Para CVE-2026-109618: fija memory_limit=-1 de forma que la aplicación no pueda sobrescribirlo (por ejemplo, con php_admin_value en el pool de PHP-FPM o en la configuración de Apache); fija un post_max_size bajo (PHP sugiere 8M sin subida de ficheros y 32M con ella); limita el tamaño de las peticiones, el número de campos y las partes multipart en el servidor web o en el proxy; y usa un límite de memoria de contenedor o de cgroup, nunca RLIMIT_AS ni RLIMIT_DATA.
Para CVE-2026-109619: fija session.upload_progress.enabled=0 en php.ini o en la configuración del servidor (no con ini_set() ni con un fichero .user.ini) y reinicia todos los workers. En PHP 8.5, fija además fatal_error_backtraces=0.

Dos advertencias. El ajuste de sesión que se difundió ampliamente el 20 de octubre solo cierra vías del segundo fallo, como señaló un miembro del equipo de seguridad de PHP; contra el primero no hace nada. Y memory_limit=-1 elimina el límite de memoria propio de PHP, así que ahora una sola petición pesada puede agotar el servidor. Combínalo con el límite de contenedor o de cgroup.

Un cortafuegos de aplicaciones web ayuda, aunque poco. Las reglas de Cloudflare están activadas por defecto en todos los planes con su WAF, incluido el gratuito, y Palo Alto Networks y otros proveedores han publicado sus propias protecciones. Aun así, Cloudflare pide a sus clientes que parcheen PHP «incluso con protecciones WAF», y vio cómo los atacantes cambiaban sus payloads para esquivar sus reglas. Además, un WAF solo protege el tráfico que pasa por él. Si tu servidor responde en su propia dirección IP, un atacante puede rodearlo.

Si nada de esto puede hacerse rápido, CISA, CERT-EU, el NCSC y la declaración conjunta de la UE apuntan en la misma dirección: desconecta el sistema de la internet pública hasta que esté corregido. Un día con una página de mantenimiento cuesta menos que reconstruir un servidor.

Paso 4: comprueba si ya han entrado

La ventana se abrió el 20 de octubre, cuando empezó la filtración, y se informó de tráfico de ataque a la mañana siguiente. Si un sistema era accesible y estaba sin parchear en esa ventana, parchear cierra la puerta, pero no te dice si alguien entró antes. El NCSC pide a quien no haya podido parchear de inmediato que busque indicios de compromiso y puertas traseras.

Qué buscar, según las recomendaciones publicadas y la práctica habitual de respuesta a incidentes:

Procesos de PHP haciendo cosas que PHP nunca hace, como abrir una shell o descargar herramientas (CISA).
Peticiones multipart inusuales seguidas de errores de límite de memoria o de respuestas HTTP 500 repetidas, workers de PHP que se reinician sin un motivo claro y cookies PHPSESSID anormalmente grandes o malformadas en las respuestas (Wiz).
Ficheros PHP nuevos o modificados en carpetas de subidas, carpetas de caché o la raíz web, cuentas de administrador nuevas en tu CMS y tareas programadas que nadie creó.

Unos logs limpios no son una prueba. El aviso de PHP sobre el segundo fallo advierte precisamente de eso, y Wiz señala que los logs de la aplicación pueden contener poco contexto.

Si encuentras algo, trátalo como un incidente, no como una tarea de parcheo. Aísla el servidor, conserva las evidencias, recurre a un proveedor de respuesta a incidentes y cambia todos los secretos que el servidor web pudiera leer: contraseñas de bases de datos, claves de API, credenciales de pago y de correo, claves de firma. Como el segundo fallo puede divulgar memoria, plantéate rotar los más sensibles de esos secretos en cualquier servidor que haya estado expuesto y sin parchear durante días, aunque no haya indicios de intrusión.

Paso 5: qué puedes tener que notificar

Una vulnerabilidad, por sí sola, no es un incidente que haya que notificar. Una vulnerabilidad explotada puede serlo.

NIS2: si tu organización está dentro del ámbito y un compromiso constituye un incidente significativo, la alerta temprana a tu CSIRT nacional debe enviarse en un plazo de 24 horas. Consulta nuestra guía de NIS2.
RGPD: si se accedió a datos personales, hay que notificarlo a la autoridad de control en un plazo de 72 horas desde que tengas conocimiento de la brecha, salvo que sea improbable que suponga un riesgo para las personas. Consulta nuestra guía del RGPD.
Cyber Resilience Act: si vendes software o un dispositivo con PHP dentro, eres su fabricante según el CRA. Desde el 11 de septiembre de 2026, los fabricantes tienen que notificar las vulnerabilidades activamente explotadas en sus productos a través de la Plataforma Única de Notificación del CRA, como recuerda la declaración conjunta de la UE. Consulta nuestra guía del CRA.
Tus clientes: si alojas o gestionas PHP para clientes, te van a preguntar. Una nota breve por escrito (qué usas, cuándo se parcheó, qué comprobaste) responde a la mayoría, y es la misma nota que querrá ver un auditor o una aseguradora de ciberriesgos.

Después de la emergencia: qué cambiar

En la mayoría de los servidores bien gestionados, PHP2Shell estará parcheado en cuestión de días. Lo que ha revelado sobre tu infraestructura seguirá siendo cierto después.

Averigua cuánto tardas en parchear. Desde el aviso hasta tener todos los servidores reiniciados: ¿horas, días o semanas? Si la respuesta honesta es «tendríamos que preguntar a la agencia», arréglalo antes de la próxima. Cuando unos investigadores dicen que la IA redujo su trabajo de explotación de meses a una semana, da por hecho que los atacantes también pueden moverse a ese ritmo.
Conserva el inventario que acabas de hacer. Fue la parte más difícil de la respuesta, y se queda desfasado en cuanto nadie se responsabiliza de él.
Deja atrás las versiones de PHP al final de su vida. Un sitio en 7.4 u 8.1 necesitó esta vez un proveedor o un backport en código fuente; la próxima vez puede que no haya ni lo uno ni lo otro. PHP 8.2 llega al fin de su vida el 31 de diciembre de 2026, así que un sitio que deje la 8.1 debería pasar directamente a la 8.3 o posterior. Cambiar de versión de PHP suele implicar también actualizar la aplicación: nuestro artículo sobre el fin de vida de Drupal, Umbraco y Kentico muestra lo que eso supone para un CMS.
Prefiere PHP-FPM a mod_php siempre que puedas. Esta vez fue la configuración de menor riesgo.
Deja desactivado el progreso de subida si no lo usas. El aviso de PHP sugiere mantener session.upload_progress.enabled desactivado incluso después de parchear cuando la aplicación no lo necesita.
Fija plazos de parcheo en tus contratos. Pregunta a tu proveedor de alojamiento y a tu agencia con qué rapidez aplican las correcciones críticas de PHP, y consigue la respuesta por escrito.

Lista de comprobación para esta semana

Haz la lista de todas las instalaciones de PHP, incluidos contenedores, paneles de control, productos de proveedores y servidores de preproducción.
Parchea primero los sistemas expuestos a internet, empezando por Apache con mod_php.
Reinicia todos los procesos de PHP y comprueba la versión que indica el servidor web.
Reconstruye y vuelve a desplegar las imágenes de contenedor.
Donde no puedas parchear hoy, aplica los ajustes provisionales de PHP, haz pasar el tráfico por un WAF o desconecta el sistema.
Pide por escrito a tus proveedores y empresas de alojamiento su versión de PHP y su fecha de parcheo.
Revisa los logs y los cambios en ficheros de todo lo que haya estado expuesto y sin parchear desde el 20 de octubre.
Decide si se aplica alguna obligación de notificación (NIS2, RGPD, CRA).
Planifica la salida de PHP 8.1 y anteriores, y de la 8.2 antes del 31 de diciembre.

En qué podemos ayudarte

A la mayoría de las empresas no les faltan ganas de parchear. Lo que les falta es una imagen clara de lo que tienen en funcionamiento, o la gente para hacer el trabajo esta semana. De esa parte nos encargamos nosotros:

Inventario y parcheo, en días. Localizamos tus instalaciones de PHP en servidores, contenedores, paneles de alojamiento y proveedores, las parcheamos, reiniciamos y verificamos, y te dejamos un registro escrito de lo que se hizo y cuándo. Ese registro es también tu respuesta a clientes y auditores.
Salir de las versiones antiguas de PHP. Aplicaciones atascadas en PHP 7.x, 8.0 u 8.1 porque el código no funciona en nada más reciente: las portamos a una versión con soporte dentro de nuestro servicio de mantenimiento de sistemas heredados.
Refuerzo de la seguridad y una rutina de parcheo, para que el próximo aviso sea un trabajo programado y no una emergencia.

Si encuentras indicios de una intrusión, llama primero a un proveedor de respuesta a incidentes. Nosotros podemos encargarnos de la reconstrucción y de la actualización de versión junto a ellos.

Escribe a office@c9group.dev contándonos qué usas y te responderemos con lo que haríamos primero.

Fuentes

Comprobadas el 22 de octubre de 2026. La situación sigue evolucionando: en particular, el estado de la explotación y los paquetes de los proveedores pueden haber cambiado desde entonces.

Proyecto PHP

Agencias

Investigadores, proveedores y datos