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

Por Samuel Hinojosa · CEO & Founder, WITSFundador y CEO de WITS. Dirige las auditorías de seguridad de nube, servidores y código de Security OS.Publicada el 25 oct 2026 · Actualizada el 25 oct 2026

¿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 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.

¿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 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 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, 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. Las versiones corregidas aparecen en el aviso de WordPress; 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 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 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.

¿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

¿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 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. Y si quieres saber hoy si tu servidor anuncia una versión de PHP vulnerable, el chequeo gratis tarda segundos.

Preguntas frecuentes

Fuentes

• WordPress.org: FAQ My site was hacked
• WordPress Developer: Hardening WordPress
• WordPress.org: requisitos (PHP recomendado)
• Patchstack: falla crítica explotada en Bricksforge (CVE-2026-85097)
• SecurityWeek: Bricksforge WordPress plugin vulnerability exploited in the wild
• Patchstack: llaves de UpdraftCentral usadas para instalar backdoors
• WordPress: GHSA-7hp8-65ch-5whp (CVE-2026-87902)
• CISA: Known Exploited Vulnerabilities Catalog

Escrita por Samuel Hinojosa y el equipo de seguridad de WITS · Actualizada el 25 oct 2026 · Markdown