New Malware Campaign Targets WP-Automatic Plugin

A SQL injection vulnerability in the WP‑Automatic plugin has been actively exploited to inject arbitrary database queries, create admin accounts, and deploy web shells/backdoors on WordPress sites. The flaw was publicly disclosed by PatchStack and has generated millions of recorded attack attempts, prompting mitigations including plugin updates and WAF rules. #WP-Automatic #PatchStack

Keypoints

  • Critical SQL injection (SQLi) in WP‑Automatic allows attackers to execute arbitrary SQL against site databases.
  • Exploit can create new admin‑level WordPress users, granting persistent, high‑privilege access.
  • Attackers upload malicious files (web shells/backdoors) and often rename the vulnerable plugin file to hide the exploit.
  • Compromised sites commonly show installation of plugins/themes that enable file uploads or code editing for further control.
  • PatchStack publicly disclosed the flaw on March 13, 2024; monitoring logged 5,576,488 attack attempts with a peak on March 31.
  • Mitigations: update WP‑Automatic, audit/remove suspicious admin users, enable security monitoring/WAF (e.g., Jetpack Scan + Enhance Protection), and maintain backups.
  • Jetpack WAF users received a rule blocking access to the vulnerable PHP file and new malware signatures to detect and clean the campaign.

MITRE Techniques

  • [T1190] Exploit Public-Facing Application – Attackers exploited a web plugin vulnerability via SQL injection to run arbitrary database queries (‘SQL injection (SQLi) flaw’).
  • [T1136] Create Account – The exploit is used to insert or create new admin‑level WordPress accounts (‘create admin‑level user accounts’).
  • [T1078] Valid Accounts – Threat actors use created admin accounts to perform further actions such as installing plugins/themes (‘installed plugins that allowed them to upload files or edit code’).
  • [T1505] Server Software Component – Uploads of malicious server components such as web shells/backdoors were observed to maintain control (‘upload malicious files, typically web shells or backdoors’).
  • [T1027] Obfuscated Files or Information – Compromised sites show obfuscated code to evade detection and maintain persistence (‘obfuscating the code’).
  • [T1036] Masquerading – Attackers rename the vulnerable WP‑Automatic file to prevent detection or block other actors (‘rename the vulnerable WP‑Automatic file’).

Indicators of Compromise

  • [Username] Suspicious admin account – administrator users with names starting with “xtw.” (e.g., xtw.*).
  • [File path] Renamed vulnerable plugin file – original ‘/wp-content/plugins/wp-automatic/inc/csv.php’ observed renamed to paths like ‘/wp-content/plugins/wp-automatic/inc/csv65f82ab408b3.php’.
  • [File Hash (SHA1)] Dropped malicious files – b0ca85463fe805ffdf809206771719dc571eb052 (web.php), 8e83c42ffd3c5a88b2b2853ff931164ebce1c0f3 (index.php).

Affected sites show a consistent technical pattern: attackers exploit an SQL injection in the WP‑Automatic plugin’s authentication handling by sending specially crafted requests that inject arbitrary SQL into the WordPress database. Successful exploitation enables attackers to create administrative accounts (allowing full site control), install plugins or themes that permit file uploads or code edits, and drop web shells/backdoors to execute commands and persist on the server.

To conceal access and block remediation, operators in this campaign often rename the vulnerable file (originally /wp-content/plugins/wp-automatic/inc/csv.php) to a randomized name (for example, csv65f82ab408b3.php) and obfuscate injected code. Detected malicious artifacts include SHA1 hashes b0ca85463fe805ffdf809206771719dc571eb052 (web.php) and 8e83c42ffd3c5a88b2b2853ff931164ebce1c0f3 (index.php); presence of an admin user beginning with “xtw.” is also a strong compromise indicator.

Remediation and hardening steps: immediately update WP‑Automatic to a patched version, audit and remove unauthorized admin accounts, scan for and remove web shells/backdoors (using updated malware signatures), enable a Web Application Firewall/WAF rule to block the vulnerable PHP endpoint (Jetpack WAF rule available), enable enhanced request inspection where possible, and restore from clean backups if needed.

Read more: https://wpscan.com/blog/new-malware-campaign-targets-wp-automatic-plugin/