WP SiteGround Control malware can add spam links, replace pages and redirect visitors. A second copy runs as a must-use (MU) plugin, which WordPress loads automatically even when ordinary plugins are deactivated.
The malicious plugin uses a familiar hosting-related name to conceal a backdoor, a way for its operator to act outside the normal WordPress login process. The remote content features support SEO spam, unwanted links or pages intended to exploit a site’s visibility in search results. A normal-looking homepage does not rule them out.
Start by asking the host to check the two file locations below, or inspect them read-only through an existing hosting file manager or SFTP connection. A matching filename needs investigation, not automatic deletion. If the code is unfamiliar or a removed file returns, involve hosting support or a WordPress security specialist and follow the recovery checklist.
What hides behind the familiar plugin name
The 39,805-byte PHP sample identifies itself as WP SiteGround Control, version 1.6.2. Its header describes a component that fetches plugin updates. The implementation instead contains persistence, concealment, remote content delivery and a page-publishing backdoor. The same malicious code can run from both locations below.
A plugin header is text supplied by its author. A hosting-related name, author label or update URL does not establish where the code came from. Compare unfamiliar components with the provider’s documented products and obtain replacements through trusted channels. SiteGround’s official WordPress plugin catalogue is the appropriate reference for its products. The malicious component described here should not be confused with those official plugins.
| Location | Role in this sample |
|---|---|
| wp-content/plugins/wp-siteground-control/wp-siteground-control.php | Regular plugin copy. Its top-level synchronization routine writes the MU copy when this file runs. |
| wp-content/mu-plugins/wp-siteground-control.php | Automatically loaded copy. It keeps running independently of the regular plugin’s activation state. |
These paths are useful indicators for this sample, not a list of every filename that similar malware can use. Legitimate hosting integrations and custom MU-plugins also exist. Their contents and origin determine whether they belong.
Why the MU-plugin copy survives ordinary deactivation
Must-use plugins are a legitimate WordPress feature. PHP files directly inside the configured MU directory load automatically, before regular plugins. They appear in a separate Must-Use section and cannot be deactivated with the usual plugin controls. The WordPress MU-plugin documentation explains this loading behavior.
The regular plugin can recreate the must-use copy whenever it runs. Its lf_sync_mu_plugin_copy() function creates the MU directory if necessary and copies the current file into it. When called from the MU copy, it checks readable regular-plugin sources and refreshes the MU file if the sizes or MD5 hashes differ, or if the regular source has a newer modification time.
The direction matters. This sample does not contain a reverse routine that recreates the regular plugin from the MU file. Removing only the MU copy can allow the running regular copy to recreate it. Removing only the regular copy leaves the already installed MU copy available to WordPress. Cleanup must account for both locations.
The malware also filters the regular plugin inventory, injects CSS to hide matching rows and adjusts the displayed MU-plugin count. A request-controlled reveal condition exists in the source. That makes an independent filesystem inventory more reliable than a visual check of plugin names. The wider pattern is covered in CleanTalk’s analysis of malicious MU-plugins, although other examples in that article have different payloads.
How the remote SEO-spam delivery works
The plugin asks a remote server what to show visitors. The hardcoded address is boston-hub[.]com/get.php, printed with brackets to avoid creating a normal link. The file builds requests containing the site host, requested URL path, visitor IP address, referring page, browser identification string, preferred language, whether the request uses HTTP or HTTPS, and a crawler classification. An activation handler can also send a registration-style ping.
Crawler classification combines user-agent checks, broad IP patterns and reverse DNS lookups. The Google branch checks a reverse hostname suffix but does not perform a corresponding forward-DNS confirmation. These are targeting heuristics in the malware, not proof that a request really came from a search engine.
| Remote response element | Result implemented in the PHP |
|---|---|
<link> | Collects markup for insertion through content and footer hooks. By default, its wrapper positions the links thousands of pixels to the left of the visible page. |
<page> | Can replace the normal page response with content supplied by the remote server. |
<url> | Redirects through WordPress when headers remain available, with a JavaScript redirect as a fallback. |
A special marker can request visible links instead of the off-screen wrapper. The remote operator can therefore vary the response without rewriting the plugin. The network functions try the WordPress HTTP API, cURL and URL-enabled PHP streams in sequence. The endpoint uses HTTP, and the fallback options also disable certificate verification for HTTPS requests.
Remote page and link markup is inserted without the permitted-HTML filter used by the publishing handler below. These branches give the remote response control over HTML delivered to visitors.
This code path handles remote content and redirects. It does not need an eval() call or a heavily encoded payload to be malicious. Visitor request metadata also gives the remote server information it can use to choose a response.
Why a normal-looking visit can miss it
Different visitors can receive different results, and some checks skip full page replacement. The early replacement path skips logged-in users, checks for administrative, AJAX, cron and REST contexts, and excludes several non-content URL patterns. A cookie named http2_session_id disables most of the frontend setup when present. However, later content-insertion hooks can also fetch remote data, so the logged-in check is not a universal bypass for every branch.
For eligible anonymous frontend requests, the code sets several cache-bypass flags and no-cache headers. Its activation handler also calls available cache-purge integrations. These calls try to keep the response dynamic. Their effect depends on the cache configuration.
The outcome can differ by request context and by the remote response. A clean-looking screenshot, an empty list of spam pages or a single successful homepage scan is therefore incomplete evidence. Google describes this general use of cloaking and hacked content in its spam policies. Changing a user-agent string alone may also fail to reproduce behavior that depends on IP or DNS checks.
How it can publish pages without a WordPress login
The handle_remote_post() method is registered on WordPress init. It accepts a title and content after comparing a submitted value with a hardcoded secret. The field name resembles a nonce, a WordPress request-security token, but the handler does not validate a WordPress nonce, a logged-in user or permission to publish.
The title is sanitized and the content passes through WordPress’s permitted-HTML filter. Those operations limit some content. They do not authorize the sender to publish. An accepted request creates a published page, prefixes a marker comment and writes matching _sys_marker metadata. This handler is registered before the constructor’s cookie-based early return.
The sample’s configuration affects which hiding routines run. The page-list filtering and page-count adjustment methods return immediately when the marker equals cache:bb4ca49b39, which is this file’s configured value. Those two page-hiding routines are inactive with this marker, even though the page publisher remains registered. Plugin-list hiding is separate and remains implemented.
How can a fake plugin get installed?
The malicious file must first reach a location that WordPress can load. Possible routes to investigate include compromised administrator accounts or sessions, exposed hosting or file-transfer access, and vulnerable code that permits file writes. A familiar filename or plugin header does not identify the entry route.
Compare plugin installation events, account activity and hosting access records with unexpected file changes. Check who can install plugins and which accounts or integrations can write site files. Removing the malicious PHP should be paired with closing the access that allowed it to be installed.
Indicators to check without overdiagnosing the database
Use the following values to search retained evidence and current files. The brackets in [.] keep the remote address from becoming a normal link. For a fixed-text search of saved files, replace [.] with a dot. Keep the bracketed form in public notes. A match in active PHP is different from a match in a scanner signature, an old audit URL or a quarantine record.
| Indicator | What it identifies |
|---|---|
WP SiteGround Control and WP_SiteGround_Control | The displayed name and PHP class used by the recovered sample. |
wp-siteground-control.php | The basename shared by the two malicious copies. |
boston-hub[.]com/get.php | The hardcoded remote content endpoint. |
cache:bb4ca49b39 | The configured page marker, useful for content and metadata searches. |
_sys_marker | A metadata key used by the publisher. The key alone is not a malware verdict. |
http2_session_id | A cookie name used to suppress much of the frontend setup. Its name alone does not prove infection. |
SHA-256 is a file fingerprint. The sample described here has the value 2c76a9fecb2d29a3e74f102708ee682ae7ec429575c5d470b8a490da7e69a674. A changed variant may have a different fingerprint.
Remote content injection does not require spam pages to be stored in the database. An empty page search does not clear a plugin that can replace responses dynamically. Conversely, an old scanner record containing a removed component’s name does not establish that the executable file has returned.
SPECIALIST-DRIVEN CLEANUP
Need help with this infection?
WP SiteGround Control, suspicious MU-plugin files or recurring redirects? CleanTalk’s specialists provide paid malware removal for WordPress to investigate the infection, remove malicious code and check for remaining persistence.
How to remove it and check for reinfection
- Preserve evidence and recovery access. Save suspicious files, their fingerprints, relevant logs and a database backup somewhere visitors cannot download them. Confirm that the site can be restored from the hosting account if the WordPress dashboard stops working.
- Contain the site before cleanup. Have the host or responder restrict access through trusted hosting or web-server controls and pause jobs that load WordPress during removal. A static maintenance response can keep visitors away from the affected application. A WordPress maintenance plugin alone still loads MU-plugins. Revoke known compromised accounts or sessions promptly from a clean device.
- Check files beyond the Plugins screen. Have the regular and MU plugin folders, themes, startup files and other locations that can run PHP inspected, including uploads, caches and backups. Compare official files with clean copies of the same releases. Identify legitimate custom code before removing anything.
- Remove every confirmed malicious copy. With WordPress execution paused, quarantine both known copies somewhere visitors cannot access them, so the regular plugin cannot repopulate the MU location during cleanup. Preserve legitimate hosting integrations and custom MU-plugins. List the files in both directories again to confirm removal.
- Review live database content and control points. Have a responder check posts and pages across statuses, revisions, metadata, stored PHP snippets, administrators and permissions, active plugin references, redirects and scheduled tasks. If recurrence remains unexplained, include database objects such as database triggers that survive file replacement.
- Complete access recovery. From a clean device, replace potentially exposed WordPress, hosting and file-transfer credentials after removing persistence, and invalidate remaining WordPress sessions. Known compromised access should already have been revoked during containment. Repeat credential changes if they were made while malicious code could still execute. Changing passwords and rotating WordPress authentication keys and salts address different parts of recovery.
- Verify the result over time. After removal, purge affected caches and restore normal service through the usual hosting process. Repeat file and database checks and investigate new or returning files. Check several public pages while signed out, including inner pages. This adds a visitor view to the evidence rather than replacing the technical checks.
Where Security by CleanTalk helps
Security by CleanTalk provides file scanning, change monitoring and login protection. Open Settings → Security by CleanTalk → Malware Scanner and review the scan results. Use the Malware Scanner guide for the current interface and file analysis workflow when a finding needs further review.
Review scanner exclusions and coverage before interpreting a clean result. A legitimate vendor file may contain suspicious-looking functions, while a whole malicious component may imitate an ordinary plugin. Quarantine or removal decisions should follow the file’s behavior and provenance, with a recoverable copy available.
File System Watcher comparisons help identify added, changed and removed PHP files between recorded states. Investigate new files in the MU directory and relate them to known maintenance. For public responses, checking inner pages as well as the homepage adds useful coverage. Neither frontend crawling nor a file scan alone replaces the database and access review.
Reduce the routes back in
Enable two-factor authentication for administrative roles, use unique passwords and protect the email and hosting accounts that can reset or bypass WordPress access. Review who can install plugins, remove unnecessary privileged accounts and investigate unexpected upload or login events.
Keep WordPress, themes and plugins updated from verified sources, including licensed commercial packages. Restrict unnecessary write access and monitor unexpected file changes. The WordPress hardening guide covers these controls. An overdue update merits attention, but it does not by itself identify the cause of an incident.
Two configuration settings are often confused. DISALLOW_FILE_EDIT disables the built-in file editors but does not block plugin uploads. DISALLOW_FILE_MODS also disables dashboard installation and updates, so it belongs in a deployment process that still delivers security updates. Consult the official configuration documentation before adopting that restriction. Neither setting removes PHP that is already installed.
If search results or browser warnings were affected, check Google Search Console after cleaning the full site. Its Security Issues report provides findings and a review process when an issue is listed. Removing a backdoor and recovering search visibility are separate steps.
Frequently asked questions
Is WP SiteGround Control a legitimate SiteGround plugin?
The sample described here is malicious software using that name. Its update description does not match its behavior. Verify provider products through official sources and inspect unexpected code. A hosting-related label does not establish authorship.
Will deactivating all ordinary plugins stop it?
Not if the malicious MU copy remains. WordPress loads that file independently. Both copies need to be checked, and the regular copy can recreate the MU file when it runs.
When should a site owner ask for help?
Ask the host or a WordPress security specialist if a file returns after removal, unexpected administrator activity appears, or the code and database findings are difficult to assess. Share the suspicious paths, scanner results and the earliest relevant timestamps.
Can this malware survive a password change?
Yes. Changing a password does not remove PHP already installed in a plugin directory. Remove the malicious copies, review how they arrived and revoke exposed access and existing sessions as part of recovery.
Do matching words in the database mean active malware?
Not necessarily. Published content, privileged options and executable snippets require a different assessment from scanner definitions, audit history and quarantine records. Read the complete value and its role before changing it.
The practical lesson
This infection combines ordinary WordPress features in a malicious component. A regular plugin writes an automatically loaded copy, hides its inventory entries and obtains content instructions from a remote host. Effective recovery removes the executable copies, checks their previous effects and closes the exposed access. The visible homepage is only one part of that check.
