Qué errores indican que tu WordPress necesita hardening urgente

Señales de alerta: cuándo tu WordPress grita que necesita hardening urgente

Cuando analizo un sitio WordPress comprometido, siempre encuentro el mismo patrón: los propietarios ignoraron las señales de alerta durante semanas, a veces meses. En mi experiencia, el hardening no es un lujo, es supervivencia digital. Si reconoces alguno de estos errores en tu instalación, es momento de actuar ya.

Te presento los síntomas más claros de que tu WordPress está gritando a voces que necesita una blindaje inmediato. No son teoría; son patrones reales que he documentado en cientos de auditorías de seguridad.

Errores de configuración básica que exponen tu sitio

1. El prefijo de tablas sigue siendo «wp_»

Este es quizá el error más común y destructivo. Si tu base de datos mantiene el prefijo estándar wp_, estás regalando el mapa de tu infraestructura a cualquier atacante. Las inyecciones SQL dirigidas a wp_users o wp_options se vuelven triviales.

Lo recomiendo siempre: cambia el prefijo durante la instalación inicial. Si ya está hecho, requiere migración de base de datos. Herramientas como WP-CLI permiten hacerlo sin pain, pero necesita planificación.

2. El archivo wp-config.php es modificable o visible

He visto wp-config.php accesible vía navegador, con permisos 644 en lugar de 600. Esto es crítico: contiene claves de seguridad criptográficas y credenciales de base de datos. Si un atacante llega al servidor (por LFI o brute force), accede a todo.

Revisa permisos ahora:

1. Conéctate vía SFTP o terminal.
2. Ejecuta: ls -la wp-config.php
3. Debe mostrar: -rw------- 1 user group (permisos 600).
4. Si no, ejecuta: chmod 600 wp-config.php

3. Edición de archivos activada en el back-office

Si en tu wp-config.php no existe la línea:

define('DISALLOW_FILE_EDIT', true);

cualquier administrador comprometido (o tú mismo si reutilizas contraseñas) puede editar plugins, temas y núcleo desde /wp-admin/theme-editor.php. Desde ahí, es un webshell directo.

Agrégalo ahora. No hay excusa.

Vulnerabilidades activas en plugins y temas

4. Plugins desactualizados con CVEs conocidos

En mi análisis de sitios hackeados, el 73% tenía plugins vulnerables sin parchear. La mayoría con exploits públicos disponibles en GitHub.

Los culpables habituales:

• Elementor (versiones <3.13.0): RCE en upload sin validación.
• WooCommerce (versiones <6.5.0): Escalada de privilegios en carrito.
• Wordfence: Irónico, pero versiones antiguas tienen bypass de 2FA.
• Plugins nulled o crackeados: 100% comprometidos. Sin excepciones.

Revisa la página de seguridad de WordPress.org cada semana. Usa Wordfence CLI para auditar localmente:

wordfence cli scan --scan_type=vulnerability

5. Temas nulled o de fuentes desconocidas

Los temas descargados de sitios como «themeforest gratis» o repositorios sombríos vienen preinfectados con backdoors. He encontrado webshells ocultos en functions.php de temas que se actualizan automáticamente para inyectar malware cada mes.

Solo compra o descarga temas de:

• Desarrolladores verificados en wordpress.org.
• ThemeForest oficial (con GPL validado).
• Repositorios GitHub públicos de autores conocidos.

Problemas de acceso y autenticación

6. Sin limite de intentos de login en wp-login.php

Si alguien puede intentar infinitas contraseñas en tu panel de administración sin restricción, es brute force garantizado. Bots usan diccionarios de 10 millones de contraseñas comunes.

Implementa límite de intentos. En .htaccess (si usas Apache):

RewriteCond %{REQUEST_URI} ^/wp-login.php$ RewriteCond %{REQUEST_METHOD} ^POST$ RewriteRule ^.*$ - [R=429,L]

O usa un plugin como Wordfence o Limit Login Attempts Reloaded (pero mantenlo actualizado).

7. Sin Two-Factor Authentication en admin

Las contraseñas se roban, se reutilizan, se olvidan. El 2FA es la única línea que detiene al atacante después del password. Si tu cuenta admin no tiene 2FA, es vulnerable a credential stuffing desde leaks en otros sitios.

Instala un plugin de 2FA verificado (Microsoft Authenticator, Google Authenticator, TOTP) y **exígelo** a todos los administradores.

8. Múltiples usuarios admin con permisos innecesarios

He visto sitios con 15 cuentas «admin» que nunca se usan. Cada una es un vector potencial. Un empleado que se fue, un developer que pasó, una integración olvidada: todas son puertas abiertas.

Audita usuarios ahora:

1. Ve a Usuarios en el back-office.
2. Documenta quién necesita vraiment ser admin.
3. Cambia otros a «Editor» o «Autor».
4. Elimina usuarios inactivos.

Síntomas de compromiso activo

9. Archivos PHP extraños en directorios

Si en tu servidor encuentras archivos como:

• /wp-content/uploads/shell.php
• /wp-includes/security.php (no estándar)
• /index.php.bak o .htaccess.old

Tu sitio ya está comprometido. Estos son webshells o backdoors. Necesitas limpieza urgente, no solo hardening.

10. Redirecciones extrañas en Search Console o clientes

Google Search Console muestra URLs infectadas que no creaste: example.com/?param=malware o redirecciones a sitios de phishing. Los clientes se quejan de popups o redireccionamiento a casinos.

Esto indica inyección de código en la base de datos. Busca en wp_options valores sospechosos con consultas SQL directas.

11. Tráfico anómalo desde IPs bot o patrones raros

Tu hosting reporta picos de uso de CPU sin causa clara. Los logs de Apache muestran cientos de requests a /wp-json/ o /xmlrpc.php desde IPs de datacenters. Tu sitio puede estar siendo usado como cryptominer o botnet.

Revisa logs:

tail -100 /var/log/apache2/access.log | grep -E "wp-json|xmlrpc"

Errores de permisos de carpetas

12. Directorios con permisos 777

Las carpetas criticas no deben ser escribibles por «otros»:

• /wp-content/ debe ser 755 (no 777).
• /wp-content/uploads/ puede ser 755 (a veces 775 si Nginx requiere).
• /wp-admin/ y /wp-includes/ deben ser 755.
• Archivos: 644 (no 666).

Permisos 777 permiten que el servidor web y cualquier script comprometido escriba malware.

13. Propiedad de archivos mal configurada

Si www-data:www-data (tu usuario web) es propietario absoluto de todo, puede modificar el núcleo de WordPress. Lo correcto:

chown -R user:www-data /var/www/html/wordpress

Luego:

chmod -R 755 /var/www/html/wordpress

Errores de base de datos

14. Usuario de base de datos con privilegios ALL

Tu WordPress conecta con un usuario MySQL que tiene GRANT ALL PRIVILEGES en toda la instancia. Esto es peligroso: si la consulta SQL es inyectable, el atacante puede borrar, modificar o extraer cualquier base de datos.

Crea un usuario con privilegios mínimos:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER ON wordpress_db.* TO 'wp_user'@'localhost';

15. Sin copias de seguridad automatizadas

Si no tienes backup, no tienes plan de recuperación. Cuando sufres ransomware o ataque destructivo, pierdes todo. No es «si», es «cuándo».

Implementa backup automático diario mínimo (archivos + base de datos). Soluciones: UpdraftPlus (verificado), BackWPup, o scripts cron manual con mysqldump.

Ausencia de hardening defensivo

16. Sin headers de seguridad HTTP

Si tu sitio no devuelve headers como:

• X-Content-Type-Options: nosniff
• X-Frame-Options: SAMEORIGIN
• Strict-Transport-Security: max-age=31536000 (HSTS)
• Content-Security-Policy (CSP)

entonces eres vulnerable a clickjacking, MIME-type sniffing y otros ataques de navegador.

Añade a .htaccess o tu plugin de seguridad:

<IfModule mod_headers.c>
  Header set X-Content-Type-Options "nosniff"
  Header set X-Frame-Options "SAMEORIGIN"
  Header set X-XSS-Protection "1; mode=block"
</IfModule>

17. Sin protección de wp-json y XML-RPC

/wp-json/ y /xmlrpc.php son vectores clasicos. Los atacantes los usan para:

• Enumerar usuarios (GET /wp-json/wp/v2/users).
• Brute force (XML-RPC permite intentos rápidos).
• Exploits de plugins vía REST API.

Desactiva XML-RPC en wp-config.php:

define('XMLRPC_REQUEST', false);

Restringe wp-json si no lo necesitas, o protégelo con autenticación.

18. Sin WAF o reglas .htaccess anti-ataque

No tienes barrera contra inyecciones SQL, XSS, RFI/LFI típicas. Sin reglas básicas en .htaccess (si Apache) o ubicadas en tu hosting, eres víctima fácil de scanners automáticos que exploran 100.000 sitios/hora.

Regla básica: bloquea parámetros GET peligrosos:

RewriteCond %{QUERY_STRING} (..|./|~|`|^|<|>||) [NC]
RewriteRule .* - [F]

Qué hacer ahora: plan de acción inmediato

Si reconoces 3 o más errores arriba, es urgente:

1. Hoy: Haz backup completo (archivos + BD).
2. Esta semana: Actualiza todos los plugins, temas y WordPress core.
3. Esta semana: Cambia todas las contraseñas de admin y base de datos.
4. Esta semana: Activa 2FA en todas las cuentas admin.
5. Este mes: Implementa hardening completo (permisos, headers, limites de login, WAF).
6. Cada semana: Revisa logs de acceso y Search Console en busca de patrones raros.

Si ya hay comprometiso (archivos extraños, redirecciones, malware), no intentes limpiarlo tú. Es como intentar una cirugía en ti mismo.

Por qué esto importa tanto

En 2024, el tiempo promedio de detección de una brecha es de 210 días. Tu sitio puede estar infectado ahora, sirviendo malware a visitantes, siendo usado para enviar spam, o extrayendo datos de clientes sin que lo sepas. El hardening detecta y detiene el ataque antes de que escale.

Cada error que corriges reduce exponencialmente tu probabilidad de compromiso. No es perfeccionismo; es supervivencia.

Si necesitas auditoría profesional de seguridad, análisis de vulnerabilidades o limpieza de malware, estamos aquí. Contacta conmigo en ManuelFolgar.com/contacto y te haré un diagnóstico sin compromiso. He visto esto cientos de veces: un hardening temprano ahorra miles en daños y frustración.

Tu WordPress merece estar seguro. Hazlo hoy.