Una brecha real en WordPress: cómo entró el malware y cómo la cerramos de raíz

La mayoría de los hackeos de WordPress no son obra de un genio del teclado encapuchado. Son mucho más aburridos —y por eso más frecuentes—: alguien deja un plugin desactualizado instalado, un bot automatizado lo encuentra, y entra por esa puerta que llevaba meses abierta.

Hace poco nos tocó limpiar y blindar un caso real. Lo contamos anonimizado (sin nombres ni datos que identifiquen a nadie) porque la historia es la de siempre, y la lección sirve para cualquiera que tenga un WordPress en producción.

1. Cómo entró: una puerta que nadie cerró

El sitio tenía instalado un plugin de subida de archivos ya abandonado por su autor. Ese plugin arrastraba una vulnerabilidad grave: permitía ejecutar código en el servidor sin estar autenticado (lo que en seguridad se llama un RCE, Remote Code Execution).

Traducido: cualquiera, desde fuera y sin ninguna contraseña, podía hacer que el servidor ejecutara instrucciones suyas. El atacante lo usó para dejar un webshell —un pequeño archivo PHP malicioso— dentro de la carpeta wp-content/uploads/. Y con eso, ya tenía una llave permanente para entrar cuando quisiera.

Ninguna parte de esto requirió adivinar la contraseña de nadie. La puerta ya estaba abierta; solo había que encontrarla.

2. Por qué el problema «volvía» cada semana

Aquí está la parte interesante, y la que más gente se salta.

El escáner de seguridad detectaba el malware, se limpiaba… y a los pocos días reaparecía. Daba la sensación de un ataque persistente e imparable. La realidad era más simple y más incómoda:

• El plugin vulnerable seguía instalado. Es decir, la puerta de entrada nunca se había cerrado. Limpiar los archivos infectados sin quitar el vector es como fregar el suelo con el grifo abierto.
• Además, el sistema de alertas no deduplicaba: re-reportaba el mismo hallazgo una y otra vez, dando una impresión de gravedad mayor de la real.

La lección número uno de cualquier incidente: limpiar el malware no es cerrar la brecha. Son dos trabajos distintos. Si solo haces el primero, vas a estar fregando el suelo eternamente.

3. Cómo lo cerramos de raíz (el checklist que aplicamos)

Esta es la parte que te puedes llevar y aplicar hoy mismo en tus webs. No es magia; es higiene.

Cerrar la entrada

• Eliminar o reemplazar el plugin vector. Si un plugin está abandonado y tiene una vulnerabilidad conocida, no se actualiza: se quita. Punto.
• Auditar todos los plugins, especialmente los nulled (versiones pirata) y los que llevan años sin actualizarse. Son la causa número uno de entradas.

Quitarle el suelo al atacante

• Bloquear la ejecución de PHP en uploads/ y en cualquier carpeta donde no debería haber código. Si el atacante consigue subir un webshell pero el servidor se niega a ejecutarlo, su llave no abre nada. Esta sola medida neutraliza una enorme familia de ataques.
• Deshabilitar la edición de archivos desde el panel (DISALLOW_FILE_EDIT en wp-config.php). Si un admin cae, que no pueda reescribir el sitio desde el navegador.

Endurecer los accesos

• 2FA en todas las cuentas de administrador. Innegociable.
• Banear las IPs del atacante y poner el WAF / antimalware en modo bloqueo activo, no en modo «solo aviso». Detectar sin bloquear es ver cómo te roban en directo.

Tapar lo que estaba desactualizado

• Actualizar core, plugins, tema y PHP. Una versión de PHP antigua es una colección de vulnerabilidades conocidas esperando a alguien.

Verificar que de verdad está limpio

• Checksums del core contra los oficiales, cero firmas de malware en un escaneo profundo, y un escaneo de control unos días después para confirmar que no reaparece. Si no reaparece, la puerta está cerrada de verdad.

4. La conclusión que te ahorra el susto

Si te quedas con una sola idea, que sea esta: el 95% de las brechas de WordPress entran por un plugin desactualizado, abandonado o pirata. No por un fallo del núcleo de WordPress, que es de los CMS más auditados del mundo.

La seguridad de WordPress no va de comprar el plugin de seguridad más caro. Va de higiene constante: menos plugins, todos actualizados, ninguno nulled, ejecución de código bloqueada donde no debe haberla, y accesos con 2FA. Aburrido, sí. Pero es lo que funciona.

Y cuando algo entra —que puede pasar—, recuerda: primero se cierra la puerta, después se limpia la casa. En ese orden.

¿No estás seguro de cómo está tu WordPress de salud? Una revisión a tiempo cuesta mucho menos que un incidente. Si quieres que le echemos un vistazo, hablamos.