Los SEOs ya no podemos ignorar la ciberseguridad

Qué ha pasado con PHP2Shell

El 21 de octubre de 2026, el equipo de PHP publicó un aviso de seguridad con dos fallos críticos, CVE-2026-109618 y CVE-2026-109619. Permiten ejecutar código en el servidor sin iniciar sesión. La corrección pasa por actualizar PHP. Actualizar solo WordPress o sus plugins no corrige estas vulnerabilidades, porque el fallo está en el propio lenguaje de programación, una capa por debajo del CMS.

Los ataques empezaron el mismo día. Patchstack recibió los primeros avisos de explotación a las 07:34 UTC, horas antes de que saliera el parche, y la CISA pidió parchear de inmediato o desconectar lo que no se pudiera parchear. Varios gobiernos desconectaron webs públicas de forma preventiva, según The Record; en Países Bajos, entre otras, DigiD y MijnOverheid.

El alcance es enorme porque PHP está en todas partes. Según W3Techs, a 27 de octubre lo usa el 69,2 % de las webs cuyo lenguaje de servidor se conoce. El riesgo se concentra en las ramas 7.4, 8.0 y 8.1, que están fuera del soporte ordinario. El aviso oficial de PHP incluye parches mínimos excepcionales para ellas y algunos proveedores han publicado sus propias correcciones, pero son justo las versiones en las que se quedan muchas webs de pyme sin mantenimiento, donde nadie se ocupa de aplicar esos parches.

En el SEOmanal ya está la guía para actualizar PHP en Plesk, cPanel y PrestaShop, con cómo hacer la parada con un 503. Este artículo empieza donde termina esa guía: parchear no limpia una intrusión que ya se ha producido.

La seguridad también es trabajo del SEO

Durante años, muchos SEOs hemos tratado la ciberseguridad como cosa de sistemas. Revisamos el rastreo, el contenido y los enlaces, y damos por hecho que el servidor y el CMS los vigila otro. Si alguien preguntaba por un firewall o por las copias, la respuesta era que eso no iba con nosotros.

PHP2Shell deja claro que sí va. Una web infectada puede tirar en días el trabajo de meses o de años. Google retira páginas del índice, marca el resultado como peligroso o aplica una acción manual. Y mientras nadie se da cuenta, la web puede estar sirviendo spam a Googlebot o redirigiendo a los usuarios que llegan desde la SERP.

Lo peor es que el problema rara vez lo detecta primero el SEO. Lo detecta el cliente cuando una caída de tráfico ya es evidente, o Google cuando el daño está hecho. Por eso creo que la seguridad tiene que entrar en nuestra lista de comprobaciones igual que lo hizo en su día el rendimiento.

Con la IA habrá más fallos expuestos, y antes

PHP2Shell no será un caso aislado. El 7 de abril de 2026, Anthropic presentó Project Glasswing, un programa para que grandes empresas tecnológicas usen un modelo de IA restringido para buscar fallos en software crítico. Según la nota de lanzamiento, el coste y el nivel de conocimiento necesarios para encontrar y explotar vulnerabilidades han bajado de forma drástica.

Esa capacidad sirve para defender, pero también para atacar. Los fallos que antes tardaban años en aparecer van a salir antes. Y el tiempo entre que se publica un fallo y que alguien lo explota en masa se acorta: con PHP2Shell fue de horas.

Para una pyme con un WordPress sin mantenimiento, esto cambia el riesgo. Ya no basta con actualizar «cuando haya tiempo». Los proyectos que no tengan a alguien vigilando las versiones del servidor y del CMS van a quedar expuestos cada vez más a menudo.

Nota de la redacción (6 de noviembre de 2026): OpenSSH acaba de confirmarlo. El 5 de noviembre publicó de urgencia la versión 10.6p2, que corrige un fallo que abría servidores Alpine Linux con cualquier contraseña larga, y avisa de que los agentes de IA redescubren fallos «a veces en cuestión de horas».

Las infecciones que más daño hacen al SEO

No todas las intrusiones buscan lo mismo. Las que más vemos en webs de pyme tienen un objetivo comercial: aprovechar la autoridad de un dominio limpio para posicionar o monetizar otra cosa. Google lo recoge en sus políticas de spam como contenido hackeado, y avisa de que es habitual que el atacante use cloaking para que el propietario no lo vea.

Redirecciones desde el .htaccess

El atacante modifica el .htaccess, o el archivo de configuración equivalente, para redirigir a otra web. Casi nunca redirige a todo el mundo. Lo hace solo con quien llega desde Google, solo en móvil o solo con ciertos navegadores. El propietario entra escribiendo la URL, ve su web normal y no sospecha nada.

El efecto en SEO es doble. Los usuarios que vienen de la SERP rebotan hacia una web fraudulenta, y Google acaba viendo esas redirecciones y marcando el sitio.

Inyección de enlaces y contenido oculto

El código malicioso se cuela en el tema, en un plugin o en la base de datos y añade enlaces a casinos, farmacias, porno o webs de réplicas. A menudo están ocultos con CSS o solo se sirven cuando el user agent es Googlebot. La web parece intacta, pero cada página reparte enlaces a terceros y entra en lo que Google considera enlaces ocultos.

Páginas spam generadas en masa

Es el caso más visible y el que más rápido destroza la indexación. El atacante crea miles de URLs nuevas dentro del dominio con contenido de productos falsificados, farmacia o apuestas. Suele añadir sitemaps propios para que Google las descubra antes.

El caso más conocido es el de las páginas en japonés o en chino, pero no hace falta que el idioma delate el ataque. Es igual de habitual encontrar en la web de una clínica o de un despacho de abogados decenas de URLs en castellano del tipo /casino-online-bono-sin-deposito/ o /apuestas-deportivas-pronosticos/, que se confunden con contenido normal si nadie revisa qué se está indexando.

En pocos días, Search Console muestra un pico de páginas indexadas que nadie ha publicado, consultas que la web no trabaja y una marca que en Google aparece rodeada de spam. Google también recomienda revisar en este caso si hay propietarios desconocidos en Search Console, porque el atacante a veces verifica la propiedad para gestionar esos sitemaps.

Persistencia y puertas traseras

Quitar el spam visible no significa haber echado al atacante. Lo habitual es que, antes de inyectar nada, deje preparada una forma de volver a entrar: una webshell escondida en la carpeta de subidas, un usuario administrador con un nombre discreto, un mu-plugin, una tarea programada que vuelve a generar los archivos o un propietario verificado en Search Console.

Si solo se borran las páginas spam, en pocos días vuelven a aparecer, y Google ve una web que se reinfecta una y otra vez. La limpieza tiene que empezar por cerrar el acceso, no por borrar el contenido.

Search Console avisa tarde y no lo ve todo

Search Console es la herramienta que todos miramos, y tiene dos informes que importan aquí. El informe de problemas de seguridad muestra lo que Google ha detectado como contenido hackeado, malware o ingeniería social, con URLs de ejemplo y el botón para pedir revisión. El informe de acciones manuales recoge las sanciones aplicadas por un revisor. Si Google detecta el problema, el propietario verificado también recibe un correo.

Las consecuencias son serias. Las páginas afectadas pueden salir en la SERP con una etiqueta de aviso, o mostrar una página de advertencia en el navegador antes de entrar. Google también advierte de que arreglar solo una parte de las páginas no sirve: hay que limpiar todo el sitio antes de pedir la revisión.

El problema es que Search Console solo avisa de lo que Google ha detectado, y cuando lo detecta. Hay tres huecos que conviene tener presentes:

• Llega tarde. Cuando aparece el aviso, las URLs spam ya están indexadas y la etiqueta ya está en la SERP. El daño a la marca y al tráfico está hecho.
• No ve todo. Las inyecciones discretas, como unos pocos enlaces ocultos en el pie, pueden pasar meses sin aviso. Según web.dev, algunos avisos de phishing llegan como mensaje y no aparecen en el informe de seguridad.
• El cloaking confunde. Si el contenido malicioso solo se sirve a Googlebot o a quien llega desde Google, al abrir la URL de ejemplo no verás nada raro. Google lo explica en su guía para saber si una web está hackeada: hay que revisar la página como la ve Google, con la inspección de URL.

Un informe de seguridad en verde no significa que la web esté limpia. Significa que Google no ha encontrado nada todavía.

Qué deberíamos hacer los SEOs

No hace falta convertirse en experto en seguridad. Hace falta saber qué riesgos tiene cada proyecto, quién se ocupa de ellos y cómo vamos a enterarnos si algo falla. Esto es lo mínimo que yo pediría en cualquier web que posicionamos.

Antes de que pase

• Saber qué versión de PHP, de CMS y de plugins tiene cada proyecto, y quién los actualiza. Si la respuesta es «nadie», ese es el primer riesgo del proyecto.
• Copias de seguridad automáticas, guardadas fuera del servidor y probadas. Una copia que nunca se ha restaurado no es una copia.
• Tener pensada la alternativa: dónde se levanta la web si hay que aislar el servidor, y cómo se sirve un 503 mientras tanto.

Para detectarlo pronto

• Alertas de cambios en archivos sensibles como el .htaccess, el functions.php del tema o el index.php.
• Un rastreo periódico que compare con el anterior: URLs nuevas que nadie ha creado, enlaces salientes nuevos, redirecciones que antes no estaban.
• Vigilar en Search Console los picos de páginas indexadas, las consultas que la web no trabaja y los usuarios y propietarios de la propiedad.
• Revisar el informe de Enlaces de Search Console aunque el de seguridad esté en verde. Cuando aparecen de repente dominios sospechosos entre los sitios que más enlazan, o URLs propias que nadie ha creado entre las páginas más enlazadas, a menudo es el primer hilo que lleva a una inyección de spam que Google todavía no ha marcado. Una herramienta de enlaces como Ahrefs completa lo que Search Console no da: el informe de dominios enlazados muestra a qué webs enlaza la tuya, y las alertas de enlaces nuevos avisan cuando empiezan a llegar enlaces a URLs que no reconoces.
• Comprobar de vez en cuando la web con la inspección de URL y como usuario que llega desde la SERP en móvil, no solo escribiendo la dirección.

Cuando ya ha pasado

1. Cerrar la puerta: parchear el fallo y cambiar todas las contraseñas y claves, desde el hosting y la base de datos hasta los administradores de la web. Limpiar sin cerrar el acceso solo sirve para que vuelvan a entrar.
2. Limpiar archivos y base de datos siguiendo el proceso del apartado siguiente, o restaurar una copia anterior a la infección si se sabe cuándo empezó.
3. Separar dos tipos de URLs. Las que ha creado el atacante se eliminan. Las páginas legítimas que se infectaron se limpian, se mantienen publicadas y se pide su reindexación con la inspección de URL.
4. Devolver un 404 a las URLs creadas por el atacante. Google trata igual el 404 y el 410; la única diferencia está en la página que ve el usuario si la tienes personalizada. El 410 admite que la página existió, y si la URL tiene un nombre comprometido o ilegal es mejor tratarla como algo que nunca debió existir. No las bloquees en robots.txt: Google necesita rastrearlas para ver que ya no existen.
5. Limpiar Search Console: eliminar los sitemaps que haya añadido el atacante y los propietarios que no reconozcas, junto con sus tokens de verificación. Si el archivo HTML, la metaetiqueta o el registro DNS que usaron sigue ahí, el propietario eliminado puede volver a verificarse. La herramienta de retirada sirve para ocultar las URLs spam de la SERP mientras Google las vuelve a rastrear.
6. Si hay aviso de seguridad o acción manual, pedir la revisión explicando qué ha pasado, qué se ha limpiado y cómo se ha cerrado el acceso.
7. Avisar al cliente desde el principio, con lo que se sabe y lo que se está haciendo.

Cómo limpiar un WordPress infectado

Si la web es un WordPress, que será el caso en buena parte de las webs afectadas por PHP2Shell, este es el orden que recomiendo para limpiarla. Conviene seguirlo completo: cada paso cierra una vía que el anterior deja abierta.

0. Antes de tocar nada

Aislar la web si está sirviendo contenido malicioso (basta con un 503) y hacer una copia completa de archivos, base de datos y registros de acceso. Esa copia es la prueba de lo que pasó y el punto de retorno si algo se rompe durante la limpieza.

1. Descargar el proyecto y trabajar en local

Revisar los archivos en un equipo, sin ejecutar el PHP infectado. La tarea es mucho más sencilla si el proyecto ya estaba bajo un sistema de control de versiones como Git: basta con comparar el estado actual con el último commit limpio para ver qué ha cambiado.

2. Reemplazar el núcleo de WordPress

Comprobar la versión exacta en wp-includes/version.php y descargar ese mismo paquete desde wordpress.org. No basta con sobrescribir: hay que borrar wp-admin y wp-includes enteros y pegar las carpetas nuevas. Si solo se sobrescribe, los archivos que añadió el atacante y que no existen en el núcleo siguen ahí.

Lo mismo vale para los PHP de la raíz (index.php, wp-login.php, wp-load.php, wp-settings.php…). Se conservan wp-config.php y wp-content, pero se revisan aparte. Con WP-CLI, wp core verify-checksums confirma que el núcleo coincide con el oficial.

3. Plugins, temas y mu-plugins con el mismo método

Borrar cada carpeta y reinstalarla desde el repositorio oficial o desde el proveedor legítimo. Si hay algún plugin o tema nulled, es decir, pirata, se elimina por completo: suelen estar detrás de buena parte de las infecciones.

Hay que fijarse también en temas y plugins que nadie instaló. Es habitual que el atacante cree carpetas con nombres creíbles, como wp-cache-xxxx o wp-hc-xxxx, o que meta archivos en subcarpetas de nombre inocente dentro de un tema propio.

Los mu-plugins no tienen fuente oficial, así que se revisan uno a uno y, ante la duda, se eliminan. Lo mismo con los drop-ins de la raíz de wp-content (db.php, advanced-cache.php, object-cache.php), archivos con nombres fijos que WordPress carga antes que cualquier plugin.

4. Buscar código sospechoso

Con un editor que busque en cientos de archivos a la vez (Notepad++ es de los más rápidos para esto), hay que localizar eval(, base64_decode, gzinflate, str_rot13, assert(, create_function, preg_replace con el modificador /e, shell_exec, system(, passthru, cadenas hexadecimales largas (\x41\162…) y líneas de miles de caracteres. Cada resultado se revisa en su contexto, porque muchas de estas funciones aparecen en código legítimo, incluso en el núcleo y en las traducciones.

• Cualquier .php dentro de wp-content/uploads/ es sospechoso, porque ahí solo debería haber archivos multimedia.
• Un .htaccess en una carpeta cualquiera que bloquea todo el PHP excepto una lista de nombres (index.php, 1.php, ok.php…) es la firma típica de una webshell.
• find . -name "*.php" -mtime -60 -ls ayuda a localizar archivos modificados recientemente, aunque las fechas se pueden falsificar.

5. Revisar los usuarios en la base de datos

Revisar wp_users y los roles en wp_usermeta (wp_capabilities) para comprobar que no hay administradores ni privilegios que no deberían estar. El prefijo de las tablas puede no ser wp_. Hay que revisar también las contraseñas de aplicación y cerrar todas las sesiones abiertas.

6. Revisar el resto de la base de datos con ayuda de la IA

Exportar wp_options y wp_posts y pedir a una IA que señale código, scripts, iframes, contenido codificado o enlaces que no encajen con la web. Si es una tienda, ojo con lo que se exporta: en WooCommerce los pedidos pueden estar en wp_posts con datos personales de clientes, y esos no se deben pasar a ninguna herramienta externa.

7. Comprobar que el contenido se corresponde con la realidad

Comparar entradas y páginas con lo que el cliente ha publicado de verdad: URLs que nadie creó, enlaces ocultos, redirecciones y sitemaps añadidos. Después, ya con la web limpia publicada, hay que mirarla como la ve Google y como un usuario que llega desde la SERP en móvil, porque el cloaking oculta la infección al propietario.

Las DevTools del navegador permiten cambiar el user agent por el de Googlebot, pero algunas infecciones son tan sofisticadas que filtran por IP y no se activan con ese truco. En ese caso, la prueba de resultados enriquecidos de Google o la prueba en directo de la inspección de URL muestran el HTML que recibe Google desde sus propias IP. La inspección tiene un límite diario de pruebas, así que conviene reservarla para las URLs clave.

8. Cerrar la puerta

Activar la doble verificación en el acceso a WordPress. Desde un equipo limpio, cambiar las contraseñas de WordPress, de la base de datos, del FTP o SSH y del panel del hosting, y regenerar las claves salt; en la práctica, hacer un wp-config.php nuevo. Fuera de WordPress hay que revisar:

• las tareas programadas del servidor y las de WP-Cron;
• las claves SSH autorizadas, incluidas las de despliegue de Git del usuario web;
• la papelera del gestor de archivos del hosting, donde suelen quedar intactas las webshells borradas.

Conviene revisar también los accesos al panel de control del servidor, sea cPanel, Plesk u otro. A veces el atacante se vale de otras vulnerabilidades para infectar las demás webs alojadas en el mismo servidor.

9. Vigilar que no vuelva

Después de la limpieza hay que revisar la web de forma constante para comprobar que nada ha vuelto. Aquí Git vuelve a ser el mejor aliado: cualquier archivo que cambie sin un commit detrás salta a la vista.

SEO y ciberseguridad, de la mano

El mensaje de fondo es sencillo. El SEO y la ciberseguridad van mucho más de la mano de lo que pensábamos. Un proyecto bien posicionado sobre una web sin mantenimiento es un proyecto en riesgo, y lo mejor que podemos hacer es tenerlo controlado antes de que Google nos lo recuerde.