Several theme-level vulnerabilities coupled with evolving abuse tactics are demonstrating once again how vulnerable WordPress becomes when multiple vulnerabilities are aligned. An unauthenticated file access and deletion vulnerability has been disclosed in the WPLMS theme-tracked as CVE-2024-10470 and assigned a CVSS score of 9.8-which has exposed thousands of learning management deployments. 

A significant risk exists as a result of the issue in more than 28,000 active installations, which enables attackers to read or remove sensitive files such as wp-config.php, thereby lowering the barrier to full site compromise, data exposure, and operational disruption. 

Not only does the vulnerability itself pose a serious threat, but its intersection with a broader wave of hostile activity that has already targeted WordPress ecosystems at a significant scale makes this threat particularly acute. This is in keeping with recent research by Sucuri that shows threat actors are utilizing malicious JavaScript injections to weaponize distributed brute-force campaigns against compromised sites. 

Instead of attacking targets directly, injected code quietly conscripts unsuspecting web browsers, creating a distributed attack platform based on normal web traffic. Earlier campaigns were focused on crypto drainers and Web3 phishing redirects, but the latest iteration, which has been observed on over 700 websites, uses leaked and commonly used credentials to systematically brute-force additional WordPress installations, representing a dramatic shift from these earlier campaigns. 

This development demonstrates how critical theme vulnerabilities and indirect attack mechanisms are being combined to amplify impact, accelerate lateral spread, and undermine trust in compromised WordPress environments by chaining together critical theme vulnerabilities and indirect attack mechanisms.

It was discovered that the attackers had manipulated the way pages were rendered to specific visitors, rather than altering visible site content. During search engine results, valid titles and descriptions were replaced with casino- and gambling-related text, suggesting that this was done deliberately to poison the indexing of search engines. 

Notably, the spam did not appear on highly trafficked areas, such as the homepage or blog posts. In place of static, low-maintenance pages, it appeared on static, low-maintenance pages like About Us, Contact Us, Privacy Policy, and Terms & Conditions—sections that are generally static and rarely examined. Consequently, the placement alone indicates a deliberate attempt to avoid detection while maximising SEO abuse. 

Verification of the affected pages through the WordPress administrative interface revealed no signs of compromise. They retained their expected permalinks and the content displayed within the editor was entirely valid. Based on a direct review of the underlying database, including the records in the wp_posts table, it was determined that no unauthorized modifications had occurred to the content storage system. 

In the present state, there is little to explain why search engines index spam, while human visitors only see benign content, since neither the page source nor the database indicate any anomalies. A turning point occurred when investigators altered the browser’s User-Agent string to emulate a crawler’s behavior.

Consequently, the same URLs exhibited entirely different content when viewed under these conditions. Instead of displaying standard corporate or legal information, pages previously showing standard corporate or legal information appeared full-screen casino spam, confirming that cloaking has been implemented. 

By using this conditional delivery mechanism, attackers were able to target search engine bots selectively and conceal the malicious payload from site administrators and regular users. A deeper technical review indicated that the compromise extends beyond simple content injection and that it involves a more advanced method for manipulating the permalinks and page rendering logic within WordPress itself without leaving conventional forensic traces. 

As a result of a deeper technical analysis, the root cause was determined to be an envato-setup-export.php component of the WPLMS theme which lacked critical security controls. In this code, the zip_file parameter is not validated or sanitized, which enables an attacker to reference any file located on the server arbitrarily.

Once a target file is selected, the application logic proceeds to read its contents using the readfile() function before deleting it using the unlink() function. By executing this unsafe sequence, unauthenticated attackers are effectively capable of removing critical configuration files, including WordPress' configuration file, user-generated content, and other important assets from the site, thereby significantly weakening the site's security posture. This vulnerability has a broader impact than deleting isolated files. 

Upon removing the WordPress config.php file, WordPress will be placed in an installation state, as it will be disconnected from the existing database. By exploiting the setup process, an attacker can link the site with a database under his/her control, allowing full administrative control of the website. 

A file-handling vulnerability that initially appears to be a vulnerability is transformed into a complete site compromise that can result in data exfiltration, persistent backdoors, and abuse of trust among users. As the theme is widely deployed across multiple sectors, the vulnerability is a high-value target for both opportunistic and coordinated attacks, thereby amplifying the threat. 

Initially disclosed by security researcher Foxyyyy through Wordfence's Bug Bounty Program, Foxyyyy received a $900 bounty. Following this publication, Wordfence has issued a recommendation for all WPLMS users to upgrade to version 4.963 or later, which contains a fix for the vulnerability known as CVE-2024-10470. Because the flaw is global in scope and severe, administrators are encouraged to prioritize patching. 

As part of enhancing baseline defenses, security teams should harden servers and applications, maintain offline backups, enforce strong authentication practices, such as unique passwords and multi-factor authentication, and make sure that operating systems, plugins, and security signatures are fully updated. 

When similar vulnerabilities arise in the future, these measures are critical to reducing exploitation risk and limiting the blast radius. The malicious functionality was found to be completely hidden within an index.php file placed in fabricated directories which reflected legitimate WordPress permalinks as a result of the subsequent investigation. 

A traffic gatekeeper file serves as a dynamic gatekeeper, determining whether to serve authentic-looking content or spam payloads based on the nature of incoming requests. As a result of conditional logic, routine visits by site owners and regular users did not raise any immediate suspicion, while search engine crawlers were selectively given content that was designed to be indexed. 

A bot-detection routine, which was embedded at the heart of this mechanism, was designed to efficiently identify search engine traffic with an extremely high level of precision. The attackers specifically targeted multiple Google-related User-Agent strings in order to effectively differentiate search engine crawlers from human traffic. 

By identifying these identifiers in a request, the malware bypasses the legitimate page altogether and loads a secondary file directly into the browser, readme.txt, rendering its contents directly in the browser. 

While this file appeared harmless, it contained a complete HTML document containing spam content specifically designed to influence the rankings of search engines. In order to conceal the compromise, the malicious script instead included indexx.php, an HTML static capture of the original page for non-bot traffic. This approach portrayed the site as entirely normal to administrators and users, effectively cloaking the compromise. 

In addition, the readme.txt payload further emphasized the sophisticated nature of the campaign by providing deceptive information. A file containing more than 600 lines of HTML, JavaScript, and stolen styling elements impersonated a high authority online retail site spanning more than 600 lines. 

In addition to reusing CSS, metadata, and structural elements related to Etsy, the attackers attempted to add credibility to the webpage by using underlying content that promoted Indonesian gambling schemes referred to as "Slot Gacor." The attackers also inserted extensive Schema Markup, using JSON-LD, to enhance visibility in search results. 

In addition to creating fabricated product listings, aggregate ratings, and pricing information, the attackers effectively manipulated how search engine snippets portrayed the pages. Consequently, what was in fact a cloaked spam page could appear in search results presenting itself as an attractive, highly rated product, leading to an increase in click-through rates and an extension of infection lifespan. 

Instead of treating symptoms individually, remediation efforts focused on fully removing the malicious infrastructure. As a result of identifying and deleting all unauthorized directories that replicated WordPress permalinks, as well as the associated malicious files, the site was then tested using multiple User-Agent configurations, ensuring that content delivery was consistent and no longer dependent on the User-Agent configuration. 

A complete review of file permissions, resetting of all administrative, hosting, FTP, and database credentials was performed in parallel with the site owner's advice to request a fresh index from search engines upon completion of the cleanup. 

In addition, security specialists recommended that an extensive post-incident hardening process be implemented, including the removal of unknown user accounts, checking core WordPress files such as index.php and .htaccess, and regularly monitoring server logs for suspicious outbound connections. 

As part of the recommendations, additional safeguards were emphasized, including maintaining offline backups, updating all components, scanning administrator devices for malware, and deploying a Web Application Firewall to prevent cloaking-based campaigns from taking hold in the future, and reducing the likelihood of reinfection. 

According to the findings of subsequent investigation, the malicious functionality was completely contained within an index.php file located in fabricated directories that mimicked legitimate WordPress permalinks. By dynamically analyzing the nature of the incoming request, this file determined whether to serve authentic-looking page content or spam payload. 

Using conditional logic, routine visits by site owners and regular users did not raise suspicion, while search engine crawlers were given manipulated content intended for indexing selectively. As a key component of this methodology, a bot-detection routine was developed which was capable of identifying search engine traffic with high precision. 

As a result of the attackers' explicit targeting of multiple Google-related User-Agent strings, they have been able to identify crawlers from human users reliably. In response to a request matching these identifiers, the malware bypassed the legitimate site entirely and loaded a secondary file, readme.txt, which was displayed directly in the browser. 

However, the file contained an entire HTML document with spam content designed to influence search engine rankings despite its seemingly innocent name. In order to conceal the compromise, the malicious script instead included indexx.php, an HTML static capture of the original page for non-bot traffic. This approach portrayed the site as entirely normal to administrators and users, effectively cloaking the compromise.

In addition, the readme.txt payload further emphasized the sophisticated nature of the campaign by providing deceptive information. A file containing more than 600 lines of HTML, JavaScript, and stolen styling elements impersonated a high authority online retail site spanning more than 600 lines. 

In addition to reusing CSS, metadata, and structural elements related to Etsy, the attackers attempted to add credibility to the webpage by using underlying content that promoted Indonesian gambling schemes referred to as "Slot Gacor." The attackers also inserted extensive Schema Markup, using JSON-LD, to enhance visibility in search results. 

In addition to creating fabricated product listings, aggregate ratings, and pricing information, the attackers effectively manipulated how search engine snippets portrayed the pages. Due to this, what was in fact a cloaked spam page appeared in search results as a product that was perceived as legitimate and highly rated, resulting in increased click-throughs and prolonged infection.

In contrast to treating symptoms in isolation, remediation efforts focused on eliminating the malicious infrastructure completely. A comprehensive investigation of all unauthorized directories replicating WordPress permalinks was conducted, together with the associated malicious files, and all unauthorized directories were deleted. 

Following the verification of consistent content delivery, multiple User-Agent configurations were used to verify that any conditionality was eliminated. In parallel, file permissions were reviewed, all administrative, hosting, FTP, and database credentials were reset, and the website owner was instructed to request that search engines refresh their index once the cleanup had been completed.

Additionally, security specialists recommend that all WordPress user accounts be removed, core WordPress files such as index.php and .htaccess be verified, and server logs for suspicious outbound connections be monitored regularly. 

It is important to maintain offline backups, keep all components updated, scan administrator devices for malware, and deploy a Web Application Firewall as additional safeguards so that reinfection will be reduced and similar cloaking-based campaigns will not occur again. 

Overall, the investigation indicates how a number of weaknesses were purposefully chained together to create a highly resilient and covert compromise. This attack did not utilize overt defacement or obvious content injection, but rather exploited a critical WordPress theme vulnerability combined with cloaking techniques to manipulate WordPress' rendering of content in accordance with the visitor's identity. 

Using CVE-2024-10470 in the WPLMS theme, they were able to remove or access sensitive files, weakening the security of the site and creating conditions for deeper manipulation of data without altering it. Several recent Sucuri findings confirm the shift towards indirect abuse mechanisms in WordPress-focused attacks, which correspond with the broader campaign. 

A malicious JavaScript injection was used by threat actors to manipulate unsuspecting visitors' browsers, effectively converting legitimate traffic into a distributed attack network via JavaScript injections. The most recent phase of this activity was observed across over 700 compromised sites.

It utilised leaked and commonly used credentials to brute-force additional WordPress installations, despite earlier iterations focusing on crypto drainers and Web3 phishing redirections. This evolution shows a deliberate movement toward techniques that are scalable and low-noise, thus maximizing reach and minimizing immediate detection.

An extremely sophisticated cloaking component was implemented in the attack Malicious logic was incorporated into index.php files located in fabricated directories that were intended to mirror legitimate WordPress permalinks, providing access to legitimate permalinks as well as identifying search engine crawlers using multiple Google-specific User-Agent strings to serve as traffic gatekeepers. 

Upon identifying crawler traffic, an additional payload was served from a file deceptively titled readme.txt which contained a fully formatted HTML document that was optimized for search engine indexing. However, human visitors and site administrators received indexx.php, a static HTML snapshot of the legitimate page, thereby ensuring that the site appeared normal during routine inspections. 

Over 600 lines of code were incorporated into the spam payload in an effort to fool automated systems. Combining HTML, JavaScript, and stolen design elements created the illusion of an e-commerce platform with high authority. 

A number of technical components associated with Etsy, including CSS, metadata, and structural components, were reused by the attackers, together with extensive JSON-LD schema markup that contained fabricated product data, ratings, and pricing. As a result, the attackers manipulated how search engines interpreted and displayed the pages. 

The result was the presentation of cloaked gambling content-promoting Indonesian "Slot Gacor" schemes-as seemingly legitimate, highly rated listings in search results, increasing click-through rates and extending the lifespan of the infection. 

Rather than addressing individual symptoms, remediation efforts focused on dismantling the attack infrastructure as a whole. A thorough examination was conducted to identify and remove all unauthorized directories that replicated WordPress permalinks along with the malicious files associated with them.

Tests were conducted using a variety of user agents to confirm the removal of conditional content delivery. Additionally, site owners were advised to request re-indexing by search engines following cleanup by reviewing file permissions, resetting all administrative, hosting, FTP, and database credentials, as well as re-adjusting all administrative credentials.

The security specialists reiterated that post-incident hardening is extremely important in order to prevent recurrences. It was recommended that unknown user accounts be audited and removed, core WordPress files such as index.php and .htaccess be verified for integrity, server logs for suspicious outbound connections be monitored, offline backups be maintained, all components are kept up to date, malware is scanned on administrator systems, and a web application firewall be implemented. 

Collectively, these steps play a critical role in reducing the risk of reinfection and defending against future cloaking-related campaigns that increasingly blur the boundaries between content abuse, SEO manipulation, and the compromise of the entire site.