WordPress malware has evolved significantly over the years. Recent malware incidents show a clear shift from isolated file infections, JavaScript redirects, or database injections toward layered compromises that affect multiple areas of the WordPress installation.
The visible symptom may still look familiar: a browser warning, a strange redirect, a spam post, or a blocklist notice. But the actual infection often sits across several layers, including theme files, database records, cached pages, user accounts, and domain reputation systems.
One recent malware cleanup incident demonstrated this clearly.
A customer’s site was flagged by Google Safe Browsing and several third-party security vendors. At first glance, it looked like a typical SEO spam infection. The database contained hundreds of spam posts and infected revisions, including content targeting casino, betting, poker, roulette, adult, and software activator keywords.
But the database spam was only one part of the compromise.
The active WordPress theme also contained a malicious JavaScript loader in functions.php. This loader used Web3 libraries and Binance Smart Chain infrastructure to retrieve encoded JavaScript through smart-contract calls, decompress it, and execute it in the visitor’s browser.
In other words, this was not just a spam-post incident. It was a layered WordPress compromise combining traditional SEO spam with a more unusual Web3-based JavaScript payload delivery mechanism.
Table of Contents
- A Quick Overview of the Layered WordPress Compromise
- Incident Snapshot
- Layer 1: Database SEO Spam Injection
- Layer 2: Web3 JavaScript Loader in functions.php
- Layer 3: Cache Persistence — The Infection Still Appeared After Cleanup
- Layer 4: Reputation and Email Deliverability Impact
- How the Attack Likely Started
- Conclusion
A Quick Overview of the Layered WordPress Compromise
The investigation found two major infection layers.
The first layer was database-level SEO spam. The database scanner identified 358 spam posts including gambling and casino spam, adult SEO spam post, and KMSPico / Office activator spam post.
The second layer was theme-level JavaScript malware. The active theme’s functions.php file had been modified to inject a script into frontend pages. The script loaded Web3-related libraries, connected to Binance Smart Chain, retrieved encoded JavaScript, decompressed it, and executed it using eval().
The infection also affected the cache layer. Cached WP Rocket pages contained references to the malicious JavaScript even after the source theme code was cleaned.
Incident Snapshot
| Area | Finding |
|---|---|
| Database | Hundreds of SEO spam posts and infected revisions |
| Spam topics | Gambling, betting, casino, adult, KMSPico activator |
| Active theme | Malicious JavaScript loader injected into functions.php |
| Payload method | Web3/BSC smart contract retrieval, decompression, eval() execution |
| Cache | WP Rocket cached infected frontend output |
| Reputation | Google Safe Browsing and third-party vendor flags |
| Customer emails landed in spam during the incident window |
This incident shows how a WordPress compromise can impact more than the website itself. Search visibility, browser trust, vendor reputation, and even email deliverability can all be affected when a domain is abused.
Layer 1: Database SEO Spam Injection
The first visible infection layer was a large SEO spam campaign infecting the WordPress database.
The posts were not random comments or obvious test entries. They were full published posts designed to target search engines. Most of the content focused on gambling-related keywords: casinos, betting offers, free spins, sportsbook pages, poker rooms, roulette strategy, and slot machine terms. Related taxonomies, categories, tags, and terms were also generated for the spam content.
Several known gambling or betting names appeared throughout the content, including 1win, Melbet, Mostbet, Pokerdom, Pokerok, Pin-Up, Eurobet, Vulkan-style terms, R7 Casino, and Vodka Casino.
The content was multilingual and looked spun, machine-translated, or automatically generated. We found English, Russian/Cyrillic, Turkish, Italian, Spanish, Portuguese, and mixed-language patterns. This is typical of SEO poisoning campaigns where attackers abuse a legitimate site’s authority to rank spam landing pages.
The attacker’s goal is usually not to vandalize the site. It is quieter: publish pages that search engines may crawl, index, and associate with gambling, adult, warez, or other high-risk keywords.
This kind of abuse can quickly damage a domain’s reputation.
The KMSPico / Office Activator Post
Apart from the gambling spam, there was a KMSPico / Office activator post that promoted KMSPico / Office 2019 activation and linked to an external activator domain. The post was written to attract users searching for Microsoft Office activation bypasses and then send them to an external activator-related site.
This type of post is high-risk because activator downloads are often associated with potentially unwanted software, malware, or credential theft.
For deleting a large number of spam posts, see this quick guide on how to bulk trash malicious WordPress posts using an MU-plugin.
Layer 2: Web3 JavaScript Loader in functions.php
The second infection layer was more unusual.
The active theme contained a malicious function in functions.php. The function was hooked into wp_head, which meant the injected JavaScript was embedded into the page source.
The script loaded several external libraries and then connected to Binance Smart Chain through a public RPC endpoint. From there, it interacted with a smart contract, retrieved encoded data, decompressed it, and executed the result in the browser.
The high-level flow looked like this:
functions.php → wp_head → Web3 library → BSC RPC → smart contract → encoded payload → decompress → eval()The important point is that the WordPress file did not need to contain the full final payload. The file contained a loader. The payload was pulled indirectly from outside the site.
That makes the malware harder to understand during a quick review. Typical scanners may miss this pattern, but Malcure Malware Shield flagged it as a Web3/BSC loader designed to retrieve, decompress, and execute external JavaScript at runtime.
The malicious function injects three external libraries into the page: web3.min.js, pako.min.js, and crypto-js.min.js. These libraries allow the script to communicate with blockchain infrastructure, decompress encoded data, and handle encoded payload logic inside the browser.
Once the page loads, the script creates a Web3 connection to bsc-dataseed.binance.org, a public Binance Smart Chain RPC endpoint. It then connects to a specific smart contract and calls methods that return encoded contract data, including an ABI, a contract address, and a second-stage payload.
The second-stage payload is returned in an encoded and compressed format. The script decodes it using atob(), decompresses it using pako.ungzip(), and stores the resulting JavaScript as a string.
The final step is the most dangerous part: the decoded JavaScript is executed using eval(). This means the attacker does not need to store the final malicious payload inside the WordPress theme file. The theme only contains a loader, while the executable payload is retrieved externally at runtime.
The suspicious part is not merely the use of Web3. Web3 can be used legitimately in some applications. The malicious pattern is the full chain: inject script into every frontend page, fetch remote encoded data, decode it, decompress it, and execute it with eval() inside the visitor’s browser.
Layer 3: Cache Persistence — The Infection Still Appeared After Cleanup
After the theme injection was removed, indicators were still detected in WP Rocket’s cached page output. It was evidence that the cache had captured the malicious JavaScript during the period when the infection was active, and that cached copy was still being served to visitors and crawlers.
This is a critical aspect of WordPress malware cleanup. A site can be technically clean at the source level while continuing to serve infected output from cache. As a result:
- Visitors may still receive the malicious script due to cached pages.
- Security scanners that crawl live pages may continue to flag the site.
- Google’s crawl and index pipeline may re-encounter the cached malicious output.
- Review requests submitted before cache purging are more likely to fail or be delayed.
In malware incidents like this, full cache purging across WP Rocket, LiteSpeed, hosting/server-level cache, and CDN layers is required before the site can be confidently verified as clean and submitted for blocklist review.
If your site has been flagged by Google, this step-by-step guide explains how to submit a review request for Google blacklist removal.
Layer 4: Reputation and Email Deliverability Impact
The Google blocklist and reputation impact extended beyond Google Safe Browsing and Google Security Issues. During the incident, multiple third-party security vendors had flagged the domain:
- ADMINUSLabs: Malicious
- Fortinet: Malicious
- CyRadar: Malicious
- alphaMountain.ai: Suspicious
Customer emails were also landing in spam. Email deliverability is influenced by a broader set of signals than just Google’s blocklist status. SPF alignment, DKIM signing, DMARC policy, sending IP reputation, and links inside messages pointing to a flagged domain all contribute.
However, in this incident, the email placement issues were most likely a reputation side-effect of the compromised domain and security vendor detections, not a sign of direct mail-server compromise.
How the Attack Likely Started
The spam posts were created under a legitimate WordPress administrator account. This points to compromised WordPress credentials as the likely entry point for the database spam injection.
The active theme modification also required elevated access — WordPress administrator, hosting-level, or filesystem access. This aligns with the same compromise path and explains how the attacker could move from spam post creation to malicious theme modification.
Conclusion
This incident combined a high-volume SEO spam campaign with a technically advanced Web3-based JavaScript payload loader. The spam posts abused the site’s search visibility, while the theme-level loader created a browser-side payload delivery mechanism. Together, they turned a normal WordPress site into a layered compromise affecting the database, active theme, cache, blacklist status, and domain reputation.
This is why WordPress malware analysis cannot stop at the first visible symptom. Unexpected indexed pages, browser warnings, suspicious frontend scripts, blacklist flags, or email deliverability issues should be treated as signs of a wider incident. The database, revisions, theme files, cache layers, user access, and reputation signals all need to be reviewed together.
Surface-level cleanup is not enough for a layered attack. The site has to be audited with both automated tools and manual inspection to confirm there are no hidden files, malicious leftovers, suspicious modifications, infected database records, or cached artifacts. After cleanup, credentials should be rotated, active sessions invalidated, and every cache layer purged.
It is critical to act early if your WordPress site shows similar symptoms. What appears to be simple SEO spam, such as Japanese SEO spam, may be part of a deeper compromise involving files, database records, cached output, and external reputation damage.
Malcure’s WordPress malware removal service helps resolve layered infections like this by combining deep scan detection technology with expert manual cleanup. Our security analysts identify and remove SEO spam, malicious theme injections, database compromises, Google blocklist issues, and recurring malware symptoms.