¿Hablamos?
Saltar al contenido
621 415 005 Plan gratuito
Infografía: ventana de una web con una línea de código PHP vulnerable marcada, aviso para parchear el servidor y tres pasos: qué es el fallo, si te afecta y qué hacer hoy
  1. Inicio
  2. Blog
  3. Vulnerabilidad PHP
Webs, precios y decisiones

Vulnerabilidad PHP (PHP2Shell): qué significa para tu web y qué hacer hoy

PHP2Shell es una vulnerabilidad PHP de gravedad 9,2 sobre 10 que permite ejecutar código en un servidor sin contraseña. Afecta a cualquier WordPress sin el parche del 21 de octubre. Los grandes hostings ya lo han aplicado, pero actualizar WordPress no lo corrige: hay que comprobar PHP. Te explico cómo y qué pedir a tu proveedor.

Por Javier Mota Ruiz, fundador de Rex Digital Actualizado: Lectura: 17 minutos
Índice
  1. ¿Qué es PHP2Shell y por qué es tan grave?
  2. ¿Afecta PHP2Shell a mi web?
  3. ¿Por qué no basta con actualizar WordPress?
  4. ¿Cómo sé qué versión de PHP usa mi web?
  5. ¿Qué tengo que hacer hoy con mi web?
  6. ¿Qué le pregunto a mi hosting o a mi agencia?
  7. ¿Y si mi web lleva PHP 8.1 o una versión anterior?
  8. ¿Qué pasa si quedan expuestos datos de pacientes o clientes?
  9. ¿Qué es verdad y qué es exageración en las noticias sobre PHP2Shell?
  10. ¿Quién debería vigilar la seguridad de tu web?
  11. Preguntas frecuentes

¿Qué es PHP2Shell y por qué es tan grave?

PHP2Shell es el nombre que ha recibido una pareja de fallos de seguridad de PHP, el lenguaje con el que funciona WordPress: CVE-2026-109618 y CVE-2026-109619. Los dos permiten a un atacante ejecutar código en el servidor sin usuario ni contraseña, solo con peticiones a la web. PHP les ha dado una gravedad de 9,2 sobre 10. El 10 que circuló con la filtración era un error, según la PHP Foundation.

Una vulnerabilidad de ejecución remota de código es un fallo que deja a alguien de fuera dar órdenes a tu servidor como si fuera suyo: leer archivos, instalar programas o cambiar lo que ven tus visitas.

Explicados sin tecnicismos:

  • CVE-2026-109618. Cuando PHP se queda sin memoria mientras prepara una petición, deja datos internos a medias y luego los trata como si estuvieran completos. Es como archivar como terminada una ficha que se quedó sin rellenar.
  • CVE-2026-109619. Después de atender una petición, quedan restos de ella en memoria, y la siguiente petición que atiende el mismo proceso puede usarlos. Es como si el siguiente paciente encontrara en la mesa la carpeta del anterior.

Lo grave no es solo la nota, es el alcance. Según W3Techs, el 69,3 % de las webs cuyo lenguaje de servidor se conoce usa PHP, y WordPress mueve el 39,6 % de todas las webs. El fallo, además, puede actuar antes de que se ejecute el código de tu web, así que da igual lo cuidado que esté tu WordPress. En España, INCIBE-CERT lo ha publicado con importancia 5 sobre 5 y el CCN-CERT ha emitido una alerta de actualización inmediata.

  1. Arranca la auditoría dentro del programa Patch the Planet de OpenAI
  2. Amazon detecta el primer intento de ataque conocido
  3. Se filtran los identificadores de los fallos antes de tiempo
  4. PHP publica el parche a las 16:00, hora peninsular
  5. Hostings como Hostinger, IONOS o Raiola terminan de parchear
  6. ¿Tiene ya el parche el servidor de tu web?
Cronología de PHP2Shell. El parche salió el 21 de octubre a las 14:00 UTC, las 16:00 en la España peninsular. Fuentes: PHP Foundation, Help Net Security y Hostinger.

Lo destapó una auditoría que empezó el 30 de julio con la empresa Calif, dentro de «Patch the Planet», un programa de OpenAI, y en la que también participaron Wiz y la propia OpenAI. OpenAI asegura que sus modelos ayudaron a los investigadores y, según Sansec, el error viene de PHP 5.4, una versión de 2012. Quédate con esta idea: la inteligencia artificial ya ayuda a encontrar fallos que llevaban más de una década en el código, así que vendrán más avisos como este, no menos.

¿Afecta PHP2Shell a mi web?

Sí, si tu web funciona con WordPress, WooCommerce, PrestaShop, Joomla o cualquier otro programa hecho en PHP y su servidor no tiene el parche del 21 de octubre. No hace falta que tengas tienda, área privada ni formularios: las piezas de PHP donde están los fallos funcionan por defecto en cualquier web. Lo que cambia de un caso a otro es quién tiene que actuar, y eso depende de dónde está alojada tu web.

Tu situaciónQué significaQué hacer
Hosting compartido o gestionado (Hostinger, SiteGround, IONOS, Raiola, Webempresa…)Lo parchea el proveedor
Los grandes proveedores ya lo han aplicado o han puesto protecciones		Comprobar la fecha de compilación de PHP o pedir confirmación por escrito
VPS o servidor propioNadie lo hace por ti
El proveedor te alquila la máquina, pero el PHP lo actualizas tú o tu técnico		Actualizar hoy a la versión corregida y reiniciar PHP
PHP 8.2, 8.3, 8.4 u 8.5Con versión oficial
Corregidas en 8.2.35, 8.3.36, 8.4.27 y 8.5.12		Confirmar que tu servidor tiene esa versión o el parche equivalente
PHP 7.4, 8.0 u 8.1Sin soporte oficial
Solo hay parches mínimos de PHP y los que aplique tu proveedor		Pedir confirmación del parche y planificar el paso a PHP 8.3 o superior
PHP 7.3 o anteriorSin arreglo de PHP
Algunos proveedores, como Hostinger o cPanel y CloudLinux, también las han parcheado		Migrar cuanto antes; si no es posible, valorar rehacer la web
Web en Wix, Squarespace o ShopifyNo gestionas el servidor
La seguridad del servidor es cosa de la plataforma		Nada en tu parte; desconfía de correos que te pidan actuar

Un aviso sobre el último caso de la tabla: la noticia ya se está usando como gancho para estafas. IONOS ha alertado de correos falsos que se aprovechan de ella. Si te llega un mensaje urgente que te pide pagar, instalar algo o «verificar» tu cuenta para protegerte de PHP2Shell, no hagas clic. Entra tú en el panel de tu proveedor por la dirección de siempre.

¿Por qué no basta con actualizar WordPress?

Porque WordPress y PHP son capas distintas, y cada una la actualiza alguien diferente. WordPress se actualiza a sí mismo y puede actualizar sus plugins y su tema. PHP es el motor que hay debajo: lo instala y lo actualiza quien gestiona el servidor. Wordfence lo dejó claro en su aviso: las actualizaciones automáticas de WordPress no aplicarán esta corrección. Y WordPress.org ha confirmado que no habrá versión nueva de WordPress, porque el fallo no es suyo.

Lo que WordPress actualiza por sí solo

Tus textos, fotos y formulariosQuién lo actualizaTú
Tema y pluginsQuién lo actualizaTú o tu agencia
WordPressQuién lo actualizaSus actualizaciones automáticas
PHP: el motor que ejecuta WordPressQuién lo actualizaTu hosting o quien gestione el servidor
Servidor y sistema operativoQuién lo actualizaTu proveedor de hosting

PHP2Shell está en la capa naranja: las actualizaciones de WordPress no llegan ahí.

Las cinco capas de una web WordPress y quién se encarga de cada una. Las actualizaciones automáticas de WordPress llegan hasta la tercera.

De aquí sale una regla práctica: si alguien te ofrece un plugin que «arregla PHP2Shell», desconfía. Patchstack recomienda no instalar plugins ni fragmentos de código de arreglo no oficiales, y Cloudflare recuerda que actualizar el código de la web o sus plugins no corrige estas vulnerabilidades.

Esta es, para nosotros, la verdadera lección de la semana. En el Método Rex lo primero es rastrear, y una de las primeras cosas que miramos en una web es quién responde de cada capa. Si no puedes decir en una frase quién se encarga del PHP de tu web, el problema no es PHP2Shell. El problema es que el próximo fallo te va a pillar igual.

¿Cómo sé qué versión de PHP usa mi web?

Tienes tres caminos, del más rápido al más fiable. Con cualquiera de ellos sabrás en dos minutos si estás en una versión corregida (8.2.35, 8.3.36, 8.4.27 u 8.5.12) o si toca preguntar.

  1. Desde WordPress. Entra en Herramientas, Salud del sitio, pestaña Información, y abre el apartado Servidor. Ahí aparece la versión de PHP.
  2. Desde el panel de tu hosting. En Hostinger: Sitios web, Administrar y, en el menú lateral, Información de PHP. La versión sale arriba; busca también la fecha de compilación (Build Date). En paneles cPanel, la herramienta suele llamarse MultiPHP Manager o Select PHP Version.
  3. Preguntando por escrito a tu proveedor. Es lo único que te da certeza cuando el número no cuadra. Más abajo tienes el mensaje listo para enviar.

¿Qué tengo que hacer hoy con mi web?

Ocho comprobaciones, en este orden. El orden importa: en Rex trabajamos con una regla que aquí vale más que nunca, ninguna agencia debería tocarte la web sin haberla rastreado antes. Y eso incluye actualizar PHP.

Rastrear
  1. Apunta tu versión de PHP y, si aparece, la fecha de compilación.
  2. Averigua qué alojamiento tienes: compartido o gestionado (parchea el proveedor) o VPS y servidor propio (parcheas tú o tu técnico).
  3. Haz una copia de seguridad completa, archivos y base de datos, y guárdala fuera del servidor.
Ejecutar
  1. En hosting compartido, envía a tu proveedor el mensaje de la siguiente sección y guarda la respuesta.
  2. En VPS o servidor propio, actualiza a la versión corregida de tu rama y reinicia todos los procesos de PHP (PHP-FPM, Apache o LiteSpeed). Sin ese reinicio, el PHP antiguo puede seguir funcionando en memoria.
  3. Si estás en PHP 8.1 o anterior, además del parche, programa el paso a PHP 8.3 o superior y pruébalo antes en una copia de la web.
Vigilar
  1. Revisa que no haya usuarios administradores que no conozcas ni archivos modificados desde el 17 de octubre, la fecha del primer intento de ataque conocido.
  2. Si tu web pasa por Cloudflare, comprueba que su protección está activa. Activó reglas contra estos fallos en todos sus planes, también en el gratuito. Ayuda, pero no sustituye al parche.

¿Qué le pregunto a mi hosting o a mi agencia?

Lo justo para no quedarte con un «está todo bien» sin datos. Copia este mensaje, cambia el dominio y envíalo hoy por el canal de soporte de tu hosting o a la agencia que gestiona tu web:

Asunto: PHP2Shell: confirmación del parche en mi web

Hola:

Os escribo por las vulnerabilidades de PHP CVE-2026-109618 y CVE-2026-109619 (PHP2Shell). Sobre mi web [tudominio.es], ¿podéis confirmarme por escrito estos cuatro puntos?

  1. Si el servidor ya tiene aplicado el parche y desde qué fecha.
  2. Qué versión de PHP usa la web y con qué fecha de compilación.
  3. Si habéis reiniciado los procesos de PHP después de aplicarlo.
  4. Si mi versión de PHP tiene soporte oficial y, si no lo tiene, qué plan proponéis para actualizarla.

Gracias.

Abrir este mensaje en mi correoSe abre tu programa de correo con el texto ya escrito.

Y así se lee la respuesta:

  • Bien: te confirman el parche, la versión, la fecha y el reinicio de PHP. Guarda ese correo.
  • A medias: «está todo protegido», sin datos. Vuelve a pedir los cuatro puntos.
  • Mal: «eso es cosa de WordPress», «se actualiza solo» o días sin contestar. Es la señal de que nadie se ocupa de tu servidor.

¿No sabes quién se encarga del PHP de tu web?

Te lo miramos. En el plan de marketing gratuito rastreamos tu web antes de proponerte nada: versión de PHP, copias de seguridad, plugins y accesos. Te lo entregamos en 48-72 horas, nos contrates o no.

Pedir mi plan de marketing gratuito Ver mantenimiento web
Sin permanencia · un solo cliente por sector y zona · plan gratuito en 48-72 horas

¿Y si mi web lleva PHP 8.1 o una versión anterior?

Entonces tu web ya estaba en riesgo antes de esta semana, y PHP2Shell solo lo ha sacado a la luz. PHP 8.1 y las versiones anteriores no tienen soporte oficial. Para este fallo, el equipo de PHP no ha publicado versiones nuevas en esas ramas: solo parches mínimos en código fuente para 7.4, 8.0 y 8.1, y pide a cada uno que hable con su proveedor o que actualice. Para PHP 7.3 y anteriores no ofrece nada.

Algunos proveedores han parcheado esas versiones por su cuenta, como cPanel, CloudLinux, TuxCare o el propio Hostinger en sus planes gestionados. Es un salvavidas, no una solución. Lo que recomiendan las fuentes de seguridad es subir al menos a PHP 8.3 y, si tus plugins lo permiten, a 8.4 u 8.5. No elijas 8.2 como destino: deja de recibir parches de seguridad el 31 de diciembre de 2026.

Le pasa sobre todo a las webs que se hicieron y no se volvieron a tocar. Lo vemos a menudo en negocios que nos llegan después del Kit Digital: la agencia entregó la web, cobró y desapareció, y desde entonces nadie ha mirado el servidor. Si es tu caso, en la estafa del Kit Digital explico cómo recuperar el control de tu web.

Cambiar de rama, por ejemplo de 8.1 a 8.3, sí puede romper plugins o temas antiguos: hazlo con copia de seguridad y probando antes, como explicamos en las preguntas frecuentes. Si la web es tan antigua que no aguanta el cambio, a veces sale más barato rehacerla con un desarrollo web nuevo que seguir parcheándola.

¿Qué pasa si quedan expuestos datos de pacientes o clientes?

Si tienes una consulta o un despacho, esta es la parte que más te toca y la que casi ningún medio cuenta. Si alguien entra en tu servidor y accede a datos personales, como los mensajes de un formulario, una agenda de citas o una lista de clientes, eso es una brecha de datos personales. El RGPD obliga a notificarla a la Agencia Española de Protección de Datos (AEPD) sin dilación indebida y, como máximo, en 72 horas desde que la conoces, salvo que sea improbable que suponga un riesgo para las personas. Si notificas más tarde, tienes que justificar el retraso. Si el riesgo es alto, también hay que comunicárselo a los afectados.

  • Los datos de salud son una categoría especial del RGPD. Según la guía de la AEPD, si una brecha los afecta se da por probable que cause daños. En una consulta de psicología o una clínica, el listón está más alto.
  • En un despacho, los mensajes de clientes suelen contener información confidencial, y la guía de la AEPD incluye los datos sobre condenas penales entre las categorías sensibles.
  • Tú eres el responsable de los datos y tu hosting, el encargado. El RGPD obliga al encargado a avisarte sin dilación si sufre una brecha, pero la notificación a la AEPD te corresponde a ti.
  • Las 72 horas corren también en fines de semana y festivos, y la brecha existe aunque no puedas demostrar que los datos salieron: basta con que hayan podido ser vistos.
  • Documenta siempre qué pasó y qué hiciste, aunque al final no tengas que notificar nada.

La AEPD tiene una herramienta gratuita, Asesora Brecha, que te ayuda a decidir si debes notificar. Y hay una medida que reduce el daño de cualquier fallo futuro en cinco minutos: mira si tu formulario de contacto guarda una copia de cada mensaje en la base de datos de WordPress. Algunos plugins lo hacen sin que lo sepas. Si los mensajes ya te llegan por correo, desactiva esa copia y borra el histórico. Lo que no está en la web no se puede robar.

¿Qué es verdad y qué es exageración en las noticias sobre PHP2Shell?

Casi todo lo que se publica tiene una base real, pero varias cifras se han inflado al pasar de un medio a otro. El riesgo es serio y la solución es sencilla: tener el parche aplicado. Estos son los titulares más repetidos, contrastados con las fuentes oficiales:

Lo que se leeLo que hay
«Tiene una gravedad de 10 sobre 10»Es 9,2 sobre 10 en los dos fallos. El 10 salió de la filtración y la PHP Foundation lo ha corregido.
«La NSA ha pedido apagar las webs»Pidió actualizar y desconectar solo si la actualización inmediata no es viable. Es el mismo consejo que dan el NCSC británico, CERT-EU o INCIBE-CERT.
«Afecta al 70 % de internet»Según W3Techs, el 69,3 % de las webs cuyo lenguaje de servidor se conoce usa PHP. Usar PHP no es lo mismo que estar expuesto: muchas ya tienen el parche o un cortafuegos delante.
«Hay 1,3 millones de servidores vulnerables»Es una estimación informal de un investigador. Estos recuentos se basan en la versión que anuncia el servidor y no detectan los parches de proveedores y distribuciones.
«Están hackeando millones de webs»Hay millones de intentos y escaneos. A 22 de octubre, Wordfence había bloqueado más de 74.000 sin ver compromisos confirmados, Patchstack recibía avisos de explotación activa de proveedores de hosting y el NCSC de Países Bajos investiga las primeras señales de ataques con éxito. Hay ataques reales, pero no una oleada confirmada de webs comprometidas.
«Los gobiernos han apagado sus webs»Cierto, por precaución. Países Bajos (DigiD, MijnOverheid) y Finlandia desconectaron servicios públicos el 21 de octubre. DigiD volvió esa misma tarde.
«Basta con cambiar una línea de php.ini»Falso. PHP dice que no hay mitigaciones completas y que actualizar es la única opción segura.
«Ya hay una tercera vulnerabilidad crítica»La CVE-2026-115560, publicada el 23 de octubre, es un aviso informativo para una configuración poco habitual.
«PHP2Shell y wp2shell son lo mismo»No. wp2shell fue un fallo de WordPress corregido en julio de 2026. PHP2Shell está en PHP, una capa por debajo.

La regla para leer cualquier noticia de seguridad es siempre la misma: busca el aviso oficial (php.net, INCIBE-CERT, tu proveedor) y desconfía de las cifras redondas sin fuente. En el caso de PHP2Shell, el riesgo es real y la solución es aburrida: tener el parche aplicado y alguien que lo confirme.

¿Quién debería vigilar la seguridad de tu web?

Alguien con nombre y apellidos, y que se entere antes que tú. PHP2Shell no será el último fallo de este tipo: si la IA ya ayuda a encontrar errores que llevaban más de una década en el código, estos avisos serán cada vez más frecuentes. Mantener una web no consiste en pulsar «actualizar» en los plugins. Consiste en que cada capa, de los textos al servidor, tenga un responsable que sepa qué hacer cuando sale un aviso.

Si ya tienes a alguien, perfecto: pásale la lista de comprobación de este artículo y pídele la respuesta por escrito. Si no lo tienes, o no sabes quién es, tienes los detalles en nuestro mantenimiento de páginas web.

Ninguna agencia debería tocarte la web sin haberla rastreado antes. Y ninguna web debería quedarse sin nadie que la vigile después.

Preguntas frecuentes sobre la vulnerabilidad PHP2Shell

¿Tengo que apagar mi web por PHP2Shell?

No, si tu servidor ya tiene el parche. Las autoridades, como el NCSC británico, CERT-EU o INCIBE-CERT, recomiendan desconectar o aislar solo los sistemas que no se pueden actualizar de inmediato. Si tu web está en un hosting compartido de un gran proveedor, lo normal es que ya esté corregida: confírmalo con la fecha de compilación o por escrito.

¿Actualizar PHP puede romper mi web?

Aplicar el parche de tu misma rama, por ejemplo pasar de una 8.3 anterior a la 8.3.36, tiene poco riesgo. Cambiar de rama, por ejemplo de 8.1 a 8.3, sí puede romper plugins o temas antiguos. Haz antes una copia de seguridad, pruébalo en una copia de la web y revisa la versión mínima de PHP de cada plugin. En Hostinger puedes volver a la versión anterior desde el panel, pero volver a una versión sin parche te deja expuesto otra vez.

¿Me protege un plugin de seguridad?

No del todo. El fallo puede actuar antes de que WordPress cargue sus plugins, así que la solución está en el servidor. Un cortafuegos delante de la web, como el de Cloudflare o Imunify360, ayuda mientras llega el parche, pero sus propios responsables lo presentan como una medida provisional.

¿Qué versión de PHP es mejor para WordPress ahora?

PHP 8.3 o superior, y 8.4 u 8.5 si tus plugins y tu tema lo admiten. PHP 8.2 sigue recibiendo parches de seguridad, pero solo hasta el 31 de diciembre de 2026, así que no compensa elegirla como destino de una migración.

¿Cómo sé si alguien ha entrado ya en mi web?

Busca usuarios administradores que no conozcas, archivos PHP nuevos, cambios en archivos como .htaccess o functions.php, redirecciones extrañas y avisos de Google o del navegador. Errores 500 repetidos o fallos de memoria desde el 17 de octubre merecen revisión, aunque no prueban un ataque. Si encuentras algo, cambia todas las contraseñas y pide ayuda antes de tocar nada más.

¿Cuánto cuesta proteger mi web de PHP2Shell?

En hosting compartido, normalmente nada: la mayoría de los grandes proveedores ya lo ha aplicado sin coste en sus planes compartidos, aunque no en los VPS. Cambiar de versión de PHP desde el panel tampoco cuesta dinero; lo que lleva trabajo es comprobar que los plugins y el tema funcionan. En un VPS o en una web muy antigua, el coste es el tiempo del técnico que haga la actualización.

Referencias

  1. Anuncio de las versiones de seguridad PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 · php.net, 21/10/2026
  2. GHSA-w8hw-w9fx-j79w: CVE-2026-109618 · Avisos de seguridad de php-src en GitHub, 21/10/2026
  3. GHSA-6wmf-4rv5-p3rp: CVE-2026-109619 · Avisos de seguridad de php-src en GitHub, 21/10/2026
  4. Today’s PHP security release and how we’re strengthening PHP security · The PHP Foundation, 21/10/2026
  5. Múltiples vulnerabilidades en PHP (aviso de importancia 5/5) · INCIBE-CERT, 21/10/2026
  6. CCN-CERT AL 11/26: actualización inmediata de vulnerabilidad crítica en PHP · CCN-CERT, 21/10/2026
  7. Critical security issue affecting PHP · NCSC, Reino Unido, 21/10/2026
  8. Security Advisory 2026-018 · CERT-EU, 21/10/2026
  9. Protecting you from PHP2Shell · Hostinger, 21/10/2026, actualizado el 22/10/2026
  10. Cómo revisar la versión de PHP en Hostinger · Centro de ayuda de Hostinger
  11. Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 ya están parcheadas en nuestros servidores · Webempresa, 22/10/2026
  12. Protección WAF frente a las vulnerabilidades de PHP · Cloudflare, 21/10/2026
  13. PHP major vulnerability alert · Patchstack, 21/10/2026
  14. PHP patches critical PHP2Shell vulnerabilities as hosts across the WordPress ecosystem race to protect customers · The Repository, 22/10/2026 (declaraciones de Wordfence y WordPress.org)
  15. Attacks on PHP2Shell continue, but no known compromises as a result yet · Wordfence, 22/10/2026
  16. PHP2Shell: vulnerabilidades de PHP parcheadas (intento de ataque detectado por Amazon el 17/10) · Help Net Security, 21/10/2026, actualizado el 22/10/2026
  17. PHP remote code execution: PHP2Shell · watchTowr, 21/10/2026
  18. Aantal websites Rijksoverheid preventief offline na kwetsbaarheden PHP · Gobierno de Países Bajos, 21/10/2026
  19. Dutch cybersecurity center investigating first signs hackers abused PHP issues · NL Times, 23/10/2026
  20. Valtori desconecta servicios web públicos por precaución · Yle (Finlandia), 21/10/2026
  21. Uso de PHP en sitios web · W3Techs, consulta del 23/10/2026
  22. Uso de WordPress en sitios web · W3Techs, consulta del 23/10/2026
  23. FAQ: My site was hacked · Documentación de WordPress.org
  24. Reglamento General de Protección de Datos (artículos 9, 33 y 34) · Diario Oficial de la Unión Europea
  25. Guía para la notificación de brechas de datos personales · Agencia Española de Protección de Datos, 2021
  26. Asesora Brecha · Agencia Española de Protección de Datos

Guías relacionadas