Dos vulnerabilidades críticas. Gravedad 9,2 sobre 10. Ejecución remota de código sin contraseña. E intentos de ataque detectados antes de su divulgación oficial.
Si tienes una página web, especialmente si funciona con WordPress, hay algo que deberías comprobar hoy. Y no, entrar en el administrador y ver que todos tus plugins están actualizados no es suficiente.
El 21 de octubre de 2026 se publicaron las correcciones para dos vulnerabilidades críticas del motor PHP, identificadas como CVE-2026-109618 y CVE-2026-109619, conocidas conjuntamente como PHP2Shell.
Lo realmente preocupante no es solo su gravedad. Es dónde se encuentran.
El problema está debajo de WordPress
Imagina que tu página web es un edificio. WordPress sería el interior, con sus puertas, cerraduras y sistemas de acceso. Los plugins serían los servicios que has incorporado. Pero PHP forma parte de la estructura que permite que todo funcione.
Puedes tener todas las cerraduras actualizadas, contraseñas robustas y sistemas de seguridad funcionando. Si el problema está en la estructura, esas precauciones pueden resultar insuficientes.
El fallo no está en WordPress ni en un plugin concreto. Está en el propio motor PHP.
Los investigadores de Wiz han demostrado la posibilidad de ejecutar código remotamente, sin autenticación, contra instalaciones de WordPress, Drupal y Joomla. En determinadas configuraciones de Apache con mod_php, el ataque puede producirse incluso antes de que se ejecute código de la aplicación.
No hace falta conocer la contraseña del administrador. No hace falta encontrar un plugin desactualizado. Bajo determinadas condiciones, una petición HTTP especialmente manipulada puede desencadenar el problema.
Esto no significa que todas las webs que utilizan PHP sean explotables de la misma manera. La configuración del servidor, la versión de PHP y las condiciones necesarias para cada ataque importan. Pero sí significa que un WordPress perfectamente actualizado puede seguir expuesto.
¿Qué podría conseguir un atacante?
El término técnico es Remote Code Execution (RCE), o ejecución remota de código: conseguir que un servidor ejecute instrucciones que nunca debería aceptar.
Dependiendo de los permisos y de la configuración del sistema, un atacante podría:
- Acceder a información confidencial.
- Modificar archivos o alterar el contenido de la web.
- Robar credenciales, tokens o claves de acceso.
- Utilizar el servidor comprometido para otras actividades maliciosas.
Los investigadores también demostraron que determinadas variantes permiten leer información de la memoria de los procesos PHP. Esa memoria puede contener contraseñas, tokens de autenticación y claves de acceso utilizadas por otras peticiones.
Que una versión de PHP sea vulnerable no significa que tu servidor ya haya sido comprometido. Pero tampoco significa que esté protegido porque la web funcione correctamente.
No es una amenaza que exista únicamente en un laboratorio
La investigación ha permitido demostrar ataques funcionales contra aplicaciones reales en entornos controlados. Y hay otro detalle preocupante: Cloudflare confirmó que, tras filtrarse información sobre las vulnerabilidades antes de su publicación oficial, observó tráfico de ataque dirigido contra sus clientes.
La compañía desplegó protecciones adicionales mediante su firewall de aplicaciones web aproximadamente nueve horas antes de la divulgación pública.
Conviene aclarar algo: la PHP Foundation señaló que, en el momento de publicarse las correcciones, no había identificado exploits funcionales entre las pruebas de explotación que estaban circulando. Una cosa es observar intentos de ataque y otra demostrar que consiguieron comprometer servidores.
Pero el riesgo es suficientemente grave para que los responsables de PHP hayan pedido actualizar inmediatamente. Y ahora que la información técnica es pública, otros investigadores y atacantes pueden analizarla.
Cómo comprobar si tu WordPress necesita una actualización urgente
La buena noticia es que puedes empezar a comprobarlo sin ser informático.
1. Descubre qué versión de PHP utiliza tu web
Accede al administrador de WordPress y entra en Herramientas → Salud del sitio → Información → Servidor. Busca el campo correspondiente a la versión de PHP.
Apunta el número completo: no basta con saber que utilizas PHP 8.4. Necesitas conocer si es 8.4.26, 8.4.27 u otra versión.
2. Comprueba si tienes una versión corregida
El proyecto PHP publicó el 21 de octubre de 2026 estas versiones de seguridad:
| Rama PHP | Primera versión oficial corregida |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Si utilizas una versión oficial anterior a la indicada dentro de su rama, debes actualizar. Consulta el aviso oficial de PHP.
Atención si utilizas PHP 8.2: aunque ahora dispone de una actualización de seguridad, su soporte oficial termina el 31 de diciembre de 2026. Tienes dos tareas: instalar la corrección urgente y planificar la migración a una rama mantenida.
¿Y si utilizas PHP 8.1 o anterior? Esas ramas ya no reciben actualizaciones regulares del proyecto PHP. Dada la gravedad del problema, se han facilitado parches mínimos del código fuente para 7.4, 8.0 y 8.1, y algunos proveedores ofrecen soporte extendido. Pero eso no convierte una rama antigua en una versión oficialmente mantenida.
Importante para administradores: algunas distribuciones Linux aplican correcciones de seguridad sin cambiar el número de versión principal. Por eso hay que consultar los paquetes instalados y los avisos del proveedor. El número de WordPress es una primera pista, no siempre una prueba definitiva.
3. Si tienes un hosting contratado, pregunta
Muchos propietarios de páginas web no saben qué versión de PHP utilizan. Si es tu caso, escribe a tu proveedor de alojamiento. Puedes copiar este mensaje:
Hola:
Ante la publicación de las vulnerabilidades críticas PHP2Shell (CVE-2026-109618 y CVE-2026-109619), necesito confirmar qué versión de PHP está ejecutando actualmente mi web.
¿Podéis indicarme si las correcciones de seguridad ya están aplicadas?
Si utilizáis versiones con parches propios o retroportados, agradecería que me confirmarais qué actualización los incluye.
Gracias.
No necesitas una respuesta genérica como «nuestros servidores son seguros». Necesitas saber si esas vulnerabilidades concretas están corregidas.
4. Actualiza y comprueba que todo sigue funcionando
Si puedes modificar PHP desde tu panel de alojamiento, revisa las versiones disponibles. Antes de cambiar de rama, realiza una copia de seguridad recuperable y comprueba la compatibilidad de la web.
Después verifica que siguen funcionando los elementos importantes: formularios de contacto, inicio de sesión, tienda online y pasarelas de pago, sistemas de reservas e integraciones con servicios externos.
Si administras un servidor, verifica además que los procesos web están ejecutando realmente la versión corregida. En determinados entornos no basta con actualizar el paquete: también hay que reiniciar los servicios o procesos correspondientes.
5. No confundas protección con reparación
Un firewall de aplicaciones web, como el de Cloudflare, puede ayudar a bloquear determinadas técnicas de explotación. Los plugins de seguridad, las contraseñas robustas y la autenticación de dos factores siguen siendo muy recomendables.
Pero ninguna de esas medidas corrige por sí misma las vulnerabilidades del motor PHP.
El aviso oficial contempla medidas temporales para administradores que no puedan actualizar inmediatamente, como ajustes relacionados con session.upload_progress.enabled y los límites de tamaño de las peticiones HTTP. Deben aplicarse con conocimiento de su impacto sobre las aplicaciones.
PHP advierte expresamente de que solo la actualización constituye una solución completa.
Si un servidor ha estado expuesto, también es recomendable revisar registros, modificaciones inesperadas y posibles indicadores de compromiso. Instalar el parche evita las vías de explotación conocidas, pero no demuestra que nunca haya existido una intrusión.
OpenAI ha publicado una herramienta para comprobar versiones
OpenAI ha publicado php2shell-checker, una herramienta gratuita y de código abierto para realizar comprobaciones sobre versiones de PHP.
Es una utilidad orientada principalmente a perfiles técnicos: se ejecuta desde la terminal utilizando Node.js y dispone de integraciones para Codex. Permite consultar la versión anunciada por una web o comprobar una instalación local.
Pero tiene una limitación fundamental. Cuando analiza una dirección web, depende de la información que el servidor expone públicamente. Si PHP está oculto en las cabeceras HTTP, puede devolver UNKNOWN.
UNKNOWN no significa que la web sea segura. Significa que la herramienta no ha podido determinar su versión. Tampoco un resultado favorable basado en cabeceras públicas sustituye a comprobar directamente los parches del servidor.
Para un propietario de WordPress, el método más sencillo sigue siendo consultar Salud del sitio y, cuando sea necesario, preguntar al proveedor de alojamiento.
Lo más inquietante: parte del problema ya se había detectado en 2024
Esta historia tiene otra dimensión. La PHP Foundation ha reconocido que en 2024, durante trabajos derivados de una auditoría de seguridad, se identificaron los primeros indicios del problema de gestión de memoria relacionado con CVE-2026-109618.
En aquel momento se planteó la posibilidad de explotación, pero todavía no se había demostrado una vía concreta. Corregir el problema tampoco era sencillo: las soluciones estudiadas podían provocar incompatibilidades, problemas de rendimiento o cambios importantes en extensiones de terceros.
El trabajo quedó bloqueado en distintas ocasiones. La propia fundación ha reconocido que el retraso fue consecuencia de problemas en sus procesos de decisión y de la falta de recursos.
En 2026, las investigaciones de Calif, OpenAI y Wiz permitieron demostrar el impacto real del fallo. La inteligencia artificial también desempeñó un papel importante en la investigación y validación de vulnerabilidades.
¿Cuántas vulnerabilidades que hoy parecen demasiado complejas para ser explotadas dejarán de serlo cuando la IA reduzca el esfuerzo necesario para desarrollar ataques?
No significa que la IA convierta automáticamente cualquier fallo en un ataque funcional. Significa que la dificultad técnica puede dejar de ser una barrera tan eficaz como antes.
La pregunta que nadie debería dejar sin responder
Durante años hemos insistido, con razón, en actualizar WordPress, eliminar plugins abandonados y utilizar contraseñas robustas. Debemos seguir haciéndolo.
Pero PHP2Shell nos recuerda una realidad incómoda: la seguridad de una web no termina en su panel de administración.
También depende del sistema operativo, del servidor web, de PHP, de sus extensiones, de la configuración y del mantenimiento continuo.
Y aquí aparece un problema cotidiano. El propietario cree que se encarga el desarrollador. El desarrollador cree que se encarga el hosting. Y el hosting puede considerar que determinados componentes son responsabilidad del cliente.
Mientras tanto, la web sigue funcionando, recibe pedidos y almacena información. Todo parece estar bien. Hasta que deja de estarlo.
Una web que funciona no es necesariamente una web segura.
Si tienes una página web, comprueba hoy qué versión de PHP utiliza y quién se responsabiliza de mantenerla. Y si conoces a alguien que utiliza WordPress, comparte esta información: puede ayudarle a detectar un riesgo que ni siquiera sabía que existía.
Me gustaría terminar con una pregunta, especialmente para desarrolladores, administradores de sistemas y proveedores de hosting: cuando aparece una vulnerabilidad crítica como PHP2Shell, ¿quién debería responsabilizarse de corregirla: el hosting, el desarrollador o el propietario de la web? Y, sobre todo, ¿cómo comprobamos que alguien se está ocupando realmente?
Fuentes técnicas
- Aviso oficial de seguridad de PHP (21/10/2026).
- PHP Foundation: investigación, divulgación y proceso de corrección.
- Wiz Research: investigación PHP2Shell.
- Cloudflare: tráfico de ataque y medidas de protección.
- OpenAI: php2shell-checker.
- PHP: versiones oficialmente soportadas.
Información revisada el 22 de octubre de 2026.
Tecnidom — Administración de sistemas, soporte IT y ciberseguridad. tecnidom.com.
¿Necesitas ayuda con la tecnología de tu empresa?
Podemos revisar contigo qué está ocurriendo, qué riesgos existen y por dónde tiene sentido empezar.
