A critical severity vulnerability in a WordPress plugin with more than 90,000 installs can let attackers gain remote code execution to fully compromise vulnerable websites.
Known as Backup Migration, the plugin helps admins automate site backups to local storage or a Google Drive account.
The security bug (tracked as CVE-2023-6553 and rated with a 9.8/10 severity score) was discovered by a team of bug hunters known as Nex Team, who reported it to WordPress security firm Wordfence under a recently launched bug bounty program.
It impacts all plugin versions up to and including Backup Migration 1.3.6, and malicious actors can exploit it in low-complexity attacks without user interaction.
CVE-2023-6553 allows unauthenticated attackers to take over targeted websites by gaining remote code execution through PHP code injection via the /includes/backup-heart.php file.
"This is due to an attacker being able to control the values passed to an include, and subsequently leverage that to achieve remote code execution. This makes it possible for unauthenticated threat actors to easily execute code on the server," Wordfence said on Monday.
"By submitting a specially-crafted request, threat-actors can leverage this issue to include arbitrary, malicious PHP code and execute arbitrary commands on the underlying server in the security context of the WordPress instance."
In the /includes/backup-heart.php file used by the Backup Migration plugin, an attempt is made to incorporate bypasser.php from the BMI_INCLUDES directory (defined by merging BMI_ROOT_DIR with the includes string) at line 118.
However, BMI_ROOT_DIR is defined through the content-dir HTTP header found on line 62, thereby making BMI_ROOT_DIR subject to user control.

Patch released within hours
Wordfence reported the critical security flaw to BackupBliss, the development team behind the Backup Migration plugin, on December 6, with the developers releasing a patch hours later.
However, despite the release of the patched Backup Migration 1.3.8 plugin version on the day of the report, almost 50,000 WordPress websites using a vulnerable version still have to be secured nearly one week later, as WordPress.org org download stats show.
Admins are strongly advised to secure their websites against potential CVE-2023-6553 attacks, given that this is a critical vulnerability that unauthenticated malicious actors can exploit remotely.
WordPress administrators are also being targeted by a phishing campaign attempting to trick them into installing malicious plugins using fake WordPress security advisories for a fictitious vulnerability tracked as CVE-2023-45124 as bait.
Last week, WordPress also fixed a Property Oriented Programming (POP) chain vulnerability that could allow attackers to gain arbitrary PHP code execution under certain conditions (when combined with some plugins in multisite installations).
Comments
PluginVulns - 4 months ago
The story quotes Wordfence claiming that it is possible to "easily execute code on the server," but the vulnerability actually requires one of two significant additional security issues that they notably neglected to mention. Either the attacker would have to be able to upload a file named bypasser.php on the website or the server would have to insecurely allow including remote files. The reason for that is the code allows including a file named bypasser.php from an arbitrary location. So an attacker has to somehow be able to put malicious code in a file with that name that can be accessed by the server. Normally, they wouldn't be able to do that.
Wordfence isn't a reliable source, but if you have to source things to them, please get in touch with us or another security provider who can inform you if inaccurate information is provided in their claims.
Also, there is still a vulnerability in the plugin that we reached out to the developer about two years ago, but they still haven't fixed: https://www.pluginvulnerabilities.com/2021/11/17/vulnerability-details-cross-site-request-forgery-csrf-in-backup-migration/
PluginVulns - 4 months ago
Also, the claim that this "impacts all plugin versions up to and including Backup Migration 1.3.6" isn't accurate either. You appear to be relying on information from Wordfence, but they don't actually determine what versions are vulnerable. The code was introduced in version 1.0.8 and as Wordfence, says, it was still in 1.3.7.