Si llevas una web en WordPress, la seguridad no es algo que puedas dejar para mañana. Cada día se reportan miles de intentos de login automatizados contra wp-admin, y los plugins desactualizados son la primera puerta por la que entra un atacante. Este artículo recoge diez medidas básicas que cualquier admin de WordPress debería tener aplicadas en 2026, actualizadas con los plugins y técnicas que sí funcionan hoy.
admin sigue siendo el primer nombre que prueban los bots cuando atacan un WordPress. Si tu instalación todavía tiene un usuario llamado admin con permisos de administrador, se lo estás poniendo demasiado fácil. La solución es rápida.
admin, root, tucasa o tu nombre).admin y reasigna sus entradas y páginas al nuevo administrador.Hay quien recomienda además cambiar la URL del login con plugins tipo WPS Hide Login. Es seguridad por oscuridad, pero combinada con limit login attempts reduce mucho el ruido de los bots y, sobre todo, te limpia el log de errores.
Las contraseñas tipo 123456, qwerty, contraseña o tu fecha de nacimiento siguen apareciendo en los listados de las más usadas año tras año. Y siguen siendo las primeras que prueba un atacante.
Lo que recomiendo en 2026:
Generadores online gratuitos como password.es siguen funcionando bien para una contraseña puntual. Para uso diario, gestor.
El 2FA añade una capa extra al login. Además de la contraseña, necesitas un código generado por una app o enviado por email, así que aunque alguien te robe la contraseña no puede entrar.
En 2026 las opciones que tienen mejor mantenimiento son:
Olvídate de Clef (descontinuado en 2017). Rublon todavía existe pero en versión empresarial; para webs personales o pymes, los tres anteriores cubren de sobra.
Por defecto, WordPress permite intentar el login todas las veces que quieras. Si un atacante usa un script de fuerza bruta probando combinaciones, tarde o temprano puede acertar.
Para frenarlo, dos plugins van perfectamente:
Si tienes un firewall a nivel de hosting o un WAF como Cloudflare, configura también una rule que limite las peticiones a /wp-login.php a, por ejemplo, 5 cada 60 segundos por IP. Eso tumba la mayoría de ataques antes de que toquen WordPress. Te dejo dos lecturas para profundizar: la guía para configurar el CDN de Cloudflare en WordPress y cómo bloquear los bots de spam con Fail2Ban si usas un servidor propio.
Los plugins son la mayor superficie de ataque de WordPress. El repositorio oficial tiene más de 60.000 plugins revisados, y el Plugin Check Team del Core hace una revisión inicial antes de aceptar uno nuevo.
Mi regla a la hora de instalar un plugin nuevo:
Antes de instalar cualquier plugin nuevo, haz una copia de seguridad completa (archivos y base de datos). UpdraftPlus o Duplicator van bien para esto, y muchos hostings ya incluyen backups automáticos al panel.
La mayoría de hackeos a WordPress aprovechan vulnerabilidades de plugins ya parcheadas pero no actualizadas en el sitio. Es decir, alguien publicó la solución hace meses y la web sigue sin aplicarla.
Desde WordPress 5.5 puedes activar las actualizaciones automáticas de plugins y temas desde el propio panel (Plugins > Todos los plugins, columna «Actualizaciones automáticas»). Para el core, las menores se aplican solas desde la versión 3.7. Las mayores (como el salto a WordPress 7.0) las decides tú.
Lo que te recomiendo:
Si quieres una visión global del estado de tu instalación, échale un vistazo a Site Audit Snapshot, un plugin que audita WordPress en un clic y te dice qué está obsoleto.
Cada plugin instalado es código que se ejecuta en tu sitio. Aunque esté desactivado, los archivos siguen ahí y pueden ser explotados si tienen una vulnerabilidad. Lo mismo con los temas: si tienes Twenty Twenty-One, Twenty Twenty-Two y tres temas que probaste en su día, son tres potenciales agujeros.
La regla es sencilla: si no lo usas, lo borras. No lo desactivas, lo borras. Mantén solo el tema activo, el tema padre si trabajas con un child theme, y los plugins que de verdad están en producción.
Lo mismo aplica a:
Los pingbacks y trackbacks son notificaciones automáticas cuando otra web enlaza tu contenido. La mayoría de webs ya no los usan, pero siguen activos por defecto y pueden ser aprovechados para ataques DDoS amplificados.
Para desactivarlos, ve a Ajustes > Comentarios y desmarca «Permitir notificaciones de enlaces de otros blogs (pingbacks y trackbacks) en los nuevos artículos».
XML-RPC es otra puerta que poca gente usa hoy (la API REST de WordPress lo ha sustituido casi por completo). Si no usas la app de WordPress.com en el móvil ni Jetpack ni servicios externos que lo necesiten, desactívalo. Plugins como Disable XML-RPC o reglas en .htaccess hacen el trabajo en dos minutos.
Y si te interesa el lado oscuro, hace poco analizamos cómo los hackers están explotando webs WordPress con campañas tipo ClickFix usando inyecciones JS y suplantaciones de Cloudflare. Lectura recomendada para entender cómo entran realmente.
Los permisos UNIX controlan quién puede leer, escribir o ejecutar cada archivo. Mal configurados, dan vía libre a un atacante que haya colado un script.
La regla canónica para WordPress:
755644wp-config.php: 600 o 640 (el archivo más sensible, contiene las credenciales de la base de datos)..htaccess: 644Nunca, jamás, uses 777 en nada (ni siquiera para «arreglar un problema temporal»). Si tu hosting te obliga a poner 777 para que algo funcione, ese hosting tiene un problema de configuración y debes hablar con el soporte o cambiarte.
Para revisar y corregir permisos en bloque, plugins como Solid Security (antes iThemes Security) tienen una opción que detecta archivos con permisos incorrectos y los corrige.
Cuando un servidor web no encuentra un archivo index.php o index.html en un directorio, por defecto puede mostrar el listado de archivos de esa carpeta. Eso significa que cualquier visitante puede ver la lista de plugins instalados, los temas, los uploads… Información valiosa para un atacante que busque vulnerabilidades concretas.
Para bloquearlo tienes dos opciones:
Options -Indexes a tu .htaccess (Apache) o autoindex off; en la configuración del server block (Nginx).Habla con tu proveedor de hosting o con tu cloud administrado para WordPress si no tienes acceso a estos archivos. Es una de esas configuraciones que casi nadie revisa y que se pasa por alto.
Estas diez medidas frenan la inmensa mayoría de ataques automatizados contra WordPress, que son los que afectan al 95% de los sitios. Lo que no cubren son las vulnerabilidades zero-day en plugins concretos, los ataques dirigidos contra una marca específica o los supply-chain attacks. Para esos casos necesitas un buen WAF (Cloudflare, Sucuri o Wordfence Premium), un hosting que parchee el sistema operativo a tiempo y atención a los avisos de WPScan o Patchstack.
Si vas a tocar wp-config.php, .htaccess o permisos por primera vez, hazte siempre una copia antes. Y si gestionas varios sitios, considera centralizar la auditoría con herramientas tipo Patchstack, WPScan o el propio Site Audit Snapshot del repositorio.
Para un sitio normal, uno bien configurado tipo Wordfence o Solid Security cubre lo básico (firewall, 2FA, escaneo, limit login). Si quieres separar funciones, tener Wordfence solo para firewall, Limit Login Attempts Reloaded y Two-Factor te da más control y menos peso. Lo importante es no instalar tres plugins de seguridad encima del otro porque se pisan entre ellos y acaban ralentizando el sitio.
Es seguridad por oscuridad. No para a un atacante decidido, pero sí elimina el ruido de bots automáticos que prueban /wp-login.php y /wp-admin a saco. Combinado con limit login attempts y 2FA reduce el log de intentos a casi cero. WPS Hide Login lo hace en un par de clics.
Si no usas la app móvil de WordPress, Jetpack ni servicios externos tipo IFTTT o publicación remota, sí. La API REST de WordPress cubre prácticamente todos los casos modernos. XML-RPC sigue activado por defecto y se ha usado históricamente para ataques de fuerza bruta amplificada y DDoS reflejados.
Lo primero, cambiar todas las contraseñas (administradores, FTP, base de datos) desde un equipo limpio. Después, restaurar una copia de seguridad anterior al hackeo si la tienes. Si no, escanear con Wordfence o Sucuri SiteCheck para identificar archivos modificados, eliminar puertas traseras y reinstalar el core de WordPress desde Herramientas > Salud del sitio.
Cubren la parte de servidor (firewall perimetral, parches del SO, monitorización), pero no la parte de aplicación. Sigues teniendo que activar 2FA, limitar el login, mantener plugins actualizados y usar contraseñas fuertes. Eso lo gestionas tú o tu agencia, el hosting no entra al wp-admin por ti.
