PHP2Shell es el nombre de dos vulnerabilidades críticas del propio PHP (CVE-2026-109618 y CVE-2026-109619), publicadas el 21 de octubre de 2026, que permiten ejecutar código en el servidor sin iniciar sesión. Afectan a cualquier web que funcione con PHP, WordPress y WooCommerce incluidos, y no se arreglan actualizando WordPress: hay que actualizar PHP. Desde el 26 de octubre se explotan activamente. En un hosting compartido lo normal es que ya esté corregido, pero se comprueba en cinco minutos y conviene pedirlo por escrito.
Si has llegado aquí buscando «vulnerabilidad php wordpress», «php2shell checker» o «vulnerabilidad php hoy», este artículo contesta tres cosas: cómo saber si tu web está afectada, qué mensaje mandarle a tu proveedor de alojamiento y qué hacer si sospechas que ya te han entrado. Esto último, junto con lo que obliga a hacer el RGPD, no lo hemos visto en las primeras páginas en español que salen en Google. Cada dato lleva su fuente al lado.
Qué es PHP2Shell
PHP2Shell son dos fallos en el núcleo de PHP, el lenguaje con el que funcionan WordPress, Joomla, Drupal y buena parte de las webs de pymes. Según el aviso de seguridad de PHP, las versiones corregidas «arreglan dos vulnerabilidades críticas que pueden permitir la ejecución remota de código sin autenticación». Traducido: un atacante puede llegar a ejecutar órdenes en el servidor de tu web sin conocer ninguna contraseña.
Los dos fallos tienen su ficha propia en GitHub: CVE-2026-109618, que se dispara cuando PHP se queda sin memoria a mitad de una petición, y CVE-2026-109619, que aprovecha restos de una petición anterior atendida por el mismo proceso. PHP les da una puntuación de gravedad CVSS 4.0 de 9,2 sobre 10.
Los encontraron tres equipos que acabaron trabajando juntos. Calif detectó el primer fallo el 1 de agosto dentro de Patch the Planet, un programa de OpenAI, y lo comunicó a PHP el 11 de agosto. Wiz Research llegó por su cuenta el 19 de agosto, con ayuda de modelos de IA de Google y de OpenAI, y OpenAI aportó más vías de ataque en septiembre, según cuenta la PHP Foundation. El fallo viene de lejos: el registro de NVD sitúa el más antiguo en PHP 5.4.0, una versión de marzo de 2012.
La situación a 27 de octubre de 2026 es esta:
- La Agencia de Ciberseguridad de Estados Unidos (CISA) añadió los dos fallos el 26 de octubre a su catálogo de vulnerabilidades explotadas. Eso significa que ya hay ataques reales.
- INCIBE-CERT lo publicó el 21 de octubre con importancia «5 - Crítica», la más alta de su escala, y lo actualizó el 26.
- El 23 de octubre PHP informó de un tercer fallo relacionado, el CVE-2026-115560, que solo aparece con una combinación poco habitual de configuración y código. Todavía no tiene parche.
¿Está afectada mi web? Cómo saberlo en cinco minutos
Tu web está protegida si su versión de PHP es igual o superior a la corregida de su rama: 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si usa PHP 8.1 o anterior, no hay versión oficial corregida, solo parches de código fuente para 7.4, 8.0 y 8.1 que tiene que aplicar tu proveedor. Así se comprueba:
- En WordPress, entra en el escritorio y ve a Herramientas > Salud del sitio > Información > Servidor. La línea «Versión de PHP» te da el número. Es el camino que indica la documentación de WordPress.
- En el panel del hosting suele aparecer en el apartado de PHP. En Plesk está en Herramientas y configuración > Configuración de PHP.
- Compara el número completo, no solo la rama. «8.3» no basta: tiene que ser 8.3.36 o superior. Si ves 8.1 o menos, tu web funciona con una versión que ya no tiene soporte de seguridad, según el calendario oficial de PHP.
Ojo con dos trampas. La primera: algunos proveedores corrigen el fallo sin cambiar el número de versión. Plesk explica que en sus paquetes de PHP 7.4, 8.0 y 8.1 la corrección se reconoce por la fecha de compilación, el 21 de octubre o posterior, y no por el número. La segunda: los comprobadores en línea que circulan estos días leen la versión que el servidor anuncia en sus cabeceras, y muchos servidores la ocultan. Que un comprobador no detecte nada no demuestra que estés a salvo. Y úsalos solo con webs que sean tuyas.
Por eso, aunque el número te salga bien, la respuesta que vale es la de tu proveedor por escrito.
Qué pedirle a tu hosting: el mensaje
Escríbele hoy, por ticket o por correo, y guarda la respuesta. Así queda constancia de la fecha en que te confirmaron la corrección, que te servirá si algún día tienes que demostrar que actuaste con diligencia. Puedes copiar este mensaje:
Hola. Sobre las vulnerabilidades de PHP publicadas el 21 de octubre de 2026 (PHP2Shell: CVE-2026-109618 y CVE-2026-109619), os pido que me confirméis por escrito: (1) qué versión exacta de PHP usa mi web [dominio] y si ya incluye la corrección; (2) en qué fecha y hora quedó aplicada la corrección o la mitigación en mi servidor; (3) si habéis detectado intentos de explotación contra mi web o mi servidor antes de esa fecha, y (4) si tengo que hacer algo por mi parte. Gracias.
La pregunta 3 es la que casi nadie hace y la más importante. Si tu hosting tardó en parchear, el riesgo no es solo lo que pueda pasar mañana, sino lo que haya podido pasar entre el 21 de octubre y el día del parche.
Varios proveedores que usan muchas pymes españolas ya han contado lo que hicieron. cdmon aplicó una mitigación a las 07:30 del 21 de octubre y el parche ese mismo día por la tarde. Dinahosting dice haber corregido PHP 7.4 y versiones posteriores y desactivado las funciones vulnerables en las antiguas. Webempresa explica que usó su cortafuegos web mientras llegaba el parche. Son afirmaciones de cada proveedor sobre su propio servicio; lo que vale para tu web es lo que te confirmen sobre tu web.
Si tienes tu propio servidor
Si gestionas tú el servidor, un VPS o una máquina en tu oficina, la tarea es tuya: actualiza PHP ya. Si no puedes, la recomendación de CISA y de WordPress.org es dura pero clara: desconectar de internet los sistemas que no se puedan actualizar, incluidos los que sigan en PHP 8.1 o anterior.
INCIBE-CERT recoge en su aviso las medidas temporales que propone PHP mientras actualizas, como fijar memory_limit=-1 desde la configuración del servidor o desactivar session.upload_progress.enabled. El mismo aviso advierte que esas medidas reducen algunas vías de ataque, pero que la actualización es la única solución completa. Si no sabes qué significan esas líneas, no es tu trabajo aplicarlas: llama a quien te mantiene el servidor.
Lo que no hace falta hacer
- No hace falta actualizar WordPress por esto. WordPress.org lo dice expresamente: estos fallos no son de WordPress, afectan a cualquier servidor con una aplicación PHP y no hay ni habrá una actualización de WordPress para ellos. Mantener WordPress y los plugins al día sigue siendo necesario, pero no arregla PHP2Shell.
- No hace falta cambiar de hosting a la carrera. Si tu proveedor te confirma la corrección con fecha, el problema concreto está resuelto. Otra cosa es lo que digan sus tiempos de respuesta sobre el servicio que tienes contratado.
- No hace falta pagar un análisis de urgencia si tu web está en un hosting que ya ha confirmado el parche y no hay señales de que te hayan entrado.
¿Y si sospecho que ya me han entrado?
Las señales típicas son usuarios administradores que no creaste, páginas o enlaces que no reconoces, redirecciones a otras webs, avisos de Google o del antivirus, o un correo de tu hosting por actividad anómala. Si ves alguna, por este orden:
- Avisa a tu hosting y pídele los registros de acceso desde el 21 de octubre.
- No restaures una copia encima sin más. Primero hay que saber por dónde entraron, o volverán a hacerlo. Guarda la copia actual por si hace falta analizarla.
- Cambia las contraseñas y las claves que viven en el servidor: la del administrador de WordPress, la de la base de datos, la del FTP o SFTP y las claves de servicios conectados, como la pasarela de pago o el correo. Wiz demostró que uno de los fallos permite leer la memoria del proceso de PHP, donde pueden estar contraseñas y tokens.
- Pide ayuda gratuita a INCIBE. Su línea Tu Ayuda en Ciberseguridad, en el 017, atiende también a empresas, todos los días de 8:00 a 23:00, y es gratuita y confidencial.
- Si en la web había datos personales, como clientes de una tienda, pacientes o formularios de contacto, valora si tienes que notificarlo. El artículo 33 del RGPD obliga a comunicar una brecha de datos personales a la autoridad de control, en España la AEPD, «a más tardar 72 horas» después de tener constancia de ella, salvo que sea improbable que suponga un riesgo para las personas. La notificación se hace en la sede electrónica de la AEPD.
Las 72 horas cuentan desde que lo sabes, no desde que te entraron. Por eso conviene hacer la pregunta 3 del mensaje cuanto antes y no esperar a la respuesta para cambiar contraseñas.
Lo que se ha exagerado estos días
«Afecta al 70 % de las webs del mundo.» La cifra sale de W3Techs, que el 27 de octubre de 2026 cuenta que PHP lo usa el 69,2 % de las webs cuyo lenguaje de servidor conoce. Es la cuota de PHP, no el número de webs que hoy se puedan atacar: muchos hostings parchearon o filtraron los ataques el mismo 21 de octubre, y PHP califica la explotación de complejidad alta.
«Entran en cualquier web sin usuario ni contraseña.» No hace falta contraseña, eso es cierto. Pero que funcione depende de cómo esté instalado PHP. Según el aviso de PHP, el riesgo es mayor con Apache y mod_php, donde una sola petición basta, y en otros modos de ejecución depende de cómo trabaje la aplicación.
«La IA ya ha encontrado el 3 % de todas las vulnerabilidades de la historia.» El dato que circula sale de un artículo de la EFF del 23 de octubre. Lo que dice es que el 3 % de todos los CVE registrados se publicó en el último mes, los encontrara quien los encontrara. Lo hemos comprobado en la API de NVD el 27 de octubre: 15.126 CVE publicados entre el 1 y el 27 de octubre de 2026, sobre un total de 415.241. Es un 3,6 %, y no todos los encontró una IA.
«Hay que aguantar 18 meses.» Lo escribió el 22 de octubre Jason Clinton, del equipo de seguridad de Anthropic, en un mensaje en X. Pedía a los responsables de seguridad que reclamen ayuda a sus consejos «no para la IA, para lo básico», y añadía que habrá que aguantar unos 18 meses. Es su opinión sobre la avalancha de vulnerabilidades que está destapando la IA, no un dato sobre PHP2Shell, que no menciona.
Un ejemplo: la clínica con WordPress en un hosting compartido
Un caso construido, no un cliente real. Una clínica de fisioterapia de Zaragoza tiene su web en WordPress, con un formulario de cita que guarda nombre, teléfono y motivo de la consulta. Se la hizo un freelance hace cuatro años y nadie la mantiene.
La recepcionista entra en Herramientas > Salud del sitio y ve PHP 7.4. No hay versión oficial corregida para esa rama, así que manda el mensaje de arriba al hosting. Le contestan que aplicaron el parche de código fuente el 22 de octubre y que no ven intentos de explotación contra su dominio. Problema resuelto por hoy. Pero el motivo de consulta es un dato de salud, y la clínica acaba de descubrir que su web corre sobre una versión sin soporte desde hace años. La próxima vulnerabilidad le pillará igual. Lo que le toca ahora es planificar el paso a PHP 8.3 o superior y decidir quién mantiene la web, no esperar al siguiente aviso.
La lectura de PotencIA
Este apartado es criterio propio, separado de los hechos citados arriba.
Lo que enseña PHP2Shell no es que PHP sea inseguro, sino que muchas webs de pymes no tienen a nadie encargado de ellas. La corrección existía el mismo día del aviso. Las webs que siguen expuestas lo están porque nadie sabe en qué versión de PHP funcionan, ni a quién hay que llamar para cambiarla. Una web sin mantenimiento no es una web terminada: es una web que nadie está mirando.
La segunda lectura tiene que ver con el ritmo. Que modelos de IA encuentren fallos que llevaban años escondidos va a hacer que avisos como este lleguen más a menudo. La defensa de una pyme no pasa por entender cada CVE, sino por tres cosas aburridas: saber dónde está alojada su web, tener a alguien que conteste cuando llega un aviso y tener copias de seguridad que se puedan restaurar.
Y una advertencia de parte interesada: PotencIA diseña y mantiene webs, también en WordPress, así que nos conviene que te preocupes por esto. Lo que incluimos y lo que no, con los costes de mantener una web viva, está en nuestra página de diseño web. Si estás valorando cuánto cuesta rehacer una web vieja, tienes los números en cuánto cuesta una página web profesional.
Cómo hemos verificado esto
Las fuentes se consultaron el 27 de octubre de 2026 desde España. El aviso de PHP en php.net, los dos avisos de GitHub, los registros de NVD y cve.org, el catálogo y la alerta de CISA, el aviso de INCIBE-CERT, las notas de WordPress.org, Plesk, cdmon, Dinahosting y Webempresa, los blogs de Calif, Wiz y la PHP Foundation, el artículo de la EFF, el dato de W3Techs y el mensaje de Jason Clinton se leyeron directamente y se guardaron en texto. La traducción de los textos en inglés es nuestra.
El recuento de CVE de octubre es un cálculo propio sobre la API pública de NVD. No hemos podido leer el texto completo del anuncio de OpenAI, que bloquea la lectura automatizada; lo que se dice aquí de su papel sale de Calif, Wiz y la PHP Foundation. Tampoco hemos podido abrir la alerta del CCN-CERT. La página de INCIBE sobre su línea 017 se leyó en el navegador. El ejemplo de la clínica es un caso construido.
La investigación de las fuentes la hizo un subagente, y cada dato usado aquí se ha vuelto a comprobar contra los textos guardados. La revisión humana de esta pieza es posterior a su publicación.