Encontrar una versión vulnerable convierte al plugin en una entrada plausible, pero no prueba que todos los cambios maliciosos vinieran de él. Tras acceder, un atacante puede crear administradores, tareas y archivos fuera de su carpeta.
Conserva versión y peticiones y reconstruye todo el límite de confianza.
Registra el componente afectado
Captura nombre, fuente, versión, estado y hash o listado antes de actualizar o eliminar. Anota primera actividad maliciosa y última hora conocida como correcta.
No ejecutes el plugin vulnerable en un staging público para reproducir el ataque. Guarda una copia restringida sin ejecutarla. Comprueba si estaba activo, activo en red o simplemente instalado.
Confirma que la vulnerabilidad aplica
Lee el aviso del fabricante o una fuente fiable: versiones, autenticación necesaria e impacto. Compáralo con versión y configuración.
Una vulnerabilidad que exige administrador explica peor un ataque anónimo salvo que ya se hubiera robado una cuenta. Que un exploit público apareciera después tampoco prueba causalidad. Separa evidencia y nivel de confianza.
Correlaciona registros de acceso
Busca peticiones a rutas del plugin, acciones AJAX, REST o archivos subidos durante el inicio. Conserva método, ruta, estado y hora sin copiar cuerpos con datos personales.
Correlaciónalas con archivos modificados, usuarios creados y red o correo saliente. Una IP no atribuye identidad. Si faltan logs, declara esa limitación.
Contén la ruta vulnerable
Desactiva o retira el plugin de ejecución pública, o bloquea su endpoint en una capa fiable. Si sostiene checkout o membresía, ofrece mantenimiento o alternativa segura.
No actualices simplemente y supongas que desapareció el atacante. La actualización cierra una vía, no la persistencia existente. Revisa webs hermanas con el mismo componente o credenciales.
Busca persistencia posterior
Revisa administradores, contraseñas de aplicación, mu-plugins, tareas, wp-config.php, arranque de raíz, PHP en uploads/caché y opciones o widgets.
Examina usuarios de hosting, claves SFTP/SSH, correo, DNS y cron si permitía ejecutar código. Rota secretos de base y aplicación desde un dispositivo limpio. Conserva IDs y archivos antes de retirarlos.
Sustituye código desde fuentes fiables
Instala núcleo, plugins y temas limpios en una raíz nueva o reemplaza componentes tras capturar. Valida desarrollo propio y uploads aparte.
Si el plugin está abandonado, elimínalo y migra la función a una alternativa mantenida. No uses una supuesta versión corregida de un archivo no oficial. Importa únicamente base y contenido evaluados.
Revisa datos creados por el plugin
Los plugins de archivos, formularios o importación pueden guardar datos fuera de su carpeta. Inventaría uploads, tablas propias, tareas y temporales.
No borres esos lugares junto con el plugin hasta evaluar registros de negocio y evidencias. Reconstruye lo necesario en el reemplazo y bloquea ejecución directa en uploads. Rota APIs y webhooks si el código podía leerlos.
Evalúa el impacto
Determina qué permitía la vulnerabilidad y qué muestran los logs. Eleva una posible exposición de clientes o pedidos por el proceso de incidentes.
Reconcilia pedidos, formularios y correo del intervalo. No concluyas que no hubo acceso porque no veas una exportación. Las decisiones de remediación y notificación corresponden a responsables autorizados.
Verifica y monitoriza
Prueba la función sustituta, login, formularios, checkout, cron y correo. Confirma que no hay cuentas o tareas desconocidas ni paquetes vulnerables en otras webs.
Monitoriza archivos, acciones privilegiadas y peticiones al endpoint antiguo. Documenta la entrada probable con evidencia e incertidumbre. Si permitía ejecutar código o el intervalo es incierto, solicita rescate compartiendo aviso, versión y logs censurados, nunca payloads ni datos.
Mantén la alerta durante varios ciclos de cron, copias y actividad comercial. Una petición bloqueada al endpoint antiguo no significa por sí sola reinfección, pero una modificación de archivos o una cuenta nueva exige volver a contener e investigar.