All-in-One WP Migration and Backup

All-in-One WP Migration and Backup 7.110 and earlier is affected by CVE-2026-89064, an unauthenticated credential-handling flaw. The plugin’s admin_init handler can store credentials from an incoming HTTP Basic Authorization header in a WordPress option without first establishing that the requester is authorized to run a migration. Version 7.111 contains the vendor’s fix.

At a glance

The WordPress.org directory lists more than 5 million active installations. The flaw is rated Medium, but the large install base and involvement of authentication material make prompt updating worthwhile.

What happens

Wordfence reports that Ai1wm_Main_Controller::init() reads PHP’s Basic-auth username and password variables during admin_init. That hook can run for unauthenticated requests to WordPress admin endpoints. In affected versions, the plugin writes the supplied values to the ai1wm_auth_header option as reversibly base64-encoded data without verifying that the request came from an authorized migration administrator.

This is not evidence that an anonymous attacker can directly read the stored value. The confirmed exposure is that credentials presented to relevant requests can be retained in the database, and an unauthenticated party can overwrite that option with attacker-chosen data. Base64 encoding does not protect a credential from anyone who later obtains database or sufficiently privileged option access. Sites using WordPress Application Passwords or HTTP Basic authentication for integrations should review the affected period carefully.

Fix and verification

1. Update all-in-one-wp-migration to 7.111 or later. The vendor’s 7.111 changelog says HTTP authentication credentials are no longer captured for users who lack migration permission.
2. Verify the installed version in the WordPress Plugins screen or with WP-CLI.
3. Review application passwords and HTTP Basic credentials used by integrations that accessed WordPress admin endpoints while an affected release was active. Revoke and replace credentials if database/option access is suspected or if logs show unexpected authentication activity.
4. Ask your hosting or security team to inspect authentication and admin-endpoint logs. Do not paste credential values into tickets, scanners, terminal output, or analytics.
5. If a database review is needed, check whether the option exists and its length without printing the stored secret. Coordinate any removal with the site’s migration/backup workflow.

wp plugin get all-in-one-wp-migration --fields=name,status,version --format=table
wp plugin update all-in-one-wp-migration
wp plugin get all-in-one-wp-migration --field=version

For a read-only check that does not reveal the option contents, replace wp_options with your site’s actual options table if its prefix is not wp_:

SELECT option_name, LENGTH(option_value) AS stored_bytes
FROM wp_options
WHERE option_name = 'ai1wm_auth_header';

A nonzero length is an investigation cue, not proof of theft. Avoid displaying the option’s value. A security update stops the vulnerable behavior but does not automatically establish whether any credential stored earlier has been accessed.

Sources

• Wordfence Intelligence vulnerability record for CVE-2026-89064
• WordPress.org plugin page and 7.111 security changelog

WPDeeply is summarizing the disclosure by Wordfence and the vendor’s release notes; this is not a claim of original discovery.