Por qué tu web WordPress ha sido hackeada (y cómo evitarlo)
Guía para identificar vectores habituales en WordPress, priorizar controles y preparar una recuperación verificable.
Autor y revisor: Jon González
No es personal, es automático
“¿Quién va a querer hackear mi web de fontanería? Si no guardo tarjetas de crédito”.
Los ataques automatizados no seleccionan siempre por tamaño: buscan versiones expuestas, credenciales débiles y configuraciones conocidas. El objetivo puede ser abusar de tus recursos de servidor, alterar contenido o acceder a datos.
Hackean tu web para:
- Enviar miles de correos SPAM desde tu servidor (hasta que Google te mete en lista negra).
- Alojar páginas de phishing de bancos (suplantación de identidad).
- Minar criptomonedas usando la CPU de tus visitas.
- Redirigir a tus clientes a webs de apuestas o porno (SEO Japones).
Y lo peor: lo hacen bots. Robots que escanean internet 24/7 buscando vulnerabilidades conocidas. Si tienes una puerta abierta, entrarán. No te preguntarán.
Las 3 Puertas Abiertas más Comunes
1. El Plugin “Zombie”
Ese plugin de “calendario de eventos” que instalaste hace 3 años y nunca usaste. El desarrollador dejó de actualizarlo en 2024. Hoy, en 2026, se ha descubierto un agujero de seguridad en ese plugin.
Tú ni te acuerdas de que lo tienes. El bot sí lo ve.
Solución: Auditoría de plugins. Si no lo usas, bórralo. Si lo usas, asegúrate de que tiene actualizaciones recientes. En Croqueta Digital, monitorizamos las actualizaciones de seguridad diariamente.
2. “admin” y “123456”
Parece broma, pero el usuario más común en WordPress sigue siendo “admin”.
Un nombre de usuario predecible reduce la incertidumbre del atacante, pero la protección real depende de contraseñas únicas, MFA, límites de intento, alertas y controles del proveedor. Cambiar el nombre no sustituye esas capas.
Solución:
- Crea un usuario nuevo con nombre difícil (ej:
web_master_cd26). - Borra el usuario “admin”.
- Usa contraseñas de 16 caracteres generadas aleatoriamente.
- Activa el 2FA (Doble Factor de Autenticación).
3. Hosting Compartido Barato
En un hosting compartido, el riesgo depende del aislamiento entre cuentas, parches, permisos, monitorización y respuesta del proveedor. El precio o el número estimado de vecinos no demuestra por sí solo que pueda producirse un movimiento lateral.
Solución: Hosting VPS aislado. Tu parcela, tus muros. Nadie entra.
El Coste del Desastre
Limpiar una web hackeada es infinitamente más caro que mantenerla segura.
- Coste técnico: horas de análisis, limpieza, reinstalación, recuperación, validación y seguimiento; debe estimarse según alcance y evidencia.
- Coste reputacional: Google pone una pantalla roja gigante a tus visitas: “Este sitio web puede dañar tu ordenador”. Adiós confianza.
- Coste SEO: Si Google detecta malware, te desindexa. Desapareces. Recuperar esas posiciones puede llevar meses.
Dormir Tranquilo cuesta menos que un Café al día
El mantenimiento web no es un gasto; es un seguro.
En nuestros planes de Mantenimiento WordPress, nosotros somos los porteros de discoteca.
- Escaneo de malware cada 6 horas.
- Firewall WAF que bloquea a los bots rusos antes de que toquen tu web.
- Copias de seguridad en la nube (off-site) por si acaso.
No esperes a ver la pantalla roja de la muerte. Protege tu activo digital hoy.
Ampliación editorial · revisión 2026
La decisión central de esta guía
¿Por qué se compromete una web WordPress?
Suele intervenir una combinación de software vulnerable, credenciales débiles, permisos excesivos, hosting expuesto, plugins abandonados y falta de monitorización. WordPress es visible por su uso, pero el riesgo depende del inventario y controles, no de una condena automática del CMS.
Aísla y conserva evidencia, cambia secretos desde un equipo seguro, identifica persistencia, restaura o limpia, parchea la causa y monitoriza. No basta con borrar un archivo. Si no conoces alcance, pide respuesta profesional antes de reabrir.
Revisa logs, integridad, usuarios, tareas programadas, archivos, base de datos y tráfico. Documenta versiones y vector probable. Tras recuperar, prueba copias, formularios y accesos. Comunica una brecha cuando corresponda según datos afectados.
No prometas protección absoluta. Reducir plugins ayuda, pero una extensión necesaria y mantenida puede ser segura. Copias conectadas al mismo servidor pueden cifrarse o alterarse; conserva separación y prueba restauración.
Marco técnico
Mantenimiento web basado en prevención y recuperación
Mantener una web significa conservar seguridad, disponibilidad, funcionamiento y capacidad de cambio. Actualizar versiones es una parte. También requiere inventario, staging, copias restaurables, pruebas de negocio, monitorización, responsables y un procedimiento claro cuando aparece una regresión.
El inventario reúne dominio, DNS, hosting, repositorio, CMS, extensiones, certificados, proveedores, secretos y fechas de renovación. Sin él, una alerta puede llegar a una persona sin acceso o una licencia crítica caducar sin dueño. Cada activo se relaciona con un responsable y una criticidad.
Las actualizaciones pasan por staging y una prueba proporcional al riesgo. Una extensión de pago requiere más que comprobar la portada: carrito, formulario, correo, búsqueda o sincronización pueden romperse. El cambio conserva versión, copia, resultado y decisión de despliegue o rollback.
Una copia no existe de forma operativa hasta restaurarse. Se definen objetivo de tiempo y pérdida aceptable, se incluyen base de datos, archivos y configuración, y se practica en un entorno aislado. Confiar en un panel que dice “backup completado” no prueba que los datos sean coherentes ni que el equipo sepa recuperarlos.
La monitorización combina disponibilidad, expiraciones, seguridad, rendimiento y transacciones sintéticas. Una respuesta 200 no confirma que el formulario envíe o el pago se complete. Las alertas tienen severidad, horario y contexto; enviar todas al mismo canal convierte el ruido en ceguera.
Lista de control antes de ejecutar
- 01 Inventario con responsables
Cada activo, proveedor y renovación tiene una persona capaz de actuar.
- 02 Staging representativo
Versiones, datos anonimizados e integraciones permiten probar recorridos críticos.
- 03 Copia restaurada
La recuperación se practica y se cronometra, no solo se programa.
- 04 Pruebas de negocio
Formulario, compra, acceso o sincronización se verifican tras cambios.
- 05 Alertas accionables
Severidad, contexto, responsable y escalado reducen ruido y tiempo de diagnóstico.
- 06 Informe agregado
Cambios, incidentes, capacidad y deuda se revisan periódicamente.
Qué medir para saber si funciona
Controla disponibilidad de recorridos, tiempo de primera respuesta, tiempo de recuperación, cambios con rollback, vulnerabilidades pendientes, antigüedad de copias probadas y errores detectados antes que el cliente. Las métricas deben diferenciar proveedor, infraestructura y aplicación.
La prevención se observa en estabilidad y capacidad de cambio, no en ausencia absoluta de incidentes. Un buen servicio reduce sorpresa, limita impacto y conserva evidencia para aprender. Prometer “cero caídas” oculta dependencias externas y crea una expectativa imposible de gobernar.
Playbook propio de esta guía
Respuesta y prevención ante una intrusión en WordPress
Esta ampliación desarrolla el problema específico de por qué tu web wordpress ha sido hackeada (y cómo evitarlo) y no se reutiliza en otras entradas del Laboratorio.
Contener sin destruir evidencia
Si la web muestra redirecciones, usuarios nuevos o archivos alterados, limita acceso y conserva copia de archivos, base, logs y configuración antes de limpiar. Cambia credenciales desde un equipo seguro y rota claves de WordPress, hosting, base, SFTP, correo y APIs afectadas. No borres al azar: puedes eliminar indicadores y dejar persistencia en tareas, plugins, usuarios o base de datos.
Determina ventana, alcance y datos accesibles. Revisa logs web, autenticación, cambios de archivo, administradores, cron, mu-plugins y contenido inyectado. Compara core y extensiones con fuentes confiables. Si hay datos personales, evalúa obligaciones con asesoramiento adecuado. El objetivo inicial es saber qué controlar y evitar más daño, no reabrir rápido con la misma causa.
Recuperar desde una base confiable
Actualiza o reinstala core, tema y plugins desde repositorios legítimos y elimina componentes abandonados. Restaura contenido solo desde una copia anterior al incidente y comprueba que no contenga la persistencia. Cambia permisos, secretos y usuarios. Prueba formularios, pagos, correo, SEO y caché antes de abrir. Una copia que restaura no está verificada hasta completar tareas reales.
Añade monitorización de integridad, accesos y errores y observa intentos posteriores. Bloquea vectores confirmados sin aplicar reglas genéricas que rompan usuarios. MFA, contraseñas únicas y mínimo privilegio reducen cuenta comprometida. Aislamiento, parcheo y copias externas reducen impacto. Ninguna capa garantiza protección absoluta, por lo que la capacidad de detectar y recuperar forma parte del control.
Prevenir recurrencia
Mantén inventario con versión, propietario, necesidad y fecha de revisión. Prueba actualizaciones en staging y retira lo que no recibe mantenimiento. Protege cadena de suministro evitando copias nulled. Revisa cuentas y tokens trimestralmente. El nombre “admin” no representa la mitad de una credencial: el control real está en autenticación, límites, alertas y permisos.
Ensaya restauración y documenta responsable, contacto y comunicación. Separa copias del servidor para que una intrusión no las modifique. Mide tiempo de parche, extensiones obsoletas, intentos, cambios inesperados y recuperación. La seguridad mejora cuando cada incidente produce una prueba o control específico, no una promesa de “grado militar”.
Reconstrucción del incidente: de la puerta de entrada a la prevención
Cuando un WordPress aparece comprometido, borrar el archivo visible no demuestra que el problema esté resuelto. La investigación preserva primero evidencias: registros disponibles, marcas temporales, usuarios, tareas programadas, plugins, temas y cambios recientes. Se compara el sistema con fuentes conocidas y se busca persistencia en archivos, base de datos, cuentas administrativas, claves y servicios externos. La causa puede ser una vulnerabilidad, una credencial reutilizada, un equipo del administrador infectado o un proveedor expuesto. Afirmar el origen sin evidencia conduce a cerrar una puerta mientras otra permanece abierta. También se revisan otros sitios y cuentas que compartan alojamiento, claves o accesos, porque el alcance puede superar la instalación que mostró el síntoma.
La recuperación más segura parte de copias verificadas o de una reconstrucción limpia. Núcleo, extensiones y tema se obtienen de fuentes confiables; se eliminan componentes sin mantenimiento; se cambian credenciales y salts; y se actualiza el entorno compatible. Antes de reabrir, se revisan permisos, ejecución de PHP donde no corresponde, configuración del servidor y cuentas con privilegios. Las copias de seguridad deben estar separadas del sitio y probarse mediante restauración. Un plugin de seguridad puede añadir señales y barreras, pero no reemplaza actualizaciones, mínimos privilegios ni una administración ordenada. Si se han expuesto datos personales o existe impacto contractual, el responsable debe evaluar las obligaciones de comunicación con asesoramiento adecuado, basándose en el alcance real del incidente.
La prevención se convierte en rutina medible. Se mantiene inventario de dominios, versiones, responsables y fecha de última copia probada. Las actualizaciones se prueban en staging y se aplican con una cadencia definida; los accesos usan autenticación multifactor cuando el servicio lo permite; y cada colaborador dispone de su propia cuenta. La monitorización alerta sobre cambios inesperados, errores, disponibilidad y caducidad de certificados, pero se acompaña de un procedimiento de respuesta. Una alerta que nadie recibe o entiende no reduce riesgo. Tras cada incidente se documentan cronología, causa confirmada, impacto, correcciones y acciones pendientes. Esa revisión transforma un episodio aislado en mejoras concretas y evita que el equipo dependa de recordar qué hizo durante la urgencia.
Comprobaciones antes de cerrar
- 01 Evidencia preservada
Logs, archivos y base se copian antes de alterar el sistema afectado.
- 02 Secretos rotados
Todas las credenciales relacionadas cambian desde un entorno seguro.
- 03 Origen confiable
Core y extensiones se reinstalan desde fuentes verificables.
- 04 Restauración ensayada
La copia se prueba con recorridos funcionales y monitorización posterior.
Actualiza el playbook tras cada incidente y simulacro. Convierte la causa confirmada en una prueba recurrente y elimina controles que solo añaden ruido.
Control editorial
Metodología y fuentes
Los riesgos se priorizan con inventario, versiones, exposición y controles; no se atribuye una probabilidad sin datos.
- INCIBE — Protege tu empresa ↗
Recursos oficiales españoles de ciberseguridad para empresas.
- WordPress — Hardening ↗
Guía oficial de endurecimiento de instalaciones WordPress.
