PHP2Shell: el fallo de seguridad que afecta a millones de webs (y cómo saber si la tuya es una de ellas)

El martes 21 de octubre de 2026 saltó una alerta de seguridad de las que no se ven todos los años. Se hizo público un fallo grave, bautizado como PHP2Shell, en la tecnología sobre la que funcionan la mayoría de las páginas web del mundo. Desde entonces, los organismos de ciberseguridad de medio mundo, el INCIBE en España y la Agència de Ciberseguretat de Catalunya entre ellos, piden a todo el que tenga una web que la actualice cuanto antes. Algunos gobiernos europeos llegaron a desconectar sus webs oficiales mientras lo hacían.

Si tienes una web hecha con WordPress, una tienda online o casi cualquier otra página, esto va contigo. No porque tu web tenga ningún error, sino porque el fallo está en la base sobre la que se apoyan casi todas. En este artículo te explicamos, sin tecnicismos, qué ha pasado, qué le puede ocurrir a una web que no se actualice, cómo saber en qué situación está la tuya y qué hay que hacer.

Qué ha pasado, explicado sin tecnicismos

Tu web no funciona sola. Por debajo hay un «motor», un lenguaje de programación llamado PHP, que es el que hace que WordPress, WooCommerce, PrestaShop y la mayoría de páginas respondan cuando alguien entra. Según W3Techs, siete de cada diez webs del mundo funcionan con él. Es como el motor de un coche: no lo ves, pero sin él nada se mueve.

El 21 de octubre, los responsables de PHP avisaron de dos fallos en ese motor. Los dos están puntuados con un 9,2 sobre 10 en la escala que mide la gravedad de estos problemas, en la categoría «crítica», y los dos permiten lo mismo: que alguien, desde cualquier lugar del mundo y sin tener ninguna contraseña, haga que tu servidor ejecute lo que él quiera. Es como si cualquiera pudiera abrir la puerta de tu negocio sin llave.

Dos datos más para entender el tamaño del problema. Los investigadores que lo descubrieron comprobaron el ataque contra versiones actuales de WordPress, Drupal, Joomla y Magento tal como vienen de serie, y sitúan el origen del fallo en una versión de PHP de hace más de una década: lleva años ahí sin que nadie lo viera. Y ya se está utilizando: Amazon detectó el primer intento de ataque cuatro días antes de que el fallo se hiciera público, y tanto Amazon como Cloudflare registran ataques desde el día del anuncio (Help Net Security, Tenable). El INCIBE lo clasifica en el nivel máximo de importancia.

Qué le puede pasar a tu web

Cuando alguien consigue entrar por este fallo, la web deja de ser tuya en la práctica. Según el aviso de PHP y la cobertura de 3Cat, lo que permite es:

• Tomar el control de la web: hacer en tu servidor lo mismo que podrías hacer tú, o más.
• Cambiar lo que ven tus clientes: páginas alteradas, enlaces a otros sitios, descargas que tú no has puesto.
• Dejar instalado código malicioso que sigue funcionando aunque después actualices, si nadie lo limpia.
• Llegar a tus datos: pedidos, clientes, transacciones y la información privada de tus usuarios.

Por eso las agencias de seguridad de Estados Unidos y del Reino Unido han recomendado desconectar las webs que no puedan actualizarse de inmediato, y por eso Países Bajos y la administración flamenca de Bélgica retiraron temporalmente webs oficiales. No es alarmismo: es lo que hace quien no puede actualizar en el momento.

Cómo saber si tu web está afectada

Todo se reduce a una pregunta: ¿qué versión de PHP tiene tu servidor? Es un número que no sale en la web, pero que se puede consultar de tres formas:

1. Preguntando a tu proveedor de alojamiento o a quien te mantiene la web. Es lo más rápido si no te manejas con paneles.
2. En el panel de tu alojamiento, donde casi siempre hay un apartado llamado «Versión de PHP» o «Selector de PHP».
3. Dentro de WordPress, en el menú Herramientas, Salud del sitio, pestaña Información, apartado Servidor. WordPress incluso avisa en esa pantalla cuando la versión es antigua (documentación de WordPress).

Con el número en la mano, esta es la referencia:

• Está protegida frente a ataques nuevos si tiene una de las versiones corregidas, PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o una posterior. Ojo: protegida a partir de ahora; más abajo te explicamos por qué eso no cierra el tema.
• Está afectada si tiene cualquier versión anterior a esas. Hay que actualizar.
• Está afectada y, además, sin arreglo fácil si tiene PHP 8.1 o anterior (8.0, 7.4…). Esas versiones son tan antiguas que ya no reciben actualizaciones oficiales: PHP solo ha publicado unos parches pensados para técnicos, y cada proveedor decide si los aplica. Si tu web está en una de ellas, lo más probable es que siga expuesta hasta que la pasen a una versión moderna.

Un detalle más: la versión 8.2, aunque hoy se pueda corregir, deja de recibir actualizaciones de seguridad el 31 de diciembre de 2026 (registro de cambios de PHP). Quien esté ahí tendrá que volver a moverse en dos meses.

Qué hay que hacer

1. Actualizar PHP a una versión corregida

Es la única solución completa, y así lo repiten los responsables de PHP en cada aviso: no hay medidas parciales que dejen la web segura. En la mayoría de los casos la actualización se hace en el servidor, no en la web, así que depende de tu proveedor de alojamiento o de quien te la mantiene. En nuestros servidores aplicamos las versiones corregidas el mismo día del anuncio.

2. Si tu web está en una versión antigua, pasarla a una moderna

Para las webs en PHP 8.1 o anterior no basta con un parche: hay que subir a una versión con soporte. Es el cambio que más cuidado requiere, porque una web de hace unos años puede no estar preparada para él. Te lo explicamos más abajo.

3. Mientras tanto, medidas temporales

Para quien no pueda actualizar en el momento, PHP ha publicado unos ajustes de configuración del servidor que reducen el riesgo. Son cosa de tu proveedor o de tu técnico, no de la web, y el propio aviso subraya que no la dejan segura: solo ganan tiempo hasta la actualización.

4. Tener al día WordPress, el tema y los plugins

Actualizar WordPress no corrige este fallo, porque el fallo no está en WordPress. Pero una web con todo al día tiene muchas menos puertas abiertas y, además, es lo que hace posible subir la versión de PHP sin que nada se rompa.

5. Revisar si alguien ha entrado ya, aunque el servidor ya esté actualizado

Este es el punto que más se olvida. Los primeros ataques se detectaron el 17 de octubre, cuatro días antes de que existiera la corrección, y desde el día del anuncio son continuos. Entre ese momento y el día en que tu proveedor aplicó el parche, tu web estuvo expuesta, aunque fueran solo unas horas. Actualizar cierra la puerta, pero no echa a quien ya haya entrado: un intruso que se coló durante ese intervalo sigue dentro con la versión nueva. Por eso, tener hoy una versión corregida no es garantía de que la web esté limpia. Conviene revisar archivos modificados o añadidos, usuarios desconocidos, tareas programadas y contenido extraño, y cambiar las contraseñas de acceso.

Por qué conviene que lo revise un profesional

Subir la versión de PHP parece un clic, y muchas veces lo es. Pero en webs de hace unos años, con un tema o plugins que nadie actualiza desde hace tiempo, ese clic puede dejar la web en blanco o con errores: cada versión nueva de PHP retira piezas antiguas, y lo que dependía de ellas deja de funcionar. Es el motivo por el que muchas webs siguen en versiones viejas: nadie se atrevió a tocarlas.

Un profesional comprueba primero qué usa tu web, hace una copia de seguridad, prueba el cambio en un entorno seguro, actualiza lo que haga falta y, si algo se rompe, lo arregla en lugar de volver a la versión vulnerable. Es el trabajo que hacemos a diario como especialistas en WordPress y PrestaShop, y la razón por la que el mantenimiento de una web no es un gasto de más, sino lo que evita sustos como este.

Qué hemos hecho nosotros

Te lo contamos porque es lo mismo que te recomendamos a ti:

• El mismo 21 de octubre, en cuanto se publicó el aviso, pedimos a nuestro proveedor la confirmación de que nuestros servidores estaban al día. Esa misma tarde quedaron aplicadas las versiones corregidas de PHP en todas las ramas con soporte (8.2 y superiores).
• Además, la función que aprovecha uno de los dos fallos (el progreso de subida de sesiones) quedó desactivada en todas las versiones de nuestros servidores, también en las antiguas, como medida de protección adicional.
• Ese mismo día actualizamos WordPress, la plantilla y los plugins de todas las webs de los clientes que tienen contratado el mantenimiento con nosotros, para que el cambio de versión de PHP no les afectara y no quedara ninguna puerta abierta.
• Avisamos por correo a nuestros clientes de alojamiento y de mantenimiento de lo que habíamos hecho, para que supieran que su web estaba en orden. Y a los clientes cuyas webs están en otros alojamientos les pedimos que preguntaran a su proveedor cuándo aplicaba el parche.
• Ninguna web con mantenimiento tuvo que migrar de versión de PHP: con el mantenimiento recurrente ya estaban en versiones modernas, y eso es justo lo que lo hace fácil cuando salta un aviso así. Sí hemos hecho estos días actualizaciones de emergencia en webs de clientes sin mantenimiento que nos las pidieron a raíz de este incidente.
• Si tu web está en otro alojamiento, pregunta hoy a tu proveedor cuándo aplicó el parche, para saber si hubo un intervalo de exposición.

Preguntas frecuentes sobre PHP2Shell

Fuentes consultadas

Información revisada el 22 de octubre de 2026: aviso de seguridad de PHP del 21/10/2026 y registro de cambios de PHP 8; fichas CVE-2026-109618 y CVE-2026-109619 y avisos GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp; aviso INCIBE-2026-762 de INCIBE-CERT; análisis de Calif; Help Net Security; Tenable; 3Cat; W3Techs; documentación de WordPress.

Etiquetado con: seguridad webvulnerabilidad PHPPHP2Shellactualizar PHPWordPressmantenimiento web