Casi todas las webs del mundo funcionan sobre un programa llamado PHP. Es el motor que, cada vez que alguien entra en una página, se encarga de construir lo que ese visitante ve. WordPress está escrito en PHP, igual que PrestaShop, Joomla o la mayoría de desarrollos a medida.
El 21 de octubre de 2026 los responsables de ese programa publicaron una actualización de urgencia. Habían aparecido dos fallos graves. La vulnerabilidad de PHP que se conoce como PHP2Shell permite que alguien desde fuera ejecute órdenes dentro del servidor, sin contraseña y sin tener ninguna cuenta en la web.
Los expertos puntúan su gravedad con un 9,2 sobre 10. Y no es un riesgo teórico: hay ataques reales en marcha desde el mismo día en que el fallo se hizo público. Por eso conviene revisarlo cuanto antes.
Este artículo explica, sin tecnicismos, qué versiones están afectadas, cómo comprobar la de tu web y qué hacer en cada caso.
Qué es PHP2Shell
PHP2Shell es el apodo que ha recibido esta vulnerabilidad de PHP. En realidad son dos fallos distintos, catalogados como CVE-2026-109618 y CVE-2026-109619. Los CVE son los códigos con los que el sector identifica cada fallo conocido, igual que una matrícula.
La explicación sencilla es esta: en determinadas situaciones PHP se queda sin memoria mientras atiende una visita y deja piezas internas a medio montar. El programa las da por buenas y sigue trabajando con ellas. Alguien que sepa provocar ese momento puede colar sus propias instrucciones entre esas piezas.
El resultado de esta vulnerabilidad de PHP es el peor posible. Una sola visita bien preparada basta para que un atacante ejecute lo que quiera dentro del servidor. No necesita robar ninguna contraseña ni engañar a nadie.
Los fallos los encontraron investigadores de la empresa de seguridad Wiz con ayuda de inteligencia artificial, y OpenAI colaboró después en la corrección. El problema fue que los detalles técnicos se filtraron antes de la fecha prevista, y eso dio ventaja a los atacantes.
La cronología explica las prisas. La red de señuelos de Amazon registró un primer intento de ataque el 17 de octubre, cuatro días antes de que el fallo fuera público. Es decir, hubo servidores expuestos incluso antes de que existiera la solución.
Qué versiones están afectadas por la vulnerabilidad de PHP
Aquí está la mayor confusión, porque esta vulnerabilidad de PHP no se limita a versiones antiguas. Las versiones de PHP afectadas abarcan todas las que hoy están en uso. Solo estas cuatro están corregidas:
| Rama de PHP | Versiones afectadas | Versión corregida |
|---|---|---|
| PHP 8.5 | Anteriores a 8.5.12 | 8.5.12 |
| PHP 8.4 | Anteriores a 8.4.27 | 8.4.27 |
| PHP 8.3 | Anteriores a 8.3.36 | 8.3.36 |
| PHP 8.2 | Anteriores a 8.2.35 | 8.2.35 |
| PHP 8.1, 8.0 y 7.4 | Todas | Sin versión oficial |
| PHP 7.3 y anteriores | Todas | Sin solución |
Las versiones 8.1 y anteriores ya no reciben soporte oficial, así que no existe una actualización para ellas. Aun así, algunas empresas de alojamiento y ciertas distribuciones de Linux han incorporado la corrección a sus propios paquetes por su cuenta.
Por eso el número de versión puede engañar. Un servidor que muestre 8.5.11 puede estar ya protegido, si su proveedor aplicó el parche sobre esa misma versión. O puede no estarlo. La única forma de salir de dudas es preguntárselo directamente al proveedor.
Tampoco importa cómo esté montado el servidor por dentro: todas las configuraciones habituales están afectadas por esta vulnerabilidad de PHP. En unas el riesgo es mayor que en otras, pero ninguna se libra.
Cómo comprobar la versión de PHP de una web
Para saber si tu sitio está expuesto a esta vulnerabilidad de PHP tienes tres caminos, de menos a más fiable:
- Desde WordPress. Entra en Herramientas, Salud del sitio, pestaña Información y abre el apartado Servidor. Ahí aparece la versión de PHP que usa tu web.
- Desde el panel de tu hosting. Casi todos los paneles tienen una sección para ver y cambiar la versión de PHP del dominio.
- Preguntando a tu proveedor. Es la única vía que confirma si el parche está puesto, porque, como acabamos de ver, el número de versión puede no reflejarlo.
Un ejemplo concreto: esta web funciona sobre PHP 8.4.27, que es la versión ya corregida de su rama frente a esta vulnerabilidad de PHP.
Por qué actualizar WordPress no resuelve esta vulnerabilidad de PHP
Es la duda más repetida estos días. WordPress no está afectado y no va a publicar ninguna actualización por este motivo, porque el fallo no está en WordPress sino en el programa que lo hace funcionar por debajo.
Una comparación sencilla: WordPress sería el coche y PHP, el motor. El ataque de esta vulnerabilidad de PHP ocurre dentro del motor, antes de que el coche llegue a arrancar. Por eso actualizar el núcleo, los plugins o la plantilla no te protege de este problema concreto. Hay que hacerlo igual, pero por otras razones.
Qué hacer ante la vulnerabilidad de PHP según el alojamiento
Si tienes un hosting gestionado, es decir, uno en el que el proveedor se ocupa del servidor por ti, lo normal es que aplique el parche de la vulnerabilidad de PHP sin que tengas que hacer nada. Aun así, confírmalo: mira su página de estado o escribe a soporte. No lo des por hecho.
Si tienes un hosting compartido, el plan económico en el que conviven varias webs en la misma máquina, la actualización suele llegar poco a poco. Mientras tanto, desde el panel de control puedes cambiar tú mismo la versión de PHP de tu dominio a una corregida. Eso sí: pruébalo antes en una copia de la web, porque algún plugin antiguo puede dejar de funcionar.
Si tienes un servidor propio o un VPS, el responsable eres tú o quien te lo administre. Hay que actualizar los paquetes de PHP y reiniciar el servicio de inmediato. Y si la web va sobre PHP 8.1 o una versión anterior, toca planificar el salto a 8.2 o superior, probándolo antes fuera de producción.
Medidas que no sustituyen al parche
El propio equipo de PHP lo ha dicho sin rodeos: ningún ajuste de configuración resuelve del todo esta vulnerabilidad de PHP. Desconfía, por tanto, de cualquier receta que prometa cerrar el problema tocando un archivo.
- Cortafuegos. Cloudflare activó reglas de bloqueo para todos sus planes, incluido el gratuito. Ayuda a frenar ataques, pero no cierra el agujero.
- Limitar el acceso. Es la única medida provisional que el proyecto reconoce como eficaz. Varios organismos oficiales han recomendado desconectar los servidores que no puedan actualizarse ya.
- Comprobarlo desde fuera. Existe una herramienta gratuita, php2shell-scanner, que dice si un servidor sigue expuesto.
Cómo saber si un sitio ha sido comprometido
Aplicar el parche de la vulnerabilidad de PHP cierra la puerta, pero no echa fuera a quien ya hubiera entrado. Si tu web estuvo expuesta, conviene revisar algunas señales. Por ejemplo: archivos nuevos o modificados sin explicación, usuarios administradores que nadie ha creado, tareas programadas que no reconoces, visitantes redirigidos a otras webs o un consumo de datos inusual.
Si aparece cualquiera de estas señales, lo prudente es restaurar una copia de seguridad anterior al 17 de octubre sobre un servidor ya actualizado y cambiar después todas las contraseñas y claves de acceso.
Por qué esto es mantenimiento web y no una incidencia aislada
Un caso así enseña la diferencia entre una web mantenida y una web que simplemente está publicada. La diferencia no está en haber reaccionado rápido el 21 de octubre, sino en todo lo que ya estaba resuelto antes de esa fecha.
- Saber en todo momento qué versión de PHP usa cada proyecto y mantenerla dentro del soporte oficial.
- Tener copias de seguridad probadas, lo bastante antiguas como para poder retroceder más de cuatro días.
- Disponer de una copia de la web donde ensayar un cambio sin tocar la versión que ven los visitantes.
- Tener un interlocutor en la empresa de alojamiento y saber dónde consultar su página de estado.
- Revisar cada cierto tiempo los archivos y los usuarios con permisos de administrador.
Una web que cumple estos cinco puntos resuelve una vulnerabilidad de PHP como esta en una mañana. Una que no los cumple descubre, en el peor momento, que va sobre una versión sin soporte, que la última copia de seguridad es de hace dos meses y que nadie recuerda quién administra el servidor.
Preguntas frecuentes
¿Afecta esta vulnerabilidad de PHP a todas las webs?
Esta vulnerabilidad de PHP afecta a cualquier servidor que use PHP para atender visitas, sea cual sea el gestor de contenidos. Como PHP está detrás de unas tres de cada cuatro webs del mundo, el alcance es enorme.
¿Basta con actualizar WordPress y los plugins?
No. La vulnerabilidad de PHP está en el motor, no en WordPress. La única solución real es actualizar PHP a una de las cuatro versiones publicadas el 21 de octubre.
¿Qué ocurre con PHP 7.4 o 8.0?
No tienen versión corregida oficial. Algunos proveedores ofrecen paquetes con la corrección incorporada por su cuenta, pero lo recomendable es migrar a 8.2 o superior.
¿Es suficiente con un cortafuegos como Cloudflare?
No. Sus reglas bloquean los ataques ya conocidos y reducen el riesgo, pero el equipo de PHP ha dejado claro que ninguna medida externa sustituye a la actualización.
Frente a esta vulnerabilidad de PHP la recomendación es simple: comprueba hoy mismo qué versión usa tu web y confirma con tu proveedor que el parche está aplicado. Si esa comprobación te resulta difícil de hacer, el problema de fondo no es este fallo concreto, sino la falta de un mantenimiento ordenado.
En Kyber el mantenimiento web forma parte de los proyectos de diseño web: versiones controladas, copias verificadas y un entorno donde probar los cambios antes de aplicarlos. Para revisar el estado de un sitio concreto, puede solicitarse una revisión.
Fuentes: alerta de CISA, análisis técnico de watchTowr y Help Net Security.