WordPress impulsa aproximadamente el 43% de todos los sitios web del mundo, lo que lo convierte en el blanco más atacado por bots automatizados. El hardening de WordPress checklist seguridad 2026 cubre ocho áreas críticas: prefijo de tabla, XML-RPC, autenticación fuerte, permisos de usuario, plugins vulnerables, base de datos, SSL y monitoreo continuo.
En 30 segundos
- Cambiá el prefijo de tabla
wp_antes de instalar: es lo primero que prueban los scripts de inyección SQL automatizados. - Desactivá XML-RPC si no usás Jetpack ni apps móviles: es el vector clásico de fuerza bruta amplificada.
- 2FA en wp-login.php es más efectivo que cualquier límite de intentos solo: sin el segundo factor, la contraseña no alcanza.
- Plugins desactualizados o sin uso son la principal puerta de entrada: si no lo usás, borralo del servidor, no lo dejes desactivado.
- Los backups fuera del servidor son la única copia que cuenta: si el hosting se compromete, el backup en el mismo servidor no sirve.
El hardening de WordPress es el proceso de reducir la superficie de ataque de una instalación WordPress mediante configuraciones específicas, desactivación de funcionalidades innecesarias y controles de acceso más estrictos que los que trae por defecto. No es una solución única: es un conjunto de decisiones técnicas que cubren desde la base de datos hasta los headers HTTP del servidor, y que requieren revisión periódica para seguir siendo efectivas.
¿Por qué es crítico el hardening de WordPress en 2026?
Ponele que tenés un sitio WordPress corriendo con SSL activo, contraseña «fuerte» y plugins más o menos actualizados. Parece suficiente. El problema es que la mayoría de los compromisos no llegan por el camino obvio: llegan por un plugin que no actualizaste en tres meses, por el prefijo wp_ que dejaste por defecto, o por XML-RPC que nunca desactivaste porque «total nadie lo usa».
Según los datos públicos de Patchstack, la aplastante mayoría de vulnerabilidades explotadas activamente en WordPress provienen de plugins y temas, no del core. El core de WordPress se parchea rápido y bien; el ecosistema que lo rodea es otra historia.
El impacto de una brecha va mucho más allá de limpiar archivos maliciosos. Google puede indexar páginas infectadas antes de que recibas cualquier alerta, lo que genera penalizaciones en el ranking que pueden tardar semanas en revertirse. Si procesás datos de usuarios o tenés un WooCommerce activo, las implicancias legales son otro problema encima. Y la «limpieza» post-hackeo consume tiempo y plata que ningún presupuesto tiene previsto.
Cambios en la instalación de WordPress que todo administrador debe hacer
Cambiar el prefijo de tabla de la base de datos
El prefijo wp_ es el default que todos los scripts de inyección SQL conocen. Cambiarlo a algo aleatorio (por ejemplo bx47k_) no frena ataques sofisticados dirigidos, pero elimina el ruido enorme de los scripts automatizados que prueban el prefijo por defecto. Si ya tenés WordPress instalado, el cambio requiere modificar wp-config.php y renombrar las tablas en la base de datos: hay plugins que lo hacen, pero hacé un backup completo antes.
Remover la versión de WordPress del HTML
Por defecto, WordPress expone su versión en el meta generator del header. Agregá esto al functions.php de tu tema hijo: Relacionado: vulnerabilidades conocidas en WordPress.
remove_action('wp_head', 'wp_generator');Después borrá readme.html, license.txt y wp-config-sample.php de la raíz. Son archivos de instalación que no tienen función en producción y anuncian exactamente qué versión corrés. La «seguridad por oscuridad» no es una defensa completa por sí sola, pero no hay razón para publicitar la versión gratis.
Desactivar XML-RPC
XML-RPC fue la API de WordPress antes de REST API. Hoy sirve principalmente como vector de amplificación para fuerza bruta: un solo request HTTP puede probar cientos de contraseñas via system.multicall (sí, en serio, es así de simple). Si no usás Jetpack ni publicación desde aplicaciones móviles que dependan de él, desactivalo en .htaccess:
<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>¿Cómo proteger el wp-login.php de ataques de fuerza bruta?
El formulario de login de WordPress es el punto más atacado de cualquier instalación. Miles de bots prueban combinaciones de usuario y contraseña de forma continua, las 24 horas. Las defensas se apilan:
- Cambiá la URL de login: plugins como WPS Hide Login cambian
/wp-login.phpa una URL personalizada. No es infalible, pero elimina completamente el ruido de los bots que atacan la URL por defecto. - Dos factores (2FA): es lo que mayor impacto tiene por menor esfuerzo. Con 2FA activo, incluso si alguien obtiene tu contraseña, no puede entrar sin el segundo factor. Wordfence y el plugin WP 2FA lo implementan con TOTP (Google Authenticator, Authy).
- Limitar intentos fallidos: la recomendación de Wordfence es bloquear IPs después de 3 a 5 intentos fallidos, con ventana de bloqueo de 20 a 60 minutos. Menos intentos aumenta el riesgo de bloquear usuarios legítimos; más intentos le da tiempo a los scripts.
- Protección HTTP básica en el wp-admin: una capa de autenticación HTTP a nivel servidor antes de que cargue el formulario de WordPress es una defensa extra que los bots automatizados suelen no superar.
¿Y qué pasa cuando combinás cambio de URL más 2FA más límite de intentos? Los ataques automatizados generalmente se dan por vencidos y siguen para otro objetivo más fácil. El objetivo no es ser invulnerable, es no ser el sitio más fácil del rango de IPs que están escaneando.
Gestión de usuarios y permisos en WordPress
El usuario «admin» con ID 1 es lo primero que buscan los scripts de ataque. Si todavía tenés ese usuario activo en tu instalación, creá un nuevo usuario con rol Administrador y nombre de usuario diferente, migrá el contenido existente, y eliminá el original. Es un paso que lleva cinco minutos y elimina el vector más predecible.
Más allá de eso, la auditoría de roles es algo que conviene hacer cada seis meses. El problema habitual es este: subís a un freelancer como Editor para un proyecto puntual, el proyecto termina, y el usuario sigue activo con los mismos permisos tres años después (que no es poco tiempo para que una cuenta quede abandonada con credenciales reutilizadas). Para más detalles técnicos, mirá implementar una capa WAF.
- Administrador: solo para el/los dueños del sitio. Permiten cambiar plugins, temas y configuración general.
- Editor: gestiona y publica contenido de otros usuarios. No necesita acceso a plugins ni configuración del sitio.
- Autor: publica sus propios posts sin acceso al contenido de otros.
- Contribuidor: escribe y edita sus propios posts pero no los publica. Mínimo acceso posible para un redactor.
Para accesos temporales, el plugin Temporary Login Without Password genera credenciales con fecha de vencimiento. Mucho mejor que crear una cuenta y acordarte de borrarla después (spoiler: nadie se acuerda).
¿Qué hacer con plugins y temas vulnerables en WordPress?
Instalás un plugin para un proyecto específico, lo configurás, funciona bárbaro, lo dejás ahí, pasan seis meses, el desarrollador abandona el plugin, aparece una vulnerabilidad crítica, los scanners la detectan, alguien la explota, y tu sitio queda comprometido antes de que hayas visto el reporte de Patchstack en el mail.
Ese es el ciclo habitual. La base de datos de Patchstack y la de WPScan registran vulnerabilidades de plugins con CVE asignados. El proceso concreto de auditoría:
- Revisá la última actualización: si un plugin no tuvo actualizaciones en más de 12 meses, está potencialmente abandonado. Buscá una alternativa mantenida activamente.
- Chequeá vulnerabilidades conocidas: ingresá el nombre del plugin en patchstack.com/database antes de instalarlo, y periódicamente para los que ya tenés activos.
- Eliminá plugins inactivos del servidor: desactivado no es lo mismo que borrado. El código sigue presente y puede ser explorado. Si no lo usás, borralo desde el panel o via FTP.
- Evitá temas «nulled»: los temas y plugins piratas prácticamente siempre contienen backdoors o código malicioso oculto. No hay forma de saber qué más ejecutan en tu servidor.
Base de datos: respaldos automáticos y protección contra inyección SQL
Dos frentes distintos: protección ante ataques y protección ante pérdida de datos.
Para los respaldos, la regla mínima es una copia diaria almacenada fuera del servidor. Plugins como WPVivid o UpdraftPlus permiten configurar el envío automático a Google Drive, Dropbox o Amazon S3. La frecuencia depende del ritmo del sitio: publicación semanal requiere backup diario; un e-commerce con pedidos constantes necesita backups cada 6 horas como mínimo. Probá la restauración cada 3 meses: un backup que no se puede restaurar no es un backup.
Para proteger contra inyección SQL en código personalizado, siempre usá prepared statements con wpdb:
$results = $wpdb->get_results(
$wpdb->prepare(
"SELECT * FROM {$wpdb->prefix}posts WHERE post_author = %d",
$author_id
)
);Nunca concatenes variables directamente en queries SQL. El OWASP Top 10 incluye inyección SQL entre las vulnerabilidades más críticas porque cuando funciona, el atacante tiene acceso completo a los datos. Y en WordPress, eso significa todo: usuarios, contraseñas (hasheadas, pero recuperables), contenido, configuración.
HTTPS, SSL y headers de seguridad HTTP en WordPress
SSL es el piso mínimo. Si tu hosting, como donweb.com, incluye certificados Let’s Encrypt gratuitos, no hay excusa para no tenerlo activo y con renovación automática configurada.
Más allá del certificado, hay headers HTTP de seguridad que la mayoría de los sitios WordPress no tiene configurados y que protegen contra clases enteras de ataques: Complementá con defenderte contra ataques DDoS.
- HSTS (Strict-Transport-Security): fuerza al navegador a usar HTTPS incluso si el usuario tipea «http://». Valor recomendado:
max-age=31536000; includeSubDomains. Ojo: una vez que activás HSTS con un max-age alto, no podés volver a HTTP fácilmente durante ese período. - X-Frame-Options: previene que tu sitio se cargue en un iframe (protección contra clickjacking). Valor:
SAMEORIGIN. - X-Content-Type-Options: previene que el navegador «adivine» el tipo de contenido (MIME sniffing). Valor:
nosniff. - Content-Security-Policy (CSP): define de dónde se pueden cargar scripts, estilos e imágenes. El más poderoso y el más complejo de configurar: requiere testing exhaustivo porque puede romper funcionalidades si las fuentes no están todas en la whitelist.
Para verificar el estado de los headers, SecurityHeaders.com analiza el sitio y da una nota de A a F. SSL Labs (ssllabs.com/ssltest/) evalúa el certificado y la configuración TLS en detalle.
Monitoreo, logs y respuesta ante incidentes en WordPress
Podés tener todo lo anterior bien configurado y aun así necesitar saber qué está pasando. Los logs son el sistema de alerta temprana.
WordPress no tiene un sistema de auditoría robusto por defecto. El plugin WP Activity Log registra todo: quién inició sesión, qué cambios realizó, desde qué IP, con timestamps. Es el primer lugar donde mirás cuando algo raro ocurre.
Las alertas que conviene tener activas:
- Cambios en archivos del core: si un archivo de WordPress se modificó fuera de una actualización oficial, es señal de compromiso. Wordfence incluye un scanner de integridad que detecta cambios no autorizados.
- Spike de intentos de login fallidos: un volumen inusual desde una IP o rango de IPs indica un ataque en curso.
- Nuevos usuarios con rol Administrador: si vos no los creaste, es un indicador claro de acceso no autorizado.
- Cambios en configuración general: modificaciones a la URL del sitio, el correo del admin o las opciones de WordPress son señales de alerta inmediata.
Si el sitio ya fue comprometido, el proceso es: poner el sitio en modo mantenimiento primero para que no siga sirviendo malware a visitantes, hacer un backup del estado comprometido para análisis forense, restaurar desde el último backup limpio verificado, analizar los logs para identificar el vector de entrada, y después aplicar el parche o eliminar el plugin que fue la puerta.
Comparativa de plugins de seguridad para WordPress
| Plugin | Firewall WAF | 2FA | Scanner de malware | Auditoría de logs | Versión gratuita |
|---|---|---|---|---|---|
| Wordfence Security | Sí (reglas con 30 días de delay en free) | Sí | Sí | Limitado en free | Sí |
| Sucuri Security | Solo en versión paga | No incluido | Sí | Sí | Sí (sin WAF) |
| WPVulnerability | No | No | Solo detección de versiones vulnerables | No | Sí |
| Solid Security (ex iThemes) | Básico | Sí | Limitado | Sí | Sí |
Para la mayoría de los sitios, Wordfence en versión gratuita más 2FA activo ya cubre bastante. La principal diferencia de la versión premium es que las reglas de firewall llegan en tiempo real en vez de con 30 días de delay: si hay un exploit activo hoy, el free lo tiene en un mes. Para sitios con e-commerce o datos sensibles, el WAF en la nube de Sucuri ofrece filtrado antes de que el tráfico llegue al servidor.
Errores comunes al implementar hardening de WordPress
Error 1: Instalar el plugin de seguridad y no configurarlo
Wordfence con configuración por defecto no es lo mismo que Wordfence bien configurado. El firewall puede estar en modo «Learning» indefinidamente, las alertas de email pueden no estar activas, y el 2FA puede estar disponible pero no forzado para el rol Administrador. Revisá la configuración completa inmediatamente después de instalar. Te puede servir nuestra cobertura de asegurar la entrada de datos.
Error 2: Creer que el backup en el hosting es suficiente
Un backup en la misma cuenta de hosting que fue comprometida no sirve. Si el atacante tiene acceso al servidor, puede borrar o cifrar esa copia también. El backup externo (Google Drive, S3, servidor separado) es el único que cuenta cuando el servidor principal es el problema.
Error 3: Dejar plugins desactivados en el servidor
Desactivar un plugin no lo elimina del servidor. El código sigue presente y puede ser explorado o ejecutado en determinados escenarios. Si no usás un plugin, borralo completamente desde la pantalla de plugins de WordPress, no lo dejes desactivado «por las dudas».
Error 4: No testear los backups nunca
¿Alguien verificó de forma independiente que esas copias se restauran correctamente? Configurar el backup y nunca probarlo es el escenario más común. Un backup corrupto o incompleto cuando más lo necesitás es lo que querés evitar. Hacé una restauración de prueba en un entorno de staging al menos cada 3 meses.
Si querés profundizar en esto, tenemos un artículo sobre Hardening de WordPress: checklist de seguridad 2026.
Para complementar esto, cubrimos el tema en detalle en nuestro artículo sobre activar autenticación de dos factores.
Si querés profundizar en esto, leé nuestro artículo sobre proteger WordPress de hackers.
Preguntas Frecuentes
¿Cuáles son los pasos básicos para asegurar un WordPress en 2026?
El checklist mínimo cubre: cambiar el prefijo de tabla wp_, desactivar XML-RPC, activar 2FA en wp-login.php, mantener WordPress core y plugins al día, configurar HTTPS con certificado válido y HSTS, y tener backups automáticos en almacenamiento externo. Estos pasos cubren la mayoría de los vectores de ataque comunes sin requerir conocimiento avanzado de seguridad.
¿Qué plugins de seguridad instalar en WordPress?
Para la mayoría de los sitios, Wordfence Security en versión gratuita es el punto de partida: incluye firewall, scanner de malware, 2FA y monitoreo de intentos de login. Para sitios con e-commerce o datos sensibles, el WAF de Sucuri con filtrado en la nube agrega una capa de protección antes de que el tráfico llegue al servidor. WPVulnerability complementa cualquiera de los dos con detección específica de versiones de plugins vulnerables.
¿Cómo cambiar la URL de wp-admin en WordPress?
El plugin WPS Hide Login es la forma más directa: cambia la URL del formulario de login a cualquier slug personalizado que definas, sin modificar archivos del core. La URL original /wp-login.php devuelve 404 para quien no conozca la nueva ruta. No es una solución de seguridad por sí sola, pero elimina el ruido de los bots que atacan sistemáticamente la URL por defecto.
¿Cuáles son las vulnerabilidades más comunes en WordPress?
Según los datos de Patchstack y WPScan, la mayoría de vulnerabilidades explotadas provienen de plugins y temas, no del core. Los tipos más frecuentes son Cross-Site Scripting (XSS), inyección SQL, escalada de privilegios y Cross-Site Request Forgery (CSRF). El core de WordPress se parchea rápido; el riesgo real está en el ecosistema de plugins desactualizados o abandonados.
¿Con qué frecuencia hay que revisar la seguridad de un WordPress?
Actualizaciones de core y plugins: dentro de las 48 horas para actualizaciones de seguridad. Auditoría de usuarios y permisos: cada 6 meses. Revisión de plugins instalados versus plugins realmente necesarios: cada 3 meses. Prueba de restauración de backup: cada 3 meses. Escaneo automático de malware: semanal como mínimo con Wordfence, diario si el sitio tiene tráfico significativo.
Conclusión
El hardening de WordPress no es un proyecto de un día ni una configuración que se hace una vez y se olvida. Es un conjunto de decisiones técnicas que tomás, mantenés y revisás periódicamente. Los pasos más importantes son también los más accesibles: cambiar el prefijo de tabla, desactivar XML-RPC, activar 2FA y configurar backups externos. Lo que salteás hoy es lo que los bots van a encontrar mañana.
Lo que cambió para 2026 no es que WordPress sea menos seguro: es que las herramientas de ataque son más accesibles, los scripts de explotación más sofisticados, y el volumen de sitios atacados simultáneamente más alto. El ecosistema de defensa también mejoró: Patchstack, WPScan y Wordfence tienen bases de vulnerabilidades actualizadas en tiempo real que hacen más fácil mantenerse al día sin ser un especialista en seguridad.
Si todavía no aplicaste el hardening en tu instalación, arrancá por los cinco puntos de la sección «En 30 segundos». Son los de mayor impacto por menor tiempo invertido. El resto del checklist se puede completar durante las semanas siguientes, pero esos primeros cinco están para hacer hoy.
¿Cómo actualizar WordPress de forma segura sin perder datos?
Hacé un backup completo antes de actualizar. Ingresá al panel de WordPress y aplicá las actualizaciones (automáticas para parches menores). Si usás temas o plugins personalizados, testeá primero en un sitio de staging. Después verificá que tus posts, formularios y búsqueda funcionen correctamente.
¿Cada cuánto tiempo debo actualizar WordPress y mis plugins?
Actualizá WordPress apenas salgan parches de seguridad (o habilitá actualización automática). Para plugins: revisa actualizaciones mensuales; si hay CVE, aplicá inmediatamente. Los temas: menos frecuentes, pero checkeá cuando haya actualizaciones. Un plugin sin actualizaciones en 12 meses está potencialmente abandonado.
¿Qué riesgos hay si no actualizo WordPress regularmente?
El código queda con vulnerabilidades conocidas que los bots atacan automáticamente. Una brecha infecta tu sitio, Google penaliza el ranking y perdés tráfico. Si procesás datos de usuarios o tenés un e-commerce, hay implicancias legales. La limpieza post-hackeo cuesta tiempo y dinero.
¿Cómo actualizar WordPress de forma segura?
Hacé un backup completo antes de actualizar (base de datos y archivos). Activá modo mantenimiento para que los visitantes no vean errores durante el proceso. Después de actualizar, verificá que todos los plugins y temas sigan funcionando. Si algo falla, restaurá desde el backup inmediatamente.
¿Con qué frecuencia debo actualizar WordPress?
El core de WordPress se actualiza cada mes aproximadamente, o inmediatamente si hay una vulnerabilidad crítica de seguridad. Revisá tu dashboard de WordPress regularmente y actualizá apenas esté disponible. Los plugins y temas también generan actualizaciones frecuentes: configurá actualizaciones automáticas en lo posible.
¿Qué hago si WordPress no actualiza correctamente?
Verificá que tengas espacio en disco suficiente en tu hosting. Luego revisá los permisos de las carpetas wp-content y wp-includes (deben tener permisos de escritura). Si sigue fallando, desactivá temporalmente los plugins para ver si alguno entra en conflicto con la actualización. Restaurá desde un backup si algo quedó a mitad de camino.
Fuentes
- WordPress.org – Hardening WordPress (documentación oficial)
- Wordfence Blog – Investigación de seguridad y análisis de vulnerabilidades
- Patchstack Database – Base de datos de vulnerabilidades de plugins WordPress
- WPScan – Scanner de vulnerabilidades para WordPress
- OWASP Top 10 – Vulnerabilidades web más críticas