Si tienes una web hecha con WordPress, PrestaShop, Moodle o casi cualquier gestor de contenidos, funciona con PHP. Y PHP ha tenido en octubre de 2026 uno de los fallos más serios de su historia: dos vulnerabilidades, bautizadas como php2shell, que permiten a un desconocido ejecutar código en tu servidor sin usuario ni contraseña.
Esta guía no es un manual técnico para administradores de sistemas. Es lo que yo haría si fuera el dueño de una web, una tienda o un despacho y quisiera saber dos cosas: si estoy expuesto y qué pasa con mi reputación si ya han entrado.
Qué ha pasado, con fechas
- 17 de octubre. Amazon detecta los primeros intentos de explotación, cuatro días antes de que el fallo se haga público.
- 20 de octubre. El equipo de PHP anuncia una actualización de seguridad crítica para el día siguiente.
- 21 de octubre. Salen las versiones corregidas: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Ese mismo día la agencia de ciberseguridad de Estados Unidos (CISA) pide parchear de inmediato.
- 23 de octubre. PHP informa de un tercer fallo relacionado con las sesiones, CVE-2026-115560, que considera poco probable de explotar y que corregirá en la próxima versión ordinaria.
- 26 de octubre. CISA añade los dos fallos principales a su catálogo de vulnerabilidades explotadas de forma activa.
Los dos fallos principales son el CVE-2026-109618 y el CVE-2026-109619, ambos con una puntuación de 9,2 sobre 10. Lo que los hace tan peligrosos es el momento en que ocurren: PHP los procesa al recibir la petición, antes de que se ejecute una sola línea de tu web. Da igual que tengas el WordPress al día, un plugin de seguridad o contraseñas largas. Si la versión de PHP del servidor no está corregida, la puerta está abierta.
Cómo saber si tu web está expuesta
Lo único que importa es la versión de PHP que usa el servidor para servir tu web. No la de tu ordenador ni la que pone en el plugin.
| Rama de PHP | Versión corregida | Qué hacer |
|---|---|---|
| 8.5 | 8.5.12 o posterior | Comprobar que el servidor ya la tiene |
| 8.4 | 8.4.27 o posterior | Igual |
| 8.3 | 8.3.36 o posterior | Igual |
| 8.2 | 8.2.35 o posterior | Actualizar ya y planificar el salto: la rama 8.2 deja de tener soporte el 31 de diciembre de 2026 |
| 8.1, 8.0, 7.4 o anteriores | Sin versión oficial | Preguntar al proveedor si ha aplicado parche propio y, si no, migrar |
Tres formas de comprobarlo, de más fácil a más técnica:
- Pregunta a tu hosting. Un correo de una línea: «¿Qué versión de PHP sirve mi dominio y tiene ya los parches de php2shell del 21 de octubre?». Los proveedores serios llevan días actualizando y suelen responder rápido.
- Mira el panel de tu hosting. Casi todos tienen un apartado de versión de PHP por dominio.
- En WordPress, en Herramientas, Salud del sitio, pestaña Información, apartado Servidor, aparece la versión de PHP.
Ojo con una trampa habitual: algunas distribuciones de Linux aplican el parche sin cambiar el número de versión. Si tu servidor muestra una versión antigua pero tu proveedor te dice que está parcheada, pídele que te lo confirme por escrito.
Nosotros también usamos PHP. Lo primero que hicimos el día 21 fue comprobar que nuestro servidor ya tenía la versión corregida. Te recomiendo hacer lo mismo hoy, no la semana que viene.
Si no puedes actualizar todavía
El aviso oficial de PHP es claro: ninguna medida provisional sustituye a la actualización. Mientras tanto, tu proveedor puede desactivar `session.upload_progress.enabled` en la configuración del servidor (no desde tu web), limitar el tamaño de las peticiones y reiniciar los procesos de PHP. Reduce el riesgo, no lo elimina.
Señales de que han podido entrar
Hubo explotación desde el 17 de octubre, así que actualizar no basta si tu web estuvo expuesta esos días. Hay que mirar atrás. Estas son las señales que vemos con más frecuencia cuando una web ha sido comprometida, sea por este fallo o por otro:
- Aparecen en Google páginas de tu dominio que no has creado, muchas veces en japonés o con productos de farmacia, réplicas o apuestas. Haz la búsqueda `site:tudominio.es` y revisa los resultados.
- Google muestra bajo tu web un aviso de que el sitio puede haber sido hackeado, o Chrome enseña una pantalla roja al entrar.
- Search Console te envía un correo de «Problemas de seguridad».
- Tus clientes reciben correos o SMS en tu nombre que tú no has enviado.
- Hay usuarios administradores nuevos, ficheros PHP recientes en carpetas de imágenes o tareas programadas que nadie recuerda haber creado.
- En los registros del servidor aparecen errores de memoria agotada en «Unknown on line 0» o caídas de procesos con «Segmentation fault» desde mediados de octubre. Esto lo tiene que revisar tu técnico o tu hosting, pero merece la pena preguntar por ello en concreto.
Ninguna señal es una prueba por sí sola. Varias juntas, sí deberían hacerte actuar.
Si han entrado: el orden en que yo lo haría
1. Guardar pruebas antes de limpiar
La reacción natural es borrar todo lo raro cuanto antes. Es un error. Si luego hay que denunciar, reclamar al proveedor o demostrar ante la AEPD que actuaste con diligencia, necesitarás saber qué pasó y cuándo. Pide a tu hosting una copia completa de ficheros, base de datos y registros tal como están ahora, y guarda capturas con fecha de los resultados de Google y de los avisos. Si el caso puede acabar en un juzgado, lo correcto es certificarlo, como explicamos en cadena de custodia y evidencias digitales.
2. Cerrar la puerta y limpiar
Actualizar PHP, cambiar todas las contraseñas (panel del hosting, FTP, base de datos, administradores de la web, correo), revisar usuarios y restaurar desde una copia anterior al 17 de octubre si la hay. Restaurar una copia sin haber actualizado PHP antes solo sirve para que vuelvan a entrar.
3. Decidir si hay brecha de datos personales
Aquí es donde mucha gente se equivoca. Si en tu web había datos de clientes (formularios de contacto, pedidos, cuentas de usuario, historiales, currículums) y el atacante pudo acceder a ellos, eso es una brecha de datos personales según el RGPD, aunque no tengas pruebas de que se los llevó.
- A la AEPD: el artículo 33 del RGPD obliga a notificarla en un plazo de 72 horas desde que tienes conocimiento de la brecha, salvo que sea improbable que suponga un riesgo para las personas. Se hace en la sede electrónica de la AEPD, y la propia Agencia tiene una herramienta, Comunica-Brecha RGPD, que ayuda a decidir si hay que comunicarla también a los afectados.
- A los afectados: el artículo 34 exige avisarles cuando el riesgo sea alto, por ejemplo si había contraseñas, datos de salud, documentos de identidad o datos bancarios.
No tener toda la información no es motivo para esperar. El RGPD permite notificar por fases: primero lo que sabes y después lo que vayas averiguando. Lo que sí pesa en contra es callar. Si quieres ver cómo se tramita algo ante la Agencia, tenemos una guía de la reclamación ante la AEPD paso a paso.
Para dudas técnicas, el teléfono 017 de INCIBE atiende gratis a empresas y particulares.
4. Pedir a Google que retire los avisos
Cuando la web está limpia, en Search Console, apartado Seguridad y acciones manuales, Problemas de seguridad, hay un botón para solicitar una revisión. Explica qué hiciste en concreto (versión de PHP actualizada, ficheros eliminados, contraseñas cambiadas). Si la revisión sale bien, el aviso desaparece de los resultados, normalmente en unos días.
Las páginas basura que metieron en tu dominio pueden seguir apareciendo un tiempo. Si ya devuelven error 404 o 410, Google las irá retirando; para las más visibles puedes usar la herramienta de retirada de URL de la propia Search Console.
Lo que más daña la reputación en estos casos
Por lo que vemos en los casos que nos llegan, el daño casi nunca viene del ataque en sí. Viene de lo que el cliente ve después: un aviso rojo de Google al buscar tu marca, correos fraudulentos con tu logotipo, o una noticia o un comentario en redes que cuenta que tus datos se filtraron y que tú no dijiste nada.
Tres cosas reducen mucho ese daño:
- Avisar tú primero. Un correo claro a tus clientes, sin tecnicismos ni excusas, diciendo qué ha pasado, qué datos pueden estar afectados y qué deben hacer (cambiar la contraseña, desconfiar de correos que pidan pagos). El que se entera por otro tiende a pensar lo peor.
- Tener preparada una respuesta corta para quien pregunte por teléfono, redes o reseñas, y que todo el equipo diga lo mismo.
- Vigilar qué se publica sobre tu marca en las semanas siguientes. Las listas de datos robados acaban a veces en foros o en canales de Telegram, y hay que detectarlo pronto para pedir su retirada.
Si el asunto ya ha salido a la luz, la guía de crisis reputacional en las primeras 72 horas sirve casi tal cual, y en filtración de datos tras un hackeo explicamos cómo actuar si tus datos o los de tus clientes aparecen publicados.
Lo que no podemos hacer, y lo que sí
Somos una agencia de reputación, no una empresa de ciberseguridad. No vamos a limpiar tu servidor; eso lo hace tu hosting o un técnico de sistemas. Lo que sí hacemos es lo que viene después: conseguir que Google retire avisos y resultados basura, localizar y pedir la retirada de datos filtrados, preparar la comunicación con clientes y prensa y, con el despacho de abogados con el que trabajamos, valorar las acciones legales que procedan.
Si tu web ha sido atacada y no sabes por dónde empezar, cuéntanoslo en el diagnóstico gratis. Si vemos que lo tuyo es solo técnico, te lo diremos y no te haremos perder el tiempo.
