SYSTEM NOTICE

Auto translation by AI. Be sure, accuracy, nuances and authorial intent may not be fully reflected.
見出し画像

[IT][Security] I was so scared by the WordPress plugin backdoor incident that I rushed to check my own site

Hello
everyone

A very nasty type of incident has emerged in the news regarding WordPress plugins.
It is quite concerning.

Backdoors were embedded in multiple plugins that had been sold, and then activated later
is what happened.

This is not just a simple vulnerability issue;
it is being viewed as supply chain contamination via legitimate updates which makes it troublesome.

The report summarizes that malicious code was inserted into a group of older WP Online Support / Essential Plugin series plugins and activated later.

I checked my own WordPress site just to be safe.

To conclude, in my environment,
I did not find any traces directly matching the incident reported this time.

In this article, along with the key points of the incident,
WordPress admin dashboard and rental server file manager only, I will summarize what I checked.

Reference site (blog by Austin Ginder)




First, what happened?

This report states that after multiple WordPress plugins were acquired, backdoors were embedded and then activated some time later.

The report states thatmalicious code was introduced around August 2025 and activated around April 5, 2026 .
It also explains that the target plugins were closed on WordPress.org and forced updates were implemented.

What is particularly nasty about this incident is that
it might not end just by deleting the plugins .

The main points to check according to the report are:

  • Unauthorized file named `wp-comments-posts.php`

  • Unauthorized code added to `wp-config.php`

are mentioned.
In other words,
you have to look not only at the plugin itself, but also at the files on the WordPress core side
as well.


To begin with, were they really that widely used?

One would like to think, 'I wouldn't install such suspicious plugins.'

However, they were not completely unknown.

Among the plugins named this time, there were some that could easily be used as 'convenient free plugins' for small to medium-sized sites or personal sites, such as pop-ups, sliders, FAQs, and list display types,
which is not surprising .

In short, this incident,

  • is not about some suspicious, unused thing being closed

but rather,

  • the fact that a commonly used, practical plugin was compromised

is what I think is scary.


Checking via the WordPress admin dashboard

1. Check if the target plugin is installed

First, I checked
"Installed Plugins" in the WordPress admin dashboard.

I could not find any display names or folder names related to the Essential Plugin series mentioned in this incident.
The report article lists the affected plugins.


2. Check under `uploads` and for administrator users

Open "Users" in the WordPress admin dashboard and check if any unfamiliar administrators have been added.


Checking via File Manager

Since I have not enabled SSH access,
I will check using the rental server's file manager.


Step 1: Open the root directory of WordPress

First, open the location where you can see the following files and folders.

  • `wp-admin`

  • `wp-content`

  • `wp-includes`

  • `wp-config.php`

This is where the main WordPress files are located.


Step 2: Check if `wp-comments-posts.php` exists

`wp-comments-post.php` is normal.

However,
if `wp-comments-posts.php` exists, be careful.

This is a key point to check for this incident.


Step 3: Check the bottom of `wp-config.php`

Open the file and check the very bottom.

If it ends with

require_once ABSPATH . 'wp-settings.php';

then it is normal for now.

If the following follows this,

  • a long, nonsensical string of alphanumeric characters

  • `base64_decode`

  • `eval(`

  • processing that looks like external communication

or similar, be careful.
In this report, additions to `wp-config.php` are considered a significant trace.


Step 4: Check `wp-content/plugins`

Check if any folders for the plugins mentioned this time remain.

Even if they are already disabled, it is useful to see if any remnants exist.
The affected plugins are listed by name in the investigation article.


My check results

In my environment, the status was as follows.

  • No target plugins were found

  • `wp-comments-posts.php` was not found

  • No suspicious additions at the end of `wp-config.php`

  • Everything under `uploads` looks normal

  • No unfamiliar administrator users found

Therefore,
I have determined that, at least within the scope I can check now,
my site is not affected by the backdoor incident currently being reported
.

Of course, I do not intend to claim that it is absolutely safe.
However, the typical signs of this incident are not visible.


What I thought about again regarding this matter

What is truly scary is
not the story about a plugin having a simple bug or vulnerability.

"I trusted the legitimate update path, but the source was contaminated"
is a troublesome scenario.

WordPress.org has an official procedure for transferring plugin ownership.

That in itself is a necessary system, and normal handovers certainly happen.

However, from the user's perspective,

  • It's safe because it's being updated

  • It's fine because it's officially distributed

The reality is that you cannot just say that anymore.


Things to do in the future

I think it would be good to go back to basics and check the following:

  • Keep plugins to the absolute minimum

  • Choose plugins where the developer and update status are visible

  • Delete unnecessary plugins

  • Occasionally check files and users

  • Back up important sites before updating

Regarding this incident as well, it was necessary not only to check for the presence of the target plugin but also to verify any traces left behind after the update, which made me realize the importance of regular inventory checks.


Summary

This WordPress plugin backdoor incident was a
pretty nasty type of supply chain issue.

However, the check points themselves can be narrowed down to some extent.

First,

  • Presence of the target plugin

  • Presence of `wp-comments-posts.php`

  • Check the end of `wp-config.php`

  • Check administrator users

Even just these four are worth checking.
Even if SSH is not allowed, there is a surprising amount you can check via the WordPress admin screen and the hosting service's file manager.


Well then,
see you again


Past articles


  • #CloudService

  • #InfrastructureEngineer

  • #ITEngineer

  • #SystemEngineer

  • #PersonalDevelopment

  • #InfrastructureConstruction

  • #WordPress

  • #Security

  • #SupplyChainAttack

  • #Plugin

  • #WebDevelopment

  • #SiteManagement

  • #RentalServer

  • #Backdoor

  • #InformationSecurity

  • #wordpress

  • #WordPress

いいなと思ったら応援しよう!