# WordPress hackeado: señales, cómo limpiarlo y cómo evitar que regrese

> ¿Página hackeada o con virus? Señales de un WordPress hackeado, qué hacer en las primeras horas, cómo limpiarlo y cómo evitar que regrese.

Autor: Samuel Hinojosa (CEO & Founder, WITS) · Actualizada: 2026-10-25 · https://security.wits.mx/guias/wordpress-hackeado/

## ¿Cómo sé si mi WordPress está hackeado?

Las señales más claras son: Google o el antivirus de tus clientes marcan tu sitio como peligroso, el hosting lo suspende, aparecen usuarios administradores o plugins que nadie instaló, o la página redirige a sitios extraños. Si ves una de estas, trata el sitio como comprometido hasta demostrar lo contrario.

La [guía oficial de WordPress para sitios hackeados](https://wordpress.org/documentation/article/faq-my-site-was-hacked/) agrega otras: el sitio se usa para atacar a otros, manda spam desde tu servidor o cambia a la vista de cualquiera. En la práctica, lo que más vemos en empresas es más discreto:

- Redirecciones que solo pasan desde el celular o desde Google, no cuando entras directo. Así el dueño tarda semanas en darse cuenta.
- Páginas nuevas en tu dominio con productos o farmacias que no vendes, que aparecen en Search Console.
- Archivos «.php» dentro de «wp-content/uploads», donde solo deberían vivir imágenes y documentos.
- Un usuario administrador o editor que nadie reconoce, o tu propia cuenta que ya no entra.
- Un «.htaccess», «index.php» o «functions.php» modificado sin que nadie del equipo lo haya tocado.
- Tu correo empieza a caer en spam porque el servidor mandó correo basura.

> **No siempre es un virus** Una página caída, lenta o con un error en blanco puede ser una actualización fallida o un problema del hosting. Antes de borrar nada, confirma con evidencia: archivos cambiados, usuarios nuevos, registros de acceso. La misma guía de WordPress pide documentar los síntomas antes de actuar.

## ¿Por dónde entran a un WordPress?

Casi nunca por el núcleo de WordPress bien actualizado. Entran por plugins y temas con fallas, por contraseñas robadas o reutilizadas y por servidores con PHP viejo. Tres ejemplos reales de las últimas semanas:

- Bricksforge (CVE-2026-85097). Un plugin para el constructor Bricks permitía subir archivos sin iniciar sesión y ejecutar código en el servidor. [Patchstack](https://patchstack.com/articles/critical-unauthenticated-arbitrary-file-upload-vulnerability-exploited-in-bricksforge-plugin/) vio los primeros ataques el 7 de octubre de 2026. Afecta a la 3.1.8.9 y anteriores, se corrigió en la 3.1.8.10, y la huella típica son archivos «login_admin_*.php» en las carpetas de «uploads». [SecurityWeek](https://www.securityweek.com/bricksforge-wordpress-plugin-vulnerability-exploited-in-the-wild/) reportó que los ataques parecen automatizados.
- Plugins falsos con puerta trasera. El 18 y 19 de octubre alguien con llaves válidas de UpdraftCentral instaló plugins con backdoor en sitios conectados. [Patchstack contó 99 nombres distintos](https://patchstack.com/articles/updraftcentral-key-compromise-wordpress-backdoors/), como «Site Health Cache», disfrazados de herramientas de mantenimiento. No fue una falla del código de UpdraftPlus: los comandos venían firmados con llaves reales.
- WordPress core (CVE-2026-87902). Una falla crítica corregida el 22 de septiembre que CISA agregó el 25 de septiembre a su [catálogo de vulnerabilidades explotadas](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). Las versiones corregidas aparecen en el [aviso de WordPress](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp); los sitios con actualizaciones automáticas de seguridad la recibieron solos.

La versión de PHP del hosting también cuenta. Una falla de PHP como [PHP2Shell](https://security.wits.mx/guias/php2shell-cve-2026-109618/) afecta a todos los WordPress de ese servidor, aunque WordPress y sus plugins estén al día. WordPress [recomienda PHP 8.3 o superior](https://wordpress.org/about/requirements/) y advierte que las versiones viejas que todavía soporta ya no tienen parches. Si tu hosting sigue en PHP 7.4 u 8.1, revisa [cómo actualizar PHP sin romper el sitio](https://security.wits.mx/guias/actualizar-php-8-4/).

## ¿Qué hago si hackearon mi página web?

El orden importa. Si borras primero, pierdes la evidencia de cómo entraron y el atacante regresa por el mismo lugar. Si restauras sin cambiar contraseñas, regresa con las mismas llaves. Estos son los pasos, basados en la guía oficial de WordPress y en lo que nos ha funcionado:

1. Documenta. Anota qué viste, a qué hora y qué cambios se hicieron antes: plugin nuevo, tema modificado, acceso a un proveedor. Toma capturas.
2. Guarda evidencia. Haz una copia completa del sitio infectado (archivos y base de datos) y de los registros de acceso del servidor, y guárdala fuera del servidor. Es tu referencia para saber qué pasó, no para restaurar.
3. Aísla. Pon el sitio en mantenimiento o limita el acceso por IP mientras trabajas. Avisa a tu hosting: en hosting compartido el problema puede tocar otros sitios.
4. Cambia todos los accesos. Contraseñas de todos los usuarios de WordPress, del panel del hosting, FTP o SFTP, SSH y de la base de datos. Genera llaves nuevas en «wp-config.php» para cerrar las sesiones abiertas. Hazlo desde una computadora limpia: WordPress recuerda que muchas infecciones empiezan en la máquina del dueño.
5. Revisa usuarios. Borra administradores y editores que nadie reconoce. En la campaña de UpdraftCentral, el backdoor creaba un editor con permisos de administración.
6. Restaura de un respaldo limpio, de antes del ataque, si lo tienes. Si no, reemplaza «wp-admin» y «wp-includes» con una copia oficial de la misma versión, y reinstala plugins y temas desde su origen oficial, no desde el botón de reinstalar del panel.
7. Busca lo que queda: archivos «.php» en «uploads», plugins desconocidos, cambios en «.htaccess», «index.php», «header.php», «footer.php» y «functions.php», y tareas programadas extrañas.
8. Actualiza todo: WordPress, cada plugin y cada tema. Borra los que no usas. Revisa la versión de PHP del servidor.
9. Cambia las contraseñas otra vez, ya con el sitio limpio. La guía oficial lo pide explícitamente: las que cambiaste al descubrir el ataque pudieron quedar expuestas durante la limpieza.
10. Pide la revisión a Google. Si Search Console marcó el sitio, solicita la revisión cuando esté limpio, y revisa si tu dominio aparece en listas de spam de correo.

```
wp core verify-checksums                 # archivos del núcleo que no coinciden con los oficiales
wp plugin verify-checksums --all         # lo mismo para plugins del directorio oficial
wp user list --role=administrator        # administradores actuales
wp plugin list                           # plugins instalados y su estado
find wp-content/uploads -name '*.php'    # código PHP donde no debería haber
wp option get updraft_central_localkeys  # si responde algo, hay llaves de UpdraftCentral activas
```

> **No repares el plugin infectado** Si encuentras un plugin con backdoor, no intentes limpiarlo línea por línea. Desactívalo, sácalo de la carpeta pública y guárdalo como evidencia. Es lo que recomienda Patchstack para los plugins falsos de UpdraftCentral, y aplica igual a cualquier otro.

## ¿Cómo evito que mi WordPress vuelva a ser hackeado?

Nadie puede prometer que un sitio nunca será atacado. Lo que sí se puede es cerrar las puertas más usadas y enterarte rápido si algo cambia. La [guía de endurecimiento de WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/) es la base:

- Actualizaciones automáticas de WordPress, y revisión semanal de plugins y temas. Borra lo que no uses: un plugin desactivado sigue siendo código en tu servidor.
- Plugins solo del directorio oficial o de empresas conocidas. Nada de versiones «premium» gratis de sitios dudosos.
- Contraseñas largas y únicas, y verificación en dos pasos para todos los administradores.
- Permisos de archivos: carpetas en 755, archivos en 644 y «wp-config.php» en 400 o 440.
- «define( 'DISALLOW_FILE_EDIT', true );» en «wp-config.php» para que nadie edite PHP desde el panel.
- Respaldos automáticos de archivos y base de datos, guardados fuera del servidor, con varias fechas y probados. Un respaldo que nunca restauraste no es un respaldo.
- PHP con soporte en el hosting y la versión oculta en las cabeceras.
- Revisa qué servicios externos tienen llaves o acceso a tu sitio y quita los que ya no usas.

Para enterarte a tiempo de fallas como la de Bricksforge, publicamos cada semana las que importan en [alertas de seguridad](https://security.wits.mx/alertas/). Y si quieres saber hoy si tu servidor anuncia una versión de PHP vulnerable, el [chequeo gratis](https://security.wits.mx/chequeo-php/) tarda segundos.

> **¿Lo limpiamos y cerramos la puerta?** Security OS revisa tu sitio y tu servidor con permisos de solo lectura: versión de PHP, plugins con fallas conocidas, usuarios, archivos fuera de lugar y accesos. Prepara cada corrección con su reversa, la aplica solo con tu autorización y te entrega evidencia antes y después. Con la Vigilancia mensual te avisamos cuando sale una falla de lo que tienes instalado.

Chequeo pasivo: solo lee la respuesta pública de tu portada, igual que un navegador. Úsalo con dominios que te pertenecen o que administras. [Revisar mi sitio gratis](https://security.wits.mx/chequeo-php/)

## Preguntas frecuentes

**¿Cómo sé si mi página web tiene virus?**

Las señales más comunes son avisos de Google o del antivirus, redirecciones a otros sitios, usuarios o plugins que nadie instaló y archivos PHP en la carpeta de uploads. Con WP-CLI, «wp core verify-checksums» te dice si cambiaron archivos del núcleo.

**¿Qué hago primero si hackearon mi WordPress?**

Documenta lo que ves, guarda una copia del sitio infectado y de los registros fuera del servidor, y aísla el sitio. Después cambia todos los accesos y limpia. Si borras primero, pierdes la pista de cómo entraron.

**¿Basta con restaurar un respaldo?**

No. Si restauras sin cambiar contraseñas ni cerrar la falla por donde entraron, el atacante regresa. El respaldo debe ser de antes del ataque y, después de restaurar, hay que actualizar todo y cambiar accesos.

**¿Un plugin de seguridad evita que me hackeen?**

Ayuda a detectar y bloquear ataques conocidos, pero no reemplaza tener todo actualizado, contraseñas únicas, verificación en dos pasos y respaldos probados. Tampoco protege si la falla está en la versión de PHP del servidor.

**¿La versión de PHP afecta la seguridad de WordPress?**

Sí. Una falla de PHP afecta a todos los sitios del servidor aunque WordPress esté al día. WordPress recomienda PHP 8.3 o superior.

**¿Qué es la falla de Bricksforge?**

Es CVE-2026-85097, una falla crítica del plugin Bricksforge que permite subir archivos y ejecutar código sin iniciar sesión. Se explota desde el 7 de octubre de 2026 y se corrige actualizando a la versión 3.1.8.10 o posterior.

**¿Por qué mi sitio hackeado solo redirige desde el celular?**

Muchos códigos maliciosos solo actúan con ciertos visitantes, como quien llega desde Google o desde un celular, para que el dueño no lo note. Revisa desde otro dispositivo y busca cambios en .htaccess y en los archivos del tema.

## Fuentes

- [WordPress.org: FAQ My site was hacked](https://wordpress.org/documentation/article/faq-my-site-was-hacked/)
- [WordPress Developer: Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/)
- [WordPress.org: requisitos (PHP recomendado)](https://wordpress.org/about/requirements/)
- [Patchstack: falla crítica explotada en Bricksforge (CVE-2026-85097)](https://patchstack.com/articles/critical-unauthenticated-arbitrary-file-upload-vulnerability-exploited-in-bricksforge-plugin/)
- [SecurityWeek: Bricksforge WordPress plugin vulnerability exploited in the wild](https://www.securityweek.com/bricksforge-wordpress-plugin-vulnerability-exploited-in-the-wild/)
- [Patchstack: llaves de UpdraftCentral usadas para instalar backdoors](https://patchstack.com/articles/updraftcentral-key-compromise-wordpress-backdoors/)
- [WordPress: GHSA-7hp8-65ch-5whp (CVE-2026-87902)](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp)
- [CISA: Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
