PHP2Shell: qué hacer si tu web está en un hosting
Lo primero que hice al leer la noticia fue mirar mi propia web. No por miedo, sino porque es la que mejor conozco y la que no tengo excusa para tener mal. Tenía cinco ficheros PHP que se podían pedir desde internet y solo necesitaba dos. Eso ya está cerrado. Pero lo importante de PHP2Shell no lo podía arreglar yo, ni puedes arreglarlo tú: lo tiene que arreglar quien te alquila el servidor. Lo que sí está en tu mano es comprobar que lo ha hecho.
Lo que vas a leer
El 21 de octubre el proyecto PHP publicó versiones nuevas para cerrar dos fallos a los que se ha llamado PHP2Shell. Tienen nombre de película y gravedad de 9,2 sobre 10, y no es exageración: permiten tomar el control de un servidor con una sola petición, sin usuario ni contraseña.
Para entender por qué te afecta aunque no sepas qué es PHP, basta con esto: PHP es el programa que hace funcionar WordPress, PrestaShop, Joomla y casi cualquier formulario de contacto. Si tu web hace algo más que enseñar páginas fijas, lo más probable es que funcione con PHP.
Qué ha pasado, en tres fechas
El 17 de octubre un sistema trampa de Amazon registró un intento de ataque con este fallo. Nadie lo había anunciado todavía.
El 20 de octubre se filtraron los detalles antes de tiempo.
El 21 de octubre el proyecto PHP publicó el aviso y las versiones arregladas. Ese mismo día ya se registraban intentos de ataque contra webs reales.
Es decir: cuando la noticia llegó a los periódicos, hacía cuatro días que alguien la estaba usando. Por eso en esta ocasión no vale el «ya lo miraré la semana que viene».
Por qué esta vez no depende de tus plugins
Casi todas las alertas de seguridad que has oído sobre webs pequeñas son de un plugin de WordPress concreto. Se actualiza el plugin y listo.
Esta no. El fallo está en PHP, en el momento en que lee lo que le llega desde internet, antes de que se ejecute una sola línea de tu web. Cuando WordPress arranca, el daño ya está hecho.
Ni WordPress, ni el tema, ni los plugins, ni un plugin de seguridad. Todos se ejecutan después de que PHP haya leído la petición, y el fallo está justo en esa lectura. Lo único que lo arregla de verdad es actualizar PHP en el servidor.
Quién tiene que arreglarlo
Si tu web está en un alojamiento compartido, que es lo normal en un negocio pequeño, el servidor no es tuyo. Es como tener la oficina en un edificio con conserjería: la cerradura de tu puerta la cambias tú, pero las llaves del portal las cambia quien gestiona el edificio. PHP es la cerradura del portal.
Estas son las versiones arregladas, por rama:
| Si tu web usa… | Versión arreglada | Situación |
|---|---|---|
| PHP 8.5 | 8.5.12 | Arreglo oficial |
| PHP 8.4 | 8.4.27 | Arreglo oficial |
| PHP 8.3 | 8.3.36 | Arreglo oficial |
| PHP 8.2 | 8.2.35 | Arreglo oficial |
| PHP 7.4, 8.0 y 8.1 | Ninguna oficial | Solo parches sueltos que tiene que aplicar tu proveedor |
| PHP 7.3 o anterior | Ninguna | Sin arreglo |
La última fila es la que preocupa. El 20 de octubre había unos 884.000 servidores en internet que anunciaban PHP 8.1 o anterior. Muchas webs siguen ahí porque nadie se acordó de subir la versión, y en esas el arreglo depende por completo de que el proveedor haya hecho el trabajo extra.
Los proveedores grandes se movieron rápido. Entre el 21 y el 22 de octubre, unos parchearon sin que se notara y otros prefirieron desconectar el servicio unas horas antes que dejarlo expuesto. Lo que no puedes hacer es dar por hecho que el tuyo lo ha hecho. Hay que comprobarlo.
Lo que te toca hacer hoy
Son cinco cosas, y ninguna exige saber programar.
1. Mira qué versión de PHP tiene tu web. En el panel del alojamiento suele haber un apartado llamado PHP. Si pone 8.1 o algo anterior, apúntalo: es lo primero que hay que resolver.
2. Pregunta a tu proveedor por escrito. Algo tan sencillo como: «¿Está aplicado el parche de PHP2Shell (CVE-2026-109618 y CVE-2026-109619) en la versión de PHP de mi alojamiento?». Por escrito, para que quede constancia. Mira también su página de estado, que es donde suelen anunciarlo.
3. Si estás en una versión vieja, súbela. A la 8.3 o la 8.4. Haz antes una copia de seguridad y prueba la web después, porque un plugin antiguo puede no llevarse bien con la versión nueva. No lo hagas un viernes a última hora.
4. Haz inventario de lo que hay colgado. Esto es lo que más se olvida. La copia de la web anterior que se quedó en una carpeta, la tienda de un subdominio que ya no se usa, la instalación de pruebas de hace tres años. Todo eso está en el mismo alojamiento y tiene la misma puerta. Lo que no uses, que lo quite quien sepa lo que hay dentro.
5. Busca señales de que alguien ha entrado. El parche cierra la puerta, pero no echa a quien ya estuviera dentro. Fíjate en ficheros que tú no has subido, usuarios administradores que no reconoces o tareas programadas nuevas en el panel.
Lo que he hecho en mi propia web
Te lo cuento porque es un caso real y pequeño, como el tuyo. Esta web es casi toda HTML fijo, pero el formulario de contacto funciona con PHP.
Tenía cinco ficheros PHP que se podían pedir desde internet. Solo dos necesitan estar a la vista: el que recibe tu mensaje y el que lo protege del correo basura. Los otros tres siguen funcionando por dentro, pero ahora el servidor los rechaza antes de que PHP llegue a verlos. Además, el formulario enviaba los datos en el formato que se usa para adjuntar ficheros, sin necesitarlo, y ese formato es justo una de las puertas del fallo. Lo he cambiado, y el servidor ya no acepta otro.
Hay que decirlo claro: esto reduce por dónde se puede entrar, pero no sustituye al parche. Los especialistas que han analizado el fallo avisan de que los ajustes de configuración no bastan por sí solos. El arreglo de verdad le toca a mi proveedor, igual que al tuyo. Mi alojamiento lleva tiempo en PHP 8.5, así que no me toca subir de versión: me toca confirmar que está en la 8.5.12 o posterior, que es lo mismo que te digo que hagas tú.
Lo que no conviene hacer
No compres un plugin que «te protege de PHP2Shell». Un plugin se ejecuta dentro de WordPress, y el fallo ocurre antes. Si alguien te lo ofrece, desconfía.
No cambies de alojamiento a la carrera. Mudar una web con prisas es una buena forma de romperla. Primero confirma si el tuyo ha parcheado: los grandes lo hicieron en uno o dos días.
No lo dejes en «seguro que no me toca». Los ataques de este tipo no buscan tu web en concreto. Recorren internet probando direcciones de forma automática, y una web pequeña de Logroño cae igual que la de una multinacional si tiene la puerta abierta.
Si prefieres que lo mire alguien, en el mantenimiento web esto es justo lo que hago cada mes: versión de PHP, parches, copias y lo que haya colgado donde no debería. Y si tu web lleva tiempo sin que nadie la toque, te interesa leer lo que envejece solo en una web parada.
Dime la dirección de tu web y te digo cómo está
Si no sabes qué versión de PHP tiene tu web, ni si tu proveedor ha aplicado el parche, lo miramos juntos. Reviso también lo que haya colgado en el mismo alojamiento, que es donde suele estar el problema. Sin coste y sin compromiso.
Rolando Díaz Hernández
Informático autónomo en Logroño, con más de 30 años de oficio. Gestiona cuentas de vendedor de Amazon en cuatro marketplaces europeos, implanta inteligencia artificial en empresas, hace webs a mano y es distribuidor oficial de Facturandoo. Escribe sobre lo que le pasa trabajando, no sobre lo que ha leído.
Fuentes
- Tenable, preguntas frecuentes sobre PHP2Shell. De ahí salen las fechas, la gravedad de 9,2 sobre 10, las versiones afectadas y arregladas, la situación de PHP 7.4 a 8.1 y las mitigaciones que publicó el proyecto PHP. Consultado el 22 de octubre de 2026.
- Help Net Security, PHP2Shell: vulnerabilidades críticas de PHP parcheadas. De ahí salen la explicación de los dos fallos y el intento de ataque registrado por Amazon el 17 de octubre, cuatro días antes de hacerse público. Consultado el 22 de octubre de 2026.
- watchTowr, explotación de PHP2Shell. De ahí salen que el ataque puede tener éxito antes de que se ejecute el código de la web, que los cambios de configuración no bastan y qué señales revisar después. Consultado el 22 de octubre de 2026.
- TuxCare, guía de parcheo de PHP2Shell. De ahí sale el recuento de unos 884.000 servidores que anunciaban PHP 8.1 o anterior el 20 de octubre, con su advertencia de que el anuncio no confirma la exposición. Consultado el 22 de octubre de 2026.
- Severint, cómo reaccionaron los proveedores de alojamiento alemanes. De ahí sale el resumen de lo que hicieron los distintos proveedores el 21 y el 22 de octubre, desde parchear sin cortes hasta desconectar el servicio. Consultado el 22 de octubre de 2026.
- Hosttest, lo que los clientes de alojamiento tienen que saber sobre PHP2Shell. De ahí sale la división de tareas entre proveedor y cliente en un alojamiento compartido. Consultado el 22 de octubre de 2026.
Imagen de cabecera: ilustración generada con inteligencia artificial.