--- title: "PHP2Shell: qué es y cómo proteger tu web | WebBarberà" description: "PHP2Shell son dos fallos críticos de PHP que permiten tomar el control de una web sin contraseña. Qué supone para tu negocio y qué revisar hoy mismo." url: https://webbarbera.com/blog/php2shell-vulnerabilidad-php/ --- [Blog](https://webbarbera.com/blog/)Hosting # PHP2Shell: la vulnerabilidad de PHP que pone en riesgo tu web (y qué hacer ya) ![Ilustración de un escudo con un candado abierto junto a una terminal que muestra las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 de PHP y la versión ya corregida](https://webbarbera.com/blog/php2shell.webp) El pasado 21 de octubre, el equipo que mantiene PHP publicó una actualización con un titular que no se ve a menudo: _vulnerabilidades críticas, actualiza ya_. Si tu web está hecha con WordPress, WooCommerce, PrestaShop, Joomla o cualquier otro gestor basado en PHP —es decir, la mayoría de webs de pymes—, esto va contigo. Te lo cuento sin tecnicismos: qué ha pasado, por qué es más serio que los avisos de siempre y qué tienes que comprobar esta misma semana. ## Qué es PHP2Shell, en pocas palabras PHP es el lenguaje con el que funcionan por dentro la mayoría de webs del mundo. Cada vez que alguien entra en una web hecha con WordPress, es PHP quien, en el servidor, monta la página y se la entrega al visitante. **PHP2Shell** es el nombre con el que se conocen dos fallos de seguridad del propio PHP, registrados como **CVE-2026-109618** y **CVE-2026-109619**. Los dos tienen una gravedad de **9,2 sobre 10** y el nombre lo resume bien: permiten pasar de “PHP” a una _shell_, es decir, a ejecutar código en tu servidor con los mismos permisos que tu web. Lo peor es que **no hace falta usuario ni contraseña**. Basta con enviar al servidor peticiones preparadas a propósito. Para que te hagas una idea: no es que alguien haya robado una llave, es que la cerradura se puede abrir desde fuera sabiendo dónde empujar. Para los curiosos: uno de los fallos aparece cuando PHP se queda sin memoria a mitad de preparar una petición y deja datos internos a medio construir; el otro hace que restos de una visita se reutilicen en la siguiente que atiende el mismo proceso. Los dos acaban igual: código ajeno ejecutándose en tu servidor. ## Por qué este aviso no es como los de siempre Si tienes WordPress, estarás acostumbrado a los avisos de “actualiza este plugin”. Este es diferente por tres motivos: 1. **El fallo no está en tu web, está en el motor.** Actualizar WordPress, el tema o los plugins **no lo arregla**. Lo que hay que actualizar es PHP, que vive en el servidor y que normalmente gestiona tu proveedor de alojamiento. 2. **Afecta a casi cualquier forma de ejecutar PHP**: PHP-FPM, Apache con mod\_php, CGI, LiteSpeed… Según los propios desarrolladores de PHP, cualquier instalación que sirva páginas web está en riesgo, y el riesgo es máximo con mod\_php, donde el ataque puede funcionar incluso antes de que llegue a ejecutarse el código de tu web. 3. **No hubo margen.** Los detalles se filtraron el 20 de octubre, antes de la fecha prevista, y PHP tuvo que adelantar un día la publicación del parche. Ese mismo 21 de octubre, investigadores de seguridad ya detectaron intentos de explotación en sus servidores trampa. Hablamos de horas, no de semanas. ## Qué versiones de PHP están a salvo | Si tu web usa… | Versión segura | | ------------------ | --------------------------------------------------------------- | | PHP 8.5 | 8.5.12 o superior | | PHP 8.4 | 8.4.27 o superior | | PHP 8.3 | 8.3.36 o superior | | PHP 8.2 | 8.2.35 o superior | | PHP 8.1, 8.0 o 7.4 | Sin versión oficial: solo si tu proveedor ha aplicado el parche | | PHP 7.3 o anterior | Sin arreglo: toca actualizar sí o sí | Con las versiones antiguas, el número **engaña**. PHP 8.1 y anteriores ya no reciben actualizaciones oficiales, así que el parche lo aplican por su cuenta las distribuciones de Linux y los paneles de alojamiento… **sin cambiar el número de versión**. En Plesk, por ejemplo, el PHP 8.1.34 corregido se sigue llamando 8.1.34; lo que cambia es la fecha de compilación. Así que, si tu web va con una versión antigua, ver “8.1.34” no te dice si estás protegido: hay que preguntarlo. Y un detalle que se le escapa a mucha gente: si tu servidor usa **Plesk**, el propio panel funciona con su propio PHP, independiente del de las webs. Plesk lo corrigió en las actualizaciones 18.0.80 Update 11 y 18.0.81 Update 4\. Actualizar el PHP de las webs no actualiza el del panel, ni al revés. ## Qué le puede pasar a tu negocio si alguien entra Un servidor comprometido no siempre “se cae”. Muchas veces al atacante le interesa pasar desapercibido y sacarle partido. Lo habitual es esto: * **Tu web empieza a redirigir a estafas** o se llena de páginas de spam que Google acaba indexando con tu dominio. * **Google o el navegador la marcan como peligrosa**, y las visitas —y las ventas— se hunden de un día para otro. * **Te roban datos**: mensajes de formularios, pedidos de la tienda online, fichas de clientes. * **Usan tu servidor para enviar spam**, y tus correos de verdad empiezan a acabar en la carpeta de correo no deseado de tus clientes. Además, si hay datos personales afectados, el RGPD te obliga a notificarlo a la Agencia Española de Protección de Datos en un **máximo de 72 horas** desde que te enteras, salvo que sea improbable que suponga un riesgo para las personas (y, si el riesgo es alto, también hay que avisar a los afectados). Limpiar un servidor, recuperar la reputación en Google y dar explicaciones a los clientes cuesta muchísimo más que una actualización a tiempo. ## Qué hacer esta semana: lista de comprobación 1. **Averigua qué versión de PHP usa tu web.** En WordPress la tienes en _Herramientas → Salud del sitio → Información → Servidor_. Si tienes acceso a Plesk, en la configuración de PHP de tu dominio. 2. **Pide a tu proveedor de alojamiento una confirmación por escrito**: si el PHP de tu web y el del panel ya están parcheados, y desde qué fecha. En un alojamiento compartido no puedes actualizar PHP tú mismo; es responsabilidad suya. 3. **Si vas con PHP 7.4, 8.0 u 8.1, planifica el salto a 8.3 u 8.4.** El parche del proveedor te saca del apuro, pero esas versiones ya no reciben mantenimiento oficial. Antes de cambiar, prueba en una copia que tu tema y tus plugins son compatibles. 4. **Después de actualizar, prueba lo que te da dinero**: formularios, carrito y pago, reservas, conexiones con otras herramientas. 5. **Busca señales raras**: usuarios administradores que no conoces, archivos `.php` dentro de la carpeta de imágenes (`wp-content/uploads`), redirecciones extrañas o avisos nuevos en Google Search Console. 6. **Ten [copias de seguridad](https://webbarbera.com/servicios/#copias-seguridad) fuera del servidor y comprueba que se pueden restaurar.** Si algo ha ido mal, una copia limpia de antes del ataque es tu mejor salvavidas. Si gestionas tu propio servidor y no puedes actualizar todavía, PHP recomienda como medida temporal desactivar `session.upload_progress` y reiniciar los procesos de PHP. Ellos mismos avisan de que no es una solución completa: la única solución de verdad es el parche. Y si sospechas que ya te han atacado, no lo dejes para mañana: cambia las contraseñas (panel, FTP, base de datos y WordPress), restaura una copia limpia y, si necesitas orientación, llama al **017**, la línea gratuita de ayuda en ciberseguridad del INCIBE para empresas y particulares. ## ¿Y si mi web es estática? Una web estática —como las que hago con Astro— entrega al visitante archivos HTML ya preparados: no hay PHP ejecutándose en cada visita, así que **esta vulnerabilidad no tiene por dónde entrar a través de la web**. Es una de las ventajas de las que hablé al comparar [Astro y WordPress](https://webbarbera.com/blog/astro6-vs-wordpress/). Pero no quiero venderte humo: que la web sea estática no hace invulnerable al servidor. Si en el mismo alojamiento hay un panel como Plesk, un blog en WordPress o un formulario en PHP, todo eso también hay que tenerlo al día. ## La lección que deja PHP2Shell Una web no es algo que se hace una vez y se olvida. Detrás hay un servidor, un lenguaje, un panel, un gestor de contenidos y sus plugins, y cada pieza necesita su mantenimiento. La pregunta importante no es “¿mi web es segura?”, sino **“¿quién se encarga de actualizar cada pieza, y cómo me entero de que lo ha hecho?”**. Si no tienes clara la respuesta, ese es el primer agujero que hay que tapar. ¿No sabes qué versión de PHP usa tu web o quién la mantiene? [Escríbeme](https://webbarbera.com/contacto/) y lo miramos juntos. Y si estás pensando en cambiar de alojamiento, aquí tienes [mis planes](https://webbarbera.com/alojamiento/), con SSL, copias de seguridad automáticas y soporte técnico. **Fuentes:** * [Aviso de seguridad oficial de PHP (21 de octubre de 2026)](https://www.php.net/archive/2026.php#2026-10-21-5) * [Seguimiento de PHP2Shell del NCSC de los Países Bajos](https://github.com/NCSC-NL/php2shell) * [Registro de cambios de Plesk](https://docs.plesk.com/release-notes/obsidian/change-log/) * [Correcciones de PHP2Shell en Ubuntu](https://ubuntu.com/blog/php2shell-vulnerability-fixes-available) Más sobre esto [Planes de alojamiento web →](https://webbarbera.com/alojamiento/)[Servicios web completos →](https://webbarbera.com/servicios/) ¿Hablamos? ## ¿Tu web y tu alojamiento están al día? Cuéntame dónde está alojada tu web y con qué está hecha, y te digo qué conviene revisar para mantenerla segura. [Contactar ahora →](https://webbarbera.com/contacto/)