all posts

WordPress plugin supply-chain attacks: June 2024 incident notes

Historical notes on the June 2024 WordPress plugin supply-chain attacks, affected releases, and the response at the time.

Historical incident note - June 2024. This article records the reports and response at the time. The versions and statuses below are historical, not a current vulnerability inventory. The temporary update pause discussed below should not be treated as advice to leave software unpatched.

Background

As of June 24th, an ongoing supply chain attack is targeting the WordPress.org plugin repository. The attacker is releasing infected versions of random WordPress plugins, compromising the security of numerous websites and applications that use those plugins.

The issue has been first reported by WordFence threat intelligence in an article.

While it’s impossible to know the scale of the attack, multiple cases have been recorded shown in Figure 1.

PluginVersionDateStatus
SEO Optimized Images2.1.22024-06-28Patched by WP.org
PowerPress Podcasting plugin by Blubrry11.9.42024-06-28Patched by WP.org
Ad Invalid Click Protector (AICP)1.2.92024-06-28Patched by WP.org
WP Server Health Stats1.7.62024-06-28Patched by WP.org
Social Warfare4.4.6.4 – 4.4.7.12024-06-24Patched by Author
Blaze Widget2.2.5 – 2.5.22024-06-24Patched by WP.org
Wrapper Link Element1.0.2 – 1.0.32024-06-24Patched by WP.org
Contact Form 7 Multi-Step Addon1.0.4 – 1.0.52024-06-24Patched by WP.org
Simply Show Hooks1.2.12024-06-24Patched by WP.org
Figure 1: List of affected plugins (source: WordFence & me)

The malicious code injected into the source code of the affected plugins performs several harmful actions:

1. Creation of administrator accounts

The code creates unauthorized admin accounts and sends the login details to a remote source, such as the IP address 94.156.79.8.

2. Injection of malicious code in your theme

It also injects malicious code into the WordPress theme’s functions.php file.

Attack Origins

The origin of the supply chain attack is currently unclear. It may be stemming from compromised WordPress.org developer accounts or an internal security incident, hopefully we will get more details soon.

Attack Response

As a crucial first step, the WordPress Plugin Directory Team temporarily closed the infected plugins to prevent further spread of malicious code.

Suspended WordPress plugin
Figure 2: Suspended WordPress plugin

Next, they proceed with removing the injected malicious code from affected plugins. They are also adding an admin notice to inform users about the issue and the steps taken to address it. This ensures users are aware of the incident and can take any necessary actions to protect their sites.

Figure 3: Development log during attack

Finally the WP.org team is tagging patched version on behalf the author.

Prevention Measures

1. Take control of the plugin updates

During an active incident, a temporary pause can keep an unreviewed release out of production while you identify affected plugins and obtain a verified replacement. Assign someone to review the pause and resume updates; disabling updates indefinitely creates a different risk.

The following filter disables automatic plugin updates globally. It does not remove an existing compromise. If used during incident response, document the change and remove it when the pause ends:

add_filter( 'auto_update_plugin', '__return_false' );

2. Install updates manually

Check the affected versions and remediation instructions against the incident advisory and the plugin’s official release information. A clean scanner result or an uneventful changelog does not prove that a release is safe. Test the replacement and investigate the site for signs of compromise before treating the incident as resolved.

If you spot any issues or found infected plugin, report it to [email protected].

3. Backup your WordPress install regularly

Regularly back up your sites to ensure you can restore them in case a plugin gets infected through auto-update.

Comments

Loading comments…

← older
How to resolve Docker Desktop login issue on Ubuntu/Debian
newer →
Configure upstream DNS resolution in K3s