During a recent WordPress malware investigation, I found this code at the beginning of a plugin file:
<?php
if (file_exists(dirname( __FILE__ ) . '/class.plugin-modules.php')) {
include_once(dirname( __FILE__ ) . '/class.plugin-modules.php');
}
?>
It is only one short line, and the rest of the file looked like normal plugin code.
But the referenced file name immediately stood out:
class.plugin-modules.php
This is a well-known indicator associated with WP-VCD , a WordPress malware campaign historically distributed through nulled or pirated plugins and themes.
The infected plugin in this particular case was old and inactive. However, the plugin name was not the most important finding. The same deployment method can appear inside many different premium plugins and themes downloaded from unofficial sources.
That is what makes WP-VCD dangerous: the nulled plugin or theme is often only the initial carrier. Once activated, the malware can copy itself into themes, modify WordPress core files, communicate with external servers and spread to other WordPress installations under the same hosting account.
Deleting the original plugin may therefore remove the source package while leaving the active infection behind.
What is WP-VCD malware?
WP-VCD is a WordPress malware family that became widely known between 2017 and 2019. It was distributed mainly through websites offering pirated versions of paid WordPress plugins and themes.
Instead of exploiting a vulnerability in WordPress, the campaign relied on site owners installing the malware themselves.
A user would search for a free copy of a premium theme or plugin, download a modified ZIP file and install it through WordPress. The package looked functional, but additional PHP files had been added before distribution.
Wordfence documented that WP-VCD packages commonly included either:
class.plugin-modules.php
or:
class.theme-modules.php
The legitimate plugin or theme was then modified so that the extra file executed when the software was activated. Wordfence also documented persistent backdoors, command-and-control communication, black-hat SEO activity and malicious advertising across infected sites. (Wordfence)
Although the campaign is old, old nulled packages are still present on websites, backups, staging installations and abandoned hosting accounts.
How to recognize the initial loader
A typical loader looks similar to this:
<?php
if (file_exists(dirname( __FILE__ ) . '/class.plugin-modules.php')) {
include_once(dirname( __FILE__ ) . '/class.plugin-modules.php');
}
?>
A theme-based version may load:
class.theme-modules.php
The code itself performs three simple actions.
It identifies the current directory
dirname( __FILE__ )
This returns the directory containing the current PHP file.
It checks whether the deployer exists
file_exists(...)
The loader does not produce an error when the referenced file is missing.
It executes the deployer
include_once(...)
If the file exists, PHP loads and executes it.
This means the small line in functions.php is not the complete malware. It is only the entry point to a second file containing the installer or deployer.
The legitimate-looking structure is intentional. Wordfence noted that WP-VCD often avoided heavy obfuscation and instead hid behind ordinary filenames and code that could be overlooked during a quick inspection.
The carrier is not always the active infection
It helps to separate three parts of a WP-VCD compromise:
Carrier
↓
Deployer
↓
Persistent backdoors and remote payloads
The carrier
This is the nulled plugin or theme downloaded by the site owner.
It may still function exactly like the original premium product, making the package appear trustworthy.
The deployer
This is commonly:
class.plugin-modules.php
or:
class.theme-modules.php
Its job is to install the infection in other locations.
The persistent infection
After deployment, malicious code may continue running from theme files, WordPress core files or neighbouring WordPress installations.
This distinction explains why an inactive plugin may still be important evidence.
The plugin may no longer be executing, but it may identify how the compromise originally started.
How WP-VCD spreads after activation
Historical versions followed a multi-stage deployment process.
1. The nulled software is activated
The modified plugin or theme loads the added deployer file.
2. Installed themes are scanned
The deployer searches the site for WordPress themes.
3. Backdoor code is added to theme files
WP-VCD has been documented injecting code into the functions.php file of every installed theme, not only the active theme.
4. Modification times may be restored
After editing the files, some versions restored their previous modification timestamps. This made the files look older and reduced the usefulness of sorting by “Last Modified.”
5. The site is registered with command-and-control infrastructure
The malware can send information about the infected site to an attacker-controlled server.
6. Other WordPress installations are discovered
The deployer may move through the hosting directory structure and look for additional WordPress sites.
7. WordPress core is modified
Documented versions created:
/wp-includes/wp-vcd.php
and modified:
/wp-includes/post.php
so that wp-vcd.php executed during normal WordPress requests.
This created a persistent reinfection loop. If a backdoor was removed from a theme, wp-vcd.php could write it back during a later page request.
A simplified infection chain looks like this:
Nulled plugin or theme
↓
class.plugin-modules.php
or class.theme-modules.php
↓
Backdoors injected into theme functions.php files
↓
wp-includes/wp-vcd.php created
↓
wp-includes/post.php modified
↓
Remote instructions and additional payloads
↓
Other WordPress installations may be infected
A useful forensic clue: the deployer may remove its own installer
One of the more interesting WP-VCD behaviours is that the initial deployer may remove its installation code after it finishes spreading the malware.
The original class.plugin-modules.php or class.theme-modules.php file may therefore appear nearly empty when it is discovered later.
Wordfence documented versions that removed the code located between their installation markers and left only a line similar to:
<?php error_reporting(0); ?>
This can create confusion during cleanup.
Someone may open the file, see almost nothing dangerous and assume it was a false positive. In reality, the file may already have completed its purpose and copied the backdoors elsewhere.
This also means the original carrier can be useful for identifying the first infected site in a hosting account. Other sites may contain wp-vcd.php and modified theme files, while only the original installation contains the initial plugin or theme deployer.
What problems can WP-VCD create?
The visible symptoms are not identical on every infected site.
WP-VCD’s controllers could send additional code from remote infrastructure, allowing the behaviour to change without updating the original nulled plugin or theme. Historically documented monetization included black-hat SEO and malicious advertising. (Wordfence)
1. Popups and unwanted advertising
Visitors may experience:
- Unexpected popups
- New browser tabs
- Full-page advertisements
- Fake download offers
- Browser-notification prompts
- Adult, casino or scam advertisements
- Advertisements that appear only occasionally
The administrator may not see the same behaviour during every test.
Conditional malware commonly limits how often it targets one visitor, or avoids displaying the payload to logged-in administrators. As a result, a site owner may check the homepage and conclude that nothing is wrong while actual visitors continue receiving unwanted content.
2. Redirects to suspicious websites
Remote payloads may redirect visitors away from the legitimate site.
The redirect may happen only:
- On mobile devices
- On the first visit
- After arriving from a search engine
- On selected posts
- In specific countries
- While logged out
- Without an existing browser cookie
These conditions make the infection difficult to reproduce consistently.
The website can appear normal on the owner’s computer but redirect real customers to advertising, fake downloads, scams or other unwanted destinations.
3. Hidden backlinks and black-hat SEO
WP-VCD used infected sites to promote the websites distributing the nulled software.
The campaign could inject backlinks or other SEO-related code into compromised websites. This created a self-supporting distribution system:
- Nulled-software sites distributed infected packages.
- New victims installed those packages.
- Compromised sites generated backlinks or traffic for the distributors.
- The distributor websites gained greater search visibility.
- More people discovered and downloaded the infected packages.
Wordfence found that the campaign could remotely deploy SEO-manipulation code to infected sites rather than storing all monetization behaviour inside the original deployer.
For the victim, this may result in:
- Hidden links
- Spam anchor text
- Links appended to content
- Off-screen HTML
- Unrelated keywords in Google Search Console
- Search impressions for suspicious terms
- Reduced trust in legitimate pages
4. Remote PHP execution
The theme backdoor could receive new code from command-and-control servers and execute it on compromised websites.
This is more serious than one fixed redirect.
Once an attacker can deliver and execute new PHP, the visible behaviour can be changed at any time. One infected website may show popups, another may inject links, and another may appear quiet while retaining the same underlying access.
Wordfence documented fallback C2 addresses and a mechanism for changing the primary C2 domain, helping the campaign survive individual infrastructure disruptions. (Wordfence)
5. Cached payloads in wp-tmp.php
WP-VCD also used a fallback mechanism for remote payloads.
Code received from the C2 server could be saved locally as:
wp-tmp.php
If the remote servers later failed to respond, the malware could execute the most recently cached payload instead.
This means an unavailable C2 domain does not automatically make the site clean. Previously delivered code may still exist locally.
6. Rogue WordPress administrator accounts
Earlier WP-VCD variants were documented creating an administrator account with these details:
Username: 100010010
Email: te@ea.st
That account would appear in the normal WordPress database tables and could provide another way to access the dashboard.
A rogue administrator can be used to:
- Upload another plugin
- Edit theme files
- Disable security tools
- Add spam content
- Create more accounts
- Change settings
- Re-establish access after file cleanup
The absence of this exact username does not prove the site is safe. It was associated with particular versions, and different or secondary payloads may create different accounts.
7. Repeated reinfection
One of the most frustrating symptoms is malware that appears to return after removal.
For example, an administrator deletes:
wp-vcd.php
or removes malicious code from one theme.
A few hours later, the file or code reappears.
This normally means another persistence point remains active:
- A different infected theme
- A modified
wp-includes/post.php - The original deployer
- A cached payload
- Another compromised plugin
- An infected staging site
- Another WordPress installation in the same account
The malware is not returning from nowhere. A component that was not removed is rebuilding the deleted component.
8. Multiple infected themes
WP-VCD did not limit itself to the active theme. Historical deployers scanned installed themes and injected their functions.php files.
A website might therefore contain malicious code in:
/wp-content/themes/current-theme/functions.php
/wp-content/themes/old-theme/functions.php
/wp-content/themes/default-theme/functions.php
/wp-content/themes/unused-theme/functions.php
Cleaning only the active theme can leave several copies behind.
Unused themes should either be inspected and replaced or removed.
9. Cross-site infection inside one hosting account
WP-VCD’s lateral propagation is one of its most important behaviours.
Documented versions moved upward through the directory structure and then searched for additional WordPress installations in the same hosting environment. Detected sites could receive wp-vcd.php and the related core modification.
This matters when a hosting account contains:
/public_html/
/public_html/blog/
/public_html/shop/
/public_html/staging/
/public_html/old-site/
/public_html/client-site/
The forgotten staging site may be the infection source.
Cleaning the main domain while leaving another installation compromised can result in reinfection.
10. WordPress core modification
A modified core file can execute during normal page requests while the site continues to work.
This makes the infection less visible than a broken site.
The most notable historical indicators include:
/wp-includes/wp-vcd.php
/wp-includes/wp-tmp.php
/wp-includes/post.php
However, cleanup should not be limited to those exact files. Once unauthorized PHP has executed, other files may also have been added or altered.
11. Misleading file dates
The deployer could reset the modification timestamps of infected theme files after writing the backdoor.
Therefore, this approach is not reliable by itself:
“I sorted the files by modification date and found nothing recent.”
A file showing a date from several years ago may still have been modified later.
Use file dates together with:
- Clean-package comparisons
- Checksums
- Code searches
- File hashes
- Access logs
- Malware signatures
- Unexpected ownership or permissions
12. Search-engine and reputation damage
Redirects, unwanted advertising and injected links can damage a domain’s search visibility and reputation.
Possible consequences include:
- Irrelevant queries in Search Console
- Ranking loss
- Spam pages or links being indexed
- Browser warnings
- Antivirus detections
- Hosting malware notices
- Reduced visitor trust
- Lower conversion rates
These effects may remain after the visible malware has been removed. Search engines and security vendors may need time to recrawl the website, and some warnings require a review request after the cleanup is completed.
13. Hosting suspension and resource usage
A hosting company may suspend an infected account after finding malicious PHP, spam redirects, repeated reinfection or unsafe activity.
Remote requests, repeated file writes and injected scripts may also contribute to:
- Higher CPU usage
- Increased PHP activity
- Slow page generation
- Additional bandwidth use
- Intermittent timeouts
- Large malware scan reports
A host may provide a list containing only the files its scanner recognized. That list should not be treated as a complete map of the compromise.
14. Possible exposure of stored secrets
Finding WP-VCD confirms that unauthorized PHP executed on the server.
It does not automatically prove that every password or API key was stolen. However, arbitrary PHP can read files and access information available to the hosting account.
Credentials should therefore be considered untrusted until rotated, including:
- WordPress administrator passwords
- Hosting credentials
- FTP or SFTP accounts
- Database credentials
- SMTP passwords
- API keys
- WordPress authentication salts
Does WP-VCD store malware in the database?
WP-VCD is primarily a file-based infection , but database artifacts may also exist.
This distinction is important.
The main components generally appear as PHP files:
class.plugin-modules.php
class.theme-modules.php
wp-vcd.php
wp-tmp.php
modified theme functions.php files
modified WordPress core files
However, the database may contain secondary evidence.
Rogue users
Check:
wp_users
wp_usermeta
Look for unknown administrators, especially the historically documented 100010010 account.
Scheduled events
WordPress cron events are stored inside the cron option in:
wp_options
Not every WP-VCD infection creates a malicious cron event, but the schedule should still be reviewed for unknown hooks.
Suspicious options and widgets
Additional payloads may store scripts, links or settings in:
wp_options
widget_* options
theme_mods_* options
Injected posts or metadata
Search:
wp_posts
wp_postmeta
for unexpected scripts, hidden links, spam posts and unrelated content.
A clean database does not prove that WP-VCD has been removed. The primary persistence may remain entirely inside files.
Likewise, deleting one suspicious database user does not clean modified PHP files.
Can an inactive plugin still be dangerous?
An inactive plugin normally does not load through WordPress’s standard active-plugin system.
But an inactive nulled plugin can still be important in three ways.
It may have been active in the past
The deployer may already have copied the malware into themes and WordPress core files.
Deactivating the original plugin does not reverse those changes.
Another file may load it directly
A compromised theme, MU plugin or custom PHP file can load code without depending on WordPress’s active-plugin list.
It can identify the original entry point
An inactive nulled package containing class.plugin-modules.php may reveal how the server was first compromised.
Therefore, the correct conclusion is not:
“The plugin is inactive, so it cannot be responsible.”
The more accurate conclusion is:
“The plugin may no longer be the active persistence point, but it may have been the original carrier.”
How to detect WP-VCD
Take a full backup before deleting or editing anything.
Search for known filenames
With SSH:
find /path/to/public_html -type f \
\( -name "class.plugin-modules.php" \
-o -name "class.theme-modules.php" \
-o -name "wp-vcd.php" \
-o -name "wp-tmp.php" \)
Search for known code markers
grep -RInE \
'class\.(plugin|theme)-modules\.php|WP_V_CD|WP_CD_CODE|theme_temp_setup|wp_temp_setup|100010010' \
/path/to/public_html
Search for the loader
grep -RIn \
"dirname( __FILE__ ).*class.plugin-modules.php" \
/path/to/public_html
Also search for the theme equivalent:
grep -RIn \
"dirname( __FILE__ ).*class.theme-modules.php" \
/path/to/public_html
Verify WordPress core
wp core verify-checksums
WP-CLI compares installed WordPress core files against official WordPress.org checksums and reports files that do not match. It performs this check before fully loading WordPress. (WordPress Developer Resources)
To include unexpected files in the WordPress root:
wp core verify-checksums --include-root
Verify WordPress.org plugins
wp plugin verify-checksums --all
WP-CLI can compare plugins available through WordPress.org against their official checksums. (WordPress Developer Resources)
Premium, custom and privately distributed plugins may not have public checksums. Compare those manually against clean packages downloaded from their original vendors.
Review administrator users
wp user list --role=administrator
Check every account with the site owner.
Do not assume an account is legitimate because its username looks normal.
Review scheduled events
wp cron event list
Investigate unfamiliar hooks, especially those calling unknown files or functions.
Do not delete every cron event. WordPress and legitimate plugins depend on scheduled tasks.
Check the database
Replace wp_ with the site’s real table prefix.
SELECT
ID,
user_login,
user_email,
user_registered
FROM wp_users
ORDER BY user_registered DESC;
Check important options:
SELECT
option_name,
LEFT(option_value, 500) AS option_preview
FROM wp_options
WHERE option_name IN (
'active_plugins',
'recently_activated',
'cron'
);
Search for readable indicators:
SELECT
option_id,
option_name,
LEFT(option_value, 500) AS option_preview
FROM wp_options
WHERE option_value LIKE '%wp-vcd%'
OR option_value LIKE '%wp-tmp%'
OR option_value LIKE '%class.plugin-modules%'
OR option_value LIKE '%class.theme-modules%'
OR option_value LIKE '%100010010%';
No results do not guarantee a clean database. Payloads may be encoded, stored under unrelated names or absent from the database completely.
How to remove WP-VCD completely
Removing only the first loader line is not enough.
A full cleanup should cover the entire hosting account.
1. Preserve evidence
Before deleting the malware, save a quarantined copy outside the public web directory.
Record:
- Suspicious filenames
- File hashes
- File sizes
- Modification times
- Plugin and theme names
- Database findings
- Unknown users
- Scan reports
- Relevant access-log entries
This can help identify the original carrier and explain later reinfection.
2. Remove all nulled software
Delete the entire infected plugin or theme directory.
Do not reinstall the same ZIP.
Replace required software with an official copy from:
- The original developer
- A reputable marketplace
- The WordPress.org repository
3. Inspect every theme
Check the functions.php file of every installed theme.
Do not limit the investigation to the active theme.
Replace official themes with clean copies and remove unused themes that are not required.
4. Replace modified WordPress core files
Verify checksums and replace modified core files with clean files from the matching official WordPress release.
Pay particular attention to:
/wp-includes/post.php
/wp-includes/wp-vcd.php
/wp-includes/wp-tmp.php
Do not overwrite wp-content or wp-config.php without understanding what will be lost.
5. Compare all plugins with clean packages
For WordPress.org plugins, use checksum verification.
For premium plugins, compare the complete directory against a newly downloaded licensed copy.
Look for:
- Additional PHP files
- Modified plugin headers
- Code before the normal opening comments
- Unexpected remote URLs
- File-writing functions
- Unknown include statements
- Third-party distributor branding
6. Inspect MU plugins and drop-ins
Check:
/wp-content/mu-plugins/
/wp-content/advanced-cache.php
/wp-content/db.php
/wp-content/object-cache.php
/wp-content/sunrise.php
These files can execute independently from the normal active-plugin list.
7. Review the database
Remove unauthorized administrator accounts.
Inspect cron, options, widgets, posts and post metadata.
Do not perform broad search-and-delete operations without reviewing the results. Legitimate page builders and plugins may contain scripts, encoded values and serialized data.
8. Scan every site under the account
Include:
- Main websites
- Addon domains
- Subdomains
- Staging sites
- Development copies
- Old installations
- Forgotten backups containing executable PHP
One compromised installation can undermine the cleanup of the others.
9. Rotate credentials
Change:
- Hosting password
- WordPress administrator passwords
- SFTP and FTP passwords
- SSH credentials
- Database password
- Control-panel credentials
- Connected email passwords where necessary
Regenerate WordPress authentication salts after the files are clean.
10. Update and harden WordPress
After cleaning:
- Update WordPress
- Update plugins and themes
- Remove unused software
- Disable dashboard file editing
- Enable two-factor authentication
- Review file permissions
- Restrict administrator access
- Add file-integrity monitoring
- Review access logs
- Keep off-site backups
11. Retest as an ordinary visitor
Test the website:
- While logged out
- In a private browser
- From a mobile device
- On another network
- Through several landing pages
- After arriving through a search result
Do not rely only on the administrator’s usual browser.
12. Request security and search reviews only after cleanup
After confirming the website is clean:
- Request a new hosting scan
- Review Google Search Console
- Remove spam URLs where appropriate
- Request blacklist reconsideration
- Monitor indexed pages and search queries
- Watch for file changes and reinfection
Common WP-VCD cleanup mistakes
Deleting only the nulled plugin
The plugin may have already copied backdoors elsewhere.
Removing only wp-vcd.php
An infected theme or neighbouring installation may recreate it.
Cleaning only the active theme
Inactive themes may contain the same backdoor.
Trusting old timestamps
WP-VCD could restore earlier modification times after changing files.
Ignoring the database
Rogue users or secondary artifacts may remain.
Checking only the database
The main persistence is usually file-based.
Scanning only the visible domain
Other WordPress installations under the account may be infected.
Reusing an old backup without scanning it
A backup created after the original infection may contain the same nulled package and backdoors.
Requesting blacklist removal too early
A failed review can delay recovery if persistence mechanisms are still present.
Indicators of compromise
| Indicator | Location or type | Confidence |
|---|---|---|
class.plugin-modules.php |
Nulled plugin | High |
class.theme-modules.php |
Nulled theme | High |
| Loader referencing either modules file | Modified PHP file | High |
wp-includes/wp-vcd.php |
WordPress core area | High |
Modified wp-includes/post.php loading wp-vcd.php
|
WordPress core | High |
WP_V_CD or WP_CD_CODE
|
Code marker | High |
Administrator 100010010
|
Database | High when present |
wp-tmp.php |
Cached payload | Medium to high |
theme_temp_setup |
Function name | Medium |
| Unofficial distributor branding | Supply-chain evidence | Medium |
| Old timestamps on modified theme files | Forensic clue | Low by itself |
| Popups or conditional redirects | Symptom | Low by itself |
The indicators should be considered together. A generic function such as include_once() or file_get_contents() is not malicious by itself.
A recent real-world discovery
In the case that led me to revisit WP-VCD, I found the loader inside an inactive nulled premium plugin.
The plugin name was not the important part. Other users may find the same loader inside completely different plugins or themes.
The important details were:
- The package had been redistributed by an unofficial source.
- Its legitimate PHP file had been modified.
- It loaded
class.plugin-modules.php. - The plugin was inactive but had probably been installed for years.
- The rest of the hosting account still needed to be examined.
This case is a reminder that old malware can survive as forgotten code even when its original campaign is no longer receiving much attention.
A website does not become clean because the malicious plugin is inactive, the old C2 domain is unavailable or the site currently shows no redirect.
The real question is whether the deployer had already completed its work.
Frequently asked questions
What is class.plugin-modules.php?
It is a filename historically used as the primary deployer inside plugins modified by the WP-VCD campaign.
It is not a standard WordPress core file.
What is class.theme-modules.php?
It serves a similar purpose inside a modified or nulled theme.
Is the one-line loader the complete malware?
No. It checks for another file and executes it. The referenced file may then install backdoors in other locations.
Can WP-VCD infect an official plugin?
The campaign generally distributed modified copies of legitimate paid software through unofficial sites. The original plugin developer may have had no involvement.
Does an inactive plugin still run?
Normally it does not load through the standard WordPress active-plugin system. However, it may have executed earlier and created persistent files elsewhere.
Does WP-VCD infect the WordPress database?
Its main persistence is generally file-based. Some variants created a rogue administrator, and additional payloads may leave options, cron events or injected content in the database.
Why does WP-VCD come back after removal?
Another infected file, theme, site or cached payload is probably recreating the component that was deleted.
Can WP-VCD infect more than one website?
Documented versions searched for other WordPress installations in the same hosting environment and deployed additional malware to them.
Is deleting wp-vcd.php enough?
No. You must identify what created it and inspect themes, core files, plugins, database records and other installations.
Can a scanner remove WP-VCD completely?
A scanner can identify known signatures, but complete remediation also requires file-integrity verification, clean-package comparison, database review and an account-wide investigation.
Final conclusion
WP-VCD is an old WordPress malware family, but the lessons from it remain relevant.
The campaign succeeded because users installed compromised premium plugins and themes themselves. Once activated, the deployer could modify themes, add persistent core files, contact external servers and spread to additional WordPress installations.
The original nulled package may later be inactive, deleted or almost empty.
That does not mean the compromise is gone.
The most important principle is to distinguish between the carrier and the active persistence :
The nulled package brought the malware in.
The deployer spread it.
Other files may now be keeping it alive.
When class.plugin-modules.php, class.theme-modules.php or wp-vcd.php is found, treat the entire hosting environment as potentially compromised.
Preserve the evidence, replace unauthorized software, verify core files, inspect every theme, review the database, scan neighbouring installations and rotate credentials.
Anything less can leave the component that brings the malware back.
Top comments (0)