WordPress Plugin Security Checklist: What to Audit After Migration Plugin Flaws

Migrating a WordPress site feels like the finish line. The files are moved, the database is imported, the DNS has propagated, and the client is happy. That is exactly when the risk is highest. Migration plugins, the tools that package and move your site, are themselves a common attack surface, and many of them ship with overly broad permissions, leftover backup files, or unauthenticated endpoints that stay live long after the move is done.

Here is the number that should get your attention. Wordfence and other security vendors have repeatedly reported that the vast majority of WordPress compromises trace back to outdated or vulnerable plugins rather than WordPress core itself. A migration often adds a plugin that nobody audits again, and that plugin may be the one with a known flaw. A site that was clean before migration can be exposed within hours of going live if an export file or a debug endpoint was left in the webroot.

This guide is a working checklist for what to audit after a migration plugin has done its job. It covers how to find leftover artifacts, how to evaluate the plugin itself, how to verify file and database integrity, and how to set up monitoring so you catch problems before a client or a crawler does. Each section includes steps you can follow directly, plus a few real-world scenarios that show why each check matters.

Key Takeaways

• Migration plugins frequently leave export archives, backup files, and debug endpoints publicly reachable. Search your webroot and uploads folder before anything else.
• Remove the migration plugin entirely once the move is verified. Deactivating it is not enough, because its code and endpoints often still execute.
• Rotate every credential the migration touched: database passwords, salts, API keys, SFTP accounts, and admin passwords.
• Audit all active plugins against their vulnerability records and update or remove anything abandoned or outdated.
• Check file integrity against a known-good baseline and review recently modified PHP files, especially inside wp-content.
• Set up ongoing monitoring with login alerts, file-change detection, and a scheduled re-audit, because the first 72 hours after migration are not the whole story.

What Is a WordPress Plugin Security Checklist?

A WordPress plugin security checklist is a repeatable set of checks you run to confirm that the plugins on a site are current, necessary, properly configured, and not leaving the site open to attack. It is narrower than a full site audit. It focuses on the code and artifacts that plugins introduce, which is where most real-world compromises begin.

For a migration specifically, the checklist adds a second layer: confirming that the tools used to move the site did not leave anything dangerous behind. That second layer is what most guides skip.

Why Migration Plugins Create Unique Security Risks

Migration plugins do something unusual. They create complete copies of your site, often including the database, the entire wp-content directory, and your configuration, and they write those copies to places that are sometimes web-accessible. They also frequently request elevated privileges, open temporary endpoints for the transfer, and store credentials for remote servers.

Each of those behaviors is reasonable during a migration and dangerous afterward. Four risks come up repeatedly.

• Exposed archives. A full site export saved as a .zip or .sql file in a public directory can hand an attacker your database, including password hashes and API keys.
• Live transfer endpoints. Some plugins expose REST routes or AJAX handlers for the import/export process. If authentication is weak or the route is never removed, it becomes an attack surface.
• Stored credentials. Many migration tools save FTP, SFTP, or database credentials in the options table, sometimes in plain text or weakly encoded form.
• Leftover code. Deactivated plugins and their files stay on disk. Old vulnerable code that never executes is generally lower risk, but any plugin file that still loads through an endpoint or a must-use directory is a live target.

How to Audit for Leftover Migration Artifacts

Start here. This is the highest-yield check because it finds the mistakes that do the most damage and take the least skill to exploit.

Step-by-step: Find exposed archives and dumps

1. Connect to the server over SFTP or SSH and open the webroot (usually public_html or /var/www/html).
2. Search the entire tree for archive and dump files. On a Linux host, run: find /path/to/site -type f \( -name "*.zip" -o -name "*.sql" -o -name "*.tar.gz" -o -name "*.sql.gz" \)
3. For each result, decide whether it belongs. Migration exports almost never do after the move is complete.
4. Check the wp-content/uploads folder separately. Migration plugins often write to wp-content/uploads/backups or a similar path.
5. Delete confirmed leftovers from the server. Do not just move them to another public folder.
6. Test the deletion by requesting the old URL in a browser. You should see a 404, not a download prompt.

A real scenario: A small agency migrated a client's WooCommerce store to a new host in March. The migration plugin generated a 1.8 GB export that was left in wp-content/ai1wm-backups/. Nobody noticed because the folder was never linked anywhere. A scanner that indexed open directories found it three weeks later. The archive contained the full customer table. The agency's cleanup took one rm command. The notification letter to customers took considerably longer.

Step-by-step: Find live debug and transfer endpoints

1. Check the active plugin list in the dashboard, then look in wp-content/mu-plugins/ for must-use plugins, which load automatically and are easy to forget.
2. Open your browser's developer tools and review the REST index at /wp-json/. Look for namespaces that match the migration plugin's name.
3. Look for any debug.log file in wp-content/ and open it in a text editor. Remove it if it contains stack traces or file paths.
4. Remove the migration plugin entirely, not just deactivate it. Confirm the plugin directory is gone from wp-content/plugins/.
5. Reload /wp-json/ and confirm the migration namespace no longer appears.

How to Rotate Credentials After Migration

Assume that any credential the migration tool touched has been seen by the tool, and possibly logged or cached. Rotation is cheap compared with a breach.

1. Change the database user password in your hosting control panel, then update wp-config.php with the new value.
2. Regenerate the authentication keys and salts at the WordPress salt generator, and replace the existing AUTH_KEY, SECURE_AUTH_KEY, and related constants. This logs out all users, which is the point.
3. Reset the password for every administrator and editor account, and review the user list for accounts you do not recognize.
4. Rotate SFTP and SSH passwords, and remove any SFTP account the migration created for itself.
5. Revoke and reissue any API keys that were configured in plugins, including payment gateways, email services, and CDN tokens.
6. Search the options table for leftover credentials. Run a query such as SELECT option_name FROM wp_options WHERE option_value LIKE '%password%' and review each hit.

How to Audit Your Active Plugins

Once the artifacts are gone, turn to the plugins that remain. Migration often brings in new plugins or reveals old ones that were never reviewed. A useful way to think about this is in three buckets: plugins you need and keep up to date, plugins you need but have not updated in a long time, and plugins you do not need at all.

Evaluate each plugin

• Last update date. A plugin not updated in more than 12 months is a warning sign. Abandoned plugins rarely receive security patches.
• Known vulnerabilities. Check the plugin name and version against the WPScan vulnerability database and the Patchstack database. Any unpatched high-severity entry is an immediate action item.
• Permissions requested. A plugin that asks for file system access, outbound network access, or the ability to create users deserves scrutiny. Ask whether the feature requires it.
• Install count and maintainer history. Low installs combined with a single maintainer who has gone quiet is a higher-risk profile than a widely used plugin with an active team.
• Necessity. Many sites run three plugins to do what one could do. Remove any plugin whose function you can no longer name.

Worked example: triaging 23 plugins

Suppose a site has 23 active plugins after migration. Here is one realistic way to triage them.

• 17 are current, maintained, and needed. Keep them and log their versions.
• 3 are needed but outdated by more than 6 months. Find maintained alternatives or update them, and test each on a staging copy first.
• 2 were installed for a feature that no longer exists. Remove them.
• 1 shows an unpatched critical vulnerability in its current version and has no fix. Replace it immediately.

That leaves 20 plugins instead of 23, with 1 critical risk closed and 3 maintenance tasks scheduled. The whole exercise takes an afternoon, and it is the single most effective hardening step most sites will take this year.

Comparing Approaches to Plugin Security Monitoring

Once the site is clean, you need a way to stay that way. Teams typically choose between a few approaches, and each has tradeoffs in cost, coverage, and effort.

Cover image: Innovate Maryland Emerging Technology Center by MDGovpics, licensed under BY 2.0 via Openverse.

Approach	Setup effort	Detects file changes	Alerts on new vulnerabilities	Blocks live attacks	Typical cost
Manual quarterly audit	Low	Only when you look	No	No	Staff time only
Free security scanner plugin	Low	Yes, on schedule	Sometimes	Limited	Free to modest
Hosting-provided security suite	Low	Varies by host	Varies	Often yes	Bundled or add-on
Dedicated firewall and monitoring plugin	Medium	Yes, continuous	Yes	Yes	Moderate subscription