Start with the problem you are seeing
Could this match the problem on your WordPress site?
This page is relevant when an unfamiliar StateMesh plugin is found on disk, does not appear normally in wp-admin, or seems to return after incomplete removal. The supplied code included both concealment filters and self-copy logic.
Observed in this investigation
- The supplied StateMesh code filtered plugin-list data and attempted to copy itself to another plugin location.
Possible warning signs
- The plugin can be absent from the normal Plugins screen while its files remain on disk.
- Deleting only one copy may not be sufficient if the alternate copy path has already been populated.
These signs are investigation leads, not proof of this artifact by themselves.
Questions this research can help answer
- Why is StateMesh missing from my WordPress Plugins screen?
- How can an unknown plugin return after I delete one copy?
Evidence boundary: The self-copy logic is visible in code; the retained evidence does not prove how many copies executed on the site.
Seeing one of these signs on your site?
I can investigate the files, database records, users, and server evidence, explain what is confirmed, and help plan a safe cleanup.
Research focus: Forensic analysis of 01-mu-StateMesh.php.php code that copied itself into mu-plugins and filtered plugin-management views.
Summary
This WordPress malware research entry documents self-copying concealed mu plugin evidence observed during one anonymized client investigation. The narrow topic is StateMesh MU-Plugin Self-Copy and Plugin-List Concealment: the page records the exact artifact, identifiers, and visible control flow instead of repeating a general malware-removal article.
The self-copy and concealment behaviors are consistent with persistence. The benign-looking StateMesh metadata appears to be camouflage in this supplied artifact.
Investigation context
Anonymized investigation with one filesystem screenshot and a retained, truncated StateMesh PHP sample. The report date is retained from the original investigation notes. Broader cleanup guidance remains in the WordPress malware removal guide; this entry is limited to what the supplied code and screenshots support.
Observed artifact
The StateMesh artifact existed in the MU-plugin path.

Confirmed findings
- The file is named 01-mu-StateMesh.php.php under mu-plugins.
- The all_plugins filter removes plugin_basename(FILE).
- show_advanced_plugins returns an empty array.
- The code builds a destination under WPMU_PLUGIN_DIR and writes file_get_contents(FILE) to it under coded conditions.
Technical analysis
How the 01-mu destination preserves an MU-plugin copy
The following code keeps the identifiers and control flow needed for defensive verification while removing secrets, complete payloads, and operational request instructions.
Redacted defensive excerpt
add_filter('all_plugins', function ($plugins) {
unset($plugins[plugin_basename(__FILE__)]);
return $plugins;
}, 9999);
$destination = WPMU_PLUGIN_DIR . '/01-mu-' . basename(__FILE__) . '.php';
// copy condition and remaining payload redacted
This excerpt is intentionally incomplete. It should be used for code search, baseline comparison, and incident review—not copied into a live site.
Analyst assessment
The self-copy and concealment behaviors are consistent with persistence. The benign-looking StateMesh metadata appears to be camouflage in this supplied artifact.
The severity reflects the capability visible in this artifact and its position in the investigated WordPress environment. It is not a claim about campaign prevalence, a particular vulnerability, or an outcome that the retained evidence does not show.
Indicators of compromise
Higher-confidence indicators
01-mu-StateMesh.php.phpStateMesh metadata combined with 01-mu self-copy logicall_plugins self-unset plus show_advanced_plugins suppression
Contextual indicators
WPMU_PLUGIN_DIRfile_put_contents()md5() comparisongoto obfuscation
Contextual indicators are not proof of infection by themselves. Confirm them through trusted-file comparison, neighboring code, database provenance, request logs, or the distinctive combinations listed above.
What this evidence does not establish
- The screenshot does not prove the self-copy branch executed.
- The full request-controlled behavior and database changes are not reproduced publicly.
- The initial compromise method and any relationship to a legitimate project were not established.
- No affected component version was confirmed.
Artifact-specific remediation
- Preserve the file and full MU-plugin directory listing.
- Remove all untrusted StateMesh copies and rebuild mu-plugins from a known baseline.
- Search for the 01-mu prefix, class names, options, and concealment filters.
- Review administrator accounts and related persistence locations.
For a complete response sequence, use the broader malware-removal guide or the WordPress malware-removal service when hands-on incident response is appropriate.
Recurrence verification
- Confirm no 01-mu-StateMesh copies return.
- Compare mu-plugins against a controlled inventory after normal requests.
- Monitor writes into WPMU_PLUGIN_DIR.
Related malware research
Browse the WordPress malware research hub.
- wp-user-query.php MU-Plugin Concealing a Stored User ID
- media-patcher-lab.php Found in WordPress mu-plugins
- system-control Plugin Restored from wp-content/.sc-backup
Related guides and case studies
- Hidden WordPress backdoor investigation
- Known fake and malicious WordPress plugins
- MU-plugin malware case study
Methodology and privacy note
This analysis is based on retained code, screenshots, paths, and notes from an anonymized WordPress client investigation. Confirmed findings are limited to visible or supplied evidence; professional interpretation is labeled as analyst assessment. Screenshots were reviewed for client identifiers, account paths, usernames, email addresses, credentials, tokens, database details, and unrelated records. Sensitive or operational material remains outside the public page, and every public code block is a redacted defensive excerpt.