Fuente principal: The PHP Foundation, «Today's PHP Security Release, and How We're Strengthening PHP Security», 21 de octubre de 2026. Para el detalle técnico, el análisis de Wiz Research y los advisories de GitHub.
El 21 de octubre de 2026, el proyecto PHP publicó una actualización de emergencia para dos vulnerabilidades críticas que permiten ejecutar código de forma remota sin autenticación. Al día siguiente, la historia estaba en medios generalistas de todo el mundo, con gobiernos revisando servicios públicos, empresas apagando partes de su infraestructura y equipos de seguridad buscando servidores sin actualizar.
El nombre que se popularizó es PHP2Shell. No es un problema de WordPress, de un plugin ni de un tema: está en el núcleo del intérprete de PHP. Eso es lo que lo hace distinto y lo que obliga a mirar la versión del servidor, no solo la del CMS.
Qué pasó, en orden
- 20 de octubre: los identificadores CVE-2026-109618 y CVE-2026-109619 empezaron a circular en foros y redes antes del anuncio coordinado. PHP adelantó la preanuncio y movió la release un día.
- 21 de octubre, 14:00 UTC: PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 con la corrección.
- 21 y 22 de octubre: CISA, CERT-EU y el NCSC británico emitieron alertas. Wiz publicó su análisis técnico, OpenAI y Calif explicaron su parte en la investigación, y medios como BBC y The Guardian reportaron servicios caídos y millones de intentos de explotación.
- 22 de octubre: la noticia llegó a portadas generalistas. Wikipedia retiró partes de su web como precaución y varios gobiernos europeos suspendieron servicios públicos, según BBC.
La situación siguió cambiando después de la publicación. CISA no había observado explotación al momento de emitir su alerta, pero The Guardian reportó millones de intentos de explotación y ya circulaban pruebas de concepto públicas. En un incidente así, la ventana entre “hay parche” y “hay explotación” puede medirse en horas.
Qué son exactamente las dos vulnerabilidades
Ambas fueron calificadas con CVSS 9.2 por el equipo de seguridad de PHP. Las dos son fallos de seguridad de memoria en el motor de PHP, relacionados con cómo se manejan los errores fatales y las situaciones de falta de memoria.
| CVE | Nombre técnico | Qué permite |
|---|---|---|
| CVE-2026-109618 | RCE via OOM corruption | Corromper memoria y ejecutar código; también disclosure de memoria del proceso |
| CVE-2026-109619 | RCE via stale global state | Reutilizar estado global que apunta a memoria liberada y ejecutar código en una petición posterior |
El detalle que importa para una empresa no es la mecánica interna, sino el alcance:
- No requiere autenticación. En Apache con
mod_php, el fallo de CVE-2026-109618 puede dispararse antes de que se ejecute el código de la aplicación. En PHP-FPM también se confirmó ejecución remota a través de rutas de aplicación. - No depende de WordPress, Drupal o Joomla. Wiz demostró explotación en esos tres, pero también advirtió que una aplicación “Hello World” sobre una versión vulnerable puede estar expuesta. El fallo está por debajo de la aplicación.
- Puede filtrar memoria. Además de ejecutar código, una de las variantes permite leer memoria del proceso, que puede contener contraseñas, tokens, claves de API y certificados de otras peticiones.
- Afecta a versiones antiguas. Wiz afirma que todas las versiones publicadas en la última década, desde PHP 5.4, están afectadas por al menos una de las dos. PHP solo mantiene parches para 8.2, 8.3, 8.4 y 8.5; PHP 8.1 y anteriores no recibieron corrección oficial.
Wiz estima que PHP impulsa alrededor del 70% de los sitios web. Es una estimación de la industria, no un censo, pero explica por qué una vulnerabilidad en el intérprete se convierte en un problema de infraestructura global.
Por qué esta vez es distinto
Cada cierto tiempo aparece una vulnerabilidad que cambia la conversación: Heartbleed en OpenSSL, Log4Shell en Java. PHP2Shell tiene un componente similar: el fallo está en una capa que casi todos dan por sentada.
La diferencia es que esta vez la investigación se apoyó en modelos de IA para encontrar y encadenar fallos que llevaban más de una década en el código. La PHP Foundation lo describe como un punto de inflexión: las herramientas permiten descubrir errores más rápido, tanto a defensores como a atacantes. Eso no significa que “la IA haya roto PHP”; significa que la economía de encontrar y explotar fallos complejos cambió.
Para un equipo pequeño, la lección práctica es incómoda: la seguridad del runtime no se delega al CMS. WordPress puede estar actualizado y el servidor seguir ejecutando una versión vulnerable de PHP.
Qué hacer ahora
1. Inventariar todo lo que corre PHP
No alcanza con revisar el sitio principal. PHP suele estar escondido en:
- el hosting del sitio corporativo y de la tienda;
- imágenes Docker y contenedores;
- aplicaciones internas y paneles legacy;
- funciones serverless o servicios gestionados;
- plugins o herramientas que traen su propio runtime.
CISA recomienda identificar y inventariar cualquier sistema que ejecute PHP, porque muchas veces no es visible desde fuera.
2. Actualizar a una versión corregida
Las versiones parcheadas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Si el hosting es gestionado, abrí un ticket y pedí confirmación por escrito de la versión de PHP y de la fecha de aplicación. Si administrás el servidor, actualizá el paquete y reiniciá PHP-FPM o el servidor web según corresponda.
Si estás en PHP 8.1 o anterior, no hay parche oficial. La única salida es migrar a una versión soportada. Mantener una versión sin soporte después de una divulgación como esta no es una decisión técnica: es una exposición abierta.
3. Si no podés actualizar hoy
CISA recomienda sacar de línea los sistemas PHP expuestos hasta poder parchearlos. Si eso no es viable:
- aislá el servicio con reglas de red y limitá el acceso;
- aplicá reglas de WAF como mitigación temporal;
- monitorizá de forma intensiva;
- planificá la actualización con una fecha concreta.
El WAF reduce la exposición, pero no elimina la vulnerabilidad. No lo trates como la solución final.
4. Comprobar la versión en WordPress
La versión de PHP no está en el panel de WordPress; está en el servidor. Estas son las formas más rápidas de verificarla:
php -v
Si tenés WP-CLI:
wp --info
En el panel de WordPress, andá a Herramientas → Salud del sitio → Información → Servidor y buscá la versión de PHP. En un hosting gestionado, la encontrás en hPanel, cPanel o en la sección de configuración de PHP.
Si usás Docker:
docker exec -it <nombre-del-contenedor> php -v
Ocultar la versión de PHP en las respuestas HTTP no es una mitigación. No cambia el código que se ejecuta.
5. Buscar señales de compromiso
Los fallos ocurren por debajo de la aplicación, así que los logs del CMS pueden tener poco contexto. Wiz recomienda revisar:
- peticiones multipart inusuales seguidas de errores de
memory_limito respuestas 500 repetidas; - cookies
PHPSESSIDinesperadamente grandes o malformadas; - caídas y reinicios anómalos de workers de PHP;
- procesos de PHP lanzando shells o descargando herramientas;
- actividad extraña en logs de Apache, PHP-FPM, LiteSpeed o el proxy.
Si hay indicios de explotación, no borres logs. Aislá el sistema, preservá evidencia y rotá credenciales, tokens y claves que hayan estado en ese servidor.
6. Revisar la cadena completa
Después de parchear, revisá:
- usuarios administradores y tareas programadas que no reconozcas;
- archivos modificados en WordPress, plugins, temas y directorios de subida;
- conexiones salientes y cuentas de servicio;
- claves de API, contraseñas y certificados que puedan haber estado en memoria.
La corrección del intérprete cierra la puerta de entrada, pero no revierte un acceso que ya ocurrió.
Qué no hacer
- No asumas que actualizar WordPress actualiza PHP. Son capas distintas.
- No confíes solo en el WAF. Es una mitigación temporal, no un parche.
- No instales pruebas de concepto de fuentes desconocidas. Los PoC públicos también pueden ser una vía de infección.
- No sigas en PHP 8.1 o anterior esperando que el hosting lo resuelva solo.
- No borres logs ni reconstruyas el servidor antes de preservar evidencia si sospechás compromiso.
Cómo citar este artículo
Si vas a usar este análisis en un informe interno, una newsletter o un artículo, podés citarlo así:
Coderwebs. «PHP2Shell: qué pasó con la vulnerabilidad crítica de PHP y qué hacer ahora». 23 de octubre de 2026. https://coderwebs.com/blog/php2shell-php-vulnerability/
Las fuentes primarias y técnicas están listadas al final. Si tu equipo necesita ayuda para inventariar versiones, revisar WordPress o priorizar la actualización, podés hablar con nosotros o ver cómo trabajamos el mantenimiento WordPress.
Conclusión
PHP2Shell no es una historia sobre un plugin desactualizado. Es una historia sobre una capa de infraestructura que sostiene una parte enorme de la web y que muchas empresas no revisan hasta que hay una emergencia. La respuesta correcta tiene tres pasos: parchear primero, investigar después y monitorizar de forma sostenida.
Si tu sitio corre WordPress, la pregunta no es “¿tengo la última versión de WordPress?”. La pregunta es “¿qué versión de PHP está ejecutando el servidor y quién la actualiza?”.