PHP2Shell: la vulnerabilidad crítica de PHP que pone en jaque a WordPress, Magento y PrestaShop

Una sola petición HTTP. Sin usuario, sin contraseña, sin que el código de tu aplicación llegue siquiera a ejecutarse. Eso es todo lo que necesita un atacante para lanzar comandos en un servidor vulnerable a PHP2Shell, el nombre con el que se conoce a la pareja de fallos CVE-2026-109618 y CVE-2026-109619, ambos con una puntuación de 9,2 en CVSS v4.0. El equipo de PHP publicó los parches el 21 de octubre de 2026, pero el problema no empieza ni termina ahí: los honeypots de Amazon ya registraron un intento de explotación el día 17, cuatro días antes de la divulgación pública, y desde entonces empresas como Patchstack y Aikido hablan de incidentes reales en marcha.

Si tu web corre sobre WordPress, WooCommerce, PrestaShop, Magento, Drupal, Joomla, Nextcloud o cualquier panel montado en PHP —es decir, si estás en la mayoría de la web—, este artículo te afecta. Partimos del análisis en vídeo que publicó el equipo de AI Security y lo ampliamos con los avisos técnicos publicados desde entonces para convertirlo en un protocolo de actuación completo.

Qué es PHP2Shell y por qué no es «otra vulnerabilidad más»

La mayoría de fallos graves en el ecosistema PHP viven en un plugin, un tema o un módulo concreto. Se parchea la extensión afectada y se acabó. PHP2Shell es otra liga: el fallo está en el propio intérprete, en la forma en que PHP gestiona la memoria de cada petición. Por eso no importa lo bien mantenido que esté tu WordPress ni lo auditado que esté tu código: si el PHP que lo ejecuta es vulnerable, la puerta está abierta antes de que tu aplicación tenga la oportunidad de defenderse.

Dos fallos de memoria, una misma consecuencia

Según la documentación técnica publicada por los investigadores de Wiz, detrás de los dos CVE hay en realidad cuatro errores de gestión de memoria que llevaban años en el código:

• CVE-2026-109618 (corrupción por falta de memoria): cuando una petición agota la memoria a mitad de proceso, PHP puede interrumpirse con estructuras internas a medio inicializar. La rutina de limpieza posterior trata esos datos rotos como válidos, y ahí se abre la vía a la ejecución de código.
• CVE-2026-109619 (estado global obsoleto): parte del estado interno ligado a una petición sobrevive después de que su memoria haya sido liberada. Una petición posterior atendida por el mismo worker puede utilizar ese estado «fantasma» antes de que se reinicialice.

El matiz importante es que el vector de entrada son peticiones multipart —las mismas que se usan para enviar formularios con archivos— diseñadas para provocar esas condiciones de memoria. Por eso, como veremos, buena parte de las mitigaciones temporales pasan por limitar o bloquear ese tipo de tráfico.

La IA ha acortado el camino del fallo al exploit

Wiz lo resume sin rodeos: los modelos de IA de frontera «redujeron sustancialmente la barrera» para convertir un fallo antiguo y difícil de explotar en un exploit funcional. Es la misma advertencia con la que cierra el vídeo de AI Security: la velocidad a la que aparecen y se arman nuevas vulnerabilidades obliga a cambiar la forma de protegerse. Kevin Beaumont, uno de los analistas de seguridad más seguidos, lo calificaba como «una de las mayores vulnerabilidades en años». Y Hal Pomeranz añadía la frase que más debería preocupar a quien gestiona webs: «habrá una cola larga con esta». Traducido: millones de servidores olvidados, sin mantenimiento, que seguirán siendo explotables durante años.

A quién afecta: prácticamente a toda la web en PHP

El exploit filtrado funciona, según varias fuentes, hasta PHP 5.4. Cualquier instalación que sirva peticiones web con PHP está en el perímetro, con independencia del modo de ejecución:

• Apache con mod_php: el escenario de mayor riesgo según el propio equipo de PHP, con un exploit demostrado que no requiere autenticación y se ejecuta antes del código de la aplicación.
• PHP-FPM (el habitual detrás de Nginx y de la mayoría de hostings modernos), php-cgi, FrankenPHP y LiteSpeed: también afectados.

Por encima de esa capa está todo lo demás: los CMS que dominan el mercado, las tiendas montadas con WooCommerce o PrestaShop, Magento, Drupal, Joomla, Nextcloud o phpMyAdmin. El alcance desborda incluso la web clásica: Palo Alto Networks ha reconocido que todas las versiones de PAN-OS y Panorama están afectadas, y Fortinet y Cisco seguían revisando sus productos en el momento de escribir estas líneas.

Paso 1: comprobar tu versión y actualizar

El equipo de PHP es tajante en sus dos avisos: actualizar es la única mitigación completa. No hay ajuste de configuración que sustituya al parche. El procedimiento es sencillo y conviene hacerlo hoy:

1. Conéctate por SSH y ejecuta php -v para ver la versión de la línea de comandos. Ojo: el PHP que atiende tu web (FPM o mod_php) puede no ser el mismo que el de la consola. Compruébalo también con un phpinfo() temporal o desde el panel de tu hosting.
2. Si estás en una rama con soporte, actualiza a la versión corregida o superior (tabla inferior).
3. Reinicia PHP —el servicio php-fpm, Apache si usas mod_php— para que todos los workers carguen el binario nuevo. Un paquete actualizado con procesos antiguos en memoria sigue siendo vulnerable.
4. Vuelve a comprobar la versión para confirmar que el cambio se ha aplicado.

Versiones corregidas por rama

Paso 2: qué hacer si tu PHP ya no tiene soporte

Aquí está el grueso del problema real. Una parte enorme de la web sigue funcionando en PHP 7.4, 8.0 u 8.1, versiones que el proyecto PHP ya no mantiene. Eso no significa necesariamente que estés desprotegido, porque las distribuciones Linux y los proveedores de soporte extendido recibieron los parches antes de la publicación y los están aplicando por su cuenta:

• Debian ha publicado actualizaciones para Debian 12 y 13.
• Ubuntu ha publicado paquetes para 22.04, 24.04 y versiones posteriores.
• AlmaLinux también ha liberado paquetes corregidos.

Un detalle que despista a muchos administradores: en estos casos el número de versión que devuelve php -v puede no cambiar, porque la distribución aplica el parche sobre su propia versión empaquetada. Lo que hay que comprobar es el aviso de seguridad de tu distribución y la versión del paquete instalado, no la cifra de PHP.

Atención también a quienes usan el repositorio de Remi (rpms.remirepo.net), muy popular en CentOS, Rocky y AlmaLinux para tener versiones recientes de PHP: al ser un proyecto mantenido por voluntarios, no tuvo actualizaciones el día de la publicación. Toca pasar a los paquetes de la distribución o compilar desde las fuentes.

Si tu distribución no trae parche, la siguiente opción es compilar el backport mínimo que el equipo de PHP ha publicado para 7.4, 8.0 y 8.1. Y si estás en PHP 5 o en una versión anterior a 7.4, no hay atajo: hay que migrar o aislar el servidor. El NCSC británico va más allá y recomienda directamente desconectar cualquier sistema que no pueda corregirse de inmediato.

Paso 3: mitigaciones si hoy no puedes actualizar

El escenario es frecuente: una tienda o una aplicación a medida que dejaría de funcionar con una versión moderna de PHP. Para ese caso existen mitigaciones. Conviene ser claros: son parciales, no sustituyen al parche y solo compran tiempo. Pero reducen mucho la superficie de ataque.

En la configuración de PHP

• session.upload_progress.enabled = 0: desactiva el seguimiento del progreso de subida, una de las piezas implicadas en el vector de ataque. Por sí solo no basta.
• memory_limit = -1: elimina el límite de memoria de PHP para que el atacante no pueda forzar la condición de «sin memoria» que dispara CVE-2026-109618. Es contraintuitivo y tiene un coste evidente: un script descontrolado puede consumir toda la RAM. Por eso se recomienda acompañarlo de límites a nivel de contenedor o cgroup, en lugar de los límites tipo RLIMIT_AS.
• post_max_size bajo: alrededor de 8M si tu aplicación no recibe archivos, o 32M si los necesita.
• En PHP 8.5, fatal_error_backtraces = 0.

Dos requisitos para que esto sirva de algo: los valores deben fijarse de forma que la aplicación no pueda sobrescribirlos (por ejemplo con php_admin_value en el pool de FPM, no con un ini_set() que cualquier plugin puede revertir), y hay que reiniciar todos los workers tras el cambio.

En el servidor web o el proxy

La medida más contundente es bloquear las peticiones multipart antes de que lleguen a PHP, o al menos limitar su tamaño y número. El precio es claro: se rompe la subida de archivos de tu aplicación (imágenes en el editor de WordPress, adjuntos en formularios, importaciones de catálogo en la tienda). Puede ser aceptable durante unas horas o unos días mientras preparas la actualización, pero no como estado permanente.

Si estás detrás de Cloudflare

Cloudflare ha desplegado reglas WAF de emergencia contra los vectores de explotación conocidos, disponibles para todos los clientes, incluido el plan gratuito. Pero hay una condición que muchos pasan por alto: solo protegen si tu servidor de origen acepta exclusivamente tráfico procedente de Cloudflare. Si la IP real de tu servidor es accesible directamente —algo muy habitual—, el atacante simplemente esquiva el WAF y ataca el origen. Restringe el acceso al puerto 80/443 a los rangos de IP de Cloudflare o usa un túnel.

Resumen operativo de mitigaciones

Cualquiera de estos ajustes puede alterar el funcionamiento de tu web. Pruébalos primero en un entorno de staging o, como mínimo, revisa formularios, pasarelas de pago y subidas de archivos justo después de aplicarlos. Un error 500 al guardar en WordPress tras tocar la configuración de PHP es el síntoma más típico de un límite mal ajustado.

Paso 4: comprobar si ya te han hackeado

Parchear cierra la puerta, pero no echa a quien ya haya entrado. Con explotación registrada desde el 17 de octubre, todo servidor que haya estado expuesto debe revisarse. No hay listas de IPs o hashes fiables publicadas; lo que sí hay son patrones de comportamiento que conviene buscar en los logs:

• Peticiones multipart extrañas seguidas de errores, en especial errores de límite de memoria o ráfagas de respuestas HTTP 500.
• Cookies PHPSESSID enormes o malformadas.
• Workers de PHP que se reinician solos sin motivo aparente.
• Procesos php-fpm, php-cgi, httpd o apache2 que lanzan shells, intérpretes o descargas con curl/wget.
• Ficheros PHP nuevos o modificados que no reconoces en el directorio web: las clásicas web shells camufladas con nombres inocentes.
• Tareas cron nuevas o usuarios del sistema (o administradores de WordPress) que nadie ha creado.

Si aparece cualquiera de estas señales, asume el compromiso: rota credenciales de base de datos, FTP/SSH y paneles, revoca claves de API y tokens (pasarelas de pago, servicios de correo, conectores con Google o Meta) y restaura desde una copia limpia anterior a la intrusión. Para comprobar la exposición desde fuera, Searchlight Cyber ha publicado php2shell-scanner, una herramienta de código abierto que verifica si un host es vulnerable.

Por qué esto es también un problema de SEO y de negocio

En SEO Ético insistimos en que la seguridad no es un asunto exclusivo del departamento técnico. Un servidor comprometido rara vez se usa solo para minar criptomonedas: lo habitual es que acabe sirviendo spam inyectado, páginas ocultas de casinos o farmacias, redirecciones maliciosas para el tráfico que llega desde Google o enlaces salientes a granjas de enlaces. Las consecuencias para la visibilidad orgánica son directas:

• Avisos de «sitio peligroso» de Navegación Segura en Chrome y en los resultados de búsqueda, que hunden el CTR de un día para otro.
• Problemas de seguridad y acciones manuales en Search Console, con pérdida de rankings hasta que se limpia y se solicita revisión.
• Contaminación del índice con miles de URLs basura que diluyen la autoridad del dominio y cuya limpieza puede llevar meses, en una lógica muy parecida a la que describimos en nuestro análisis del SEO negativo.
• En tiendas online, el riesgo escala: robo de datos de clientes, skimmers en el checkout y obligaciones de notificación bajo el RGPD.

Además, Google endurece cada vez más su respuesta frente a sitios que alojan spam, aunque lo hayan hecho sin saberlo, como ya vimos con su ofensiva antispam impulsada por IA. Cuesta mucho menos parchear hoy que recuperar posiciones dentro de tres meses.

La lección de fondo: el mantenimiento ya no es opcional

PHP2Shell deja una conclusión incómoda para muchas pymes y agencias: el PHP 7.4 que «funciona bien» y que nadie quiere tocar por miedo a romper la web es, a partir de ahora, un pasivo con fecha de caducidad. La IA no solo ayuda a escribir contenidos o código; también acelera la conversión de fallos antiguos en ataques automatizados y masivos. Eso reduce el margen entre la publicación de un parche y la explotación a escala a días, a veces horas.

La respuesta no es el pánico, sino el método: inventario de servidores y versiones, un plan de actualización realista para las ramas sin soporte, entornos de pruebas para validar cambios, monitorización de logs y copias de seguridad verificadas. Si gestionas una web en PHP y no puedes responder ahora mismo a la pregunta «¿qué versión de PHP sirve mi web y quién la actualiza?», ese es el primer problema que debes resolver. Encontrarás más guías sobre infraestructura y rendimiento en nuestra sección de Web.

Fuentes: vídeo y guías de AI Security, avisos de seguridad de PHP, Help Net Security, AlmaLinux y SOCRadar. Dada la evolución rápida del caso, consulta siempre el aviso de tu distribución o proveedor de hosting.