Malroot Security

Malroot Security is a WordPress malware scanner built specifically to catch the threats that file-based scanners miss. It was created after a real-world investigation of compromised WordPress sites where Wordfence and similar tools failed to detect database-resident malware, rogue REST API endpoints, malicious MySQL triggers, and self-healing rootkit patterns.

What makes Malroot different

Most security plugins only scan files on disk. Malroot also looks at:

• Database content — wp_options, wp_posts, wp_postmeta for injected PHP/JS payloads
• MySQL triggers and events — catches rootkits that recreate fake admins on every spam comment
• REST API routes — flags non-standard namespaces with dangerous capabilities
• mu-plugins — detects self-healing loaders that reinstall malware after deletion
• Bot-cloaked content — compares Googlebot vs human page output to detect SEO spam
• Outbound connections — logs every external HTTP request and alerts on known C2 hosts

Core features

• Eight independent scanner modules with severity-based findings
• One-click incident response that replays a complete malware cleanup
• Auto-quarantine with full restore for files, options, postmeta, users, triggers, events
• Real-time hooks block rogue admin creation and eval-based option injection
• WordPress.org checksum verification — official files auto-accept silently
• Login security with IP throttling, automated-tool detection, geo-aware new-origin alerts
• Built-in 2FA (TOTP, RFC 6238 — works with Google Authenticator, Authy, 1Password)
• Spam registration shield with honeypot, pattern blocklist, and bulk subscriber cleanup
• Email and Slack alerting with deduplication
• CSV export of findings for audit trails
• Self-integrity check — Malroot detects tampering with its own code

Plain-language Simple View

Findings are translated from technical rule IDs into plain English with clear actions:

• “Hidden trap found in your database” instead of “TR-005: Trigger after_insert_comment”
• “Fake admin account found” instead of “UA-010: Known malware admin name”
• “Hacker tool found on your site” instead of “MAL-005: WSO/FilesMan webshell signature”

Each finding card answers three questions: what happened, why it matters, what to do.

How verified-safe checking works

When a file changes, Malroot looks up its MD5 hash in:

1. The official WordPress.org core checksums API
2. The official plugin checksums at downloads.wordpress.org
3. A recent plugin/theme update window from the operator’s own update history

Files that match an official checksum auto-accept silently — the user never sees them. Files that match a malware signature get flagged as critical regardless of any update window. Custom files and theme edits surface for manual review.

Real-world validation

Malroot was developed during the cleanup of compromised WordPress sites, including sites where the rogue plugin had embedded a MySQL trigger that recreated a newsfeed admin user every time a spam comment was posted. That attack pattern is now a built-in detection.

External services

This plugin connects to the external services listed below. By default only the WordPress.org checksum APIs are used; the rest are opt-in. Each is documented with what is sent, when, and why.

WordPress.org core checksums API (api.wordpress.org) Used to verify whether changed core files match official WordPress release checksums. The plugin sends only the WordPress version string and locale (e.g. 6.5.4 / en_US) to fetch the public checksum manifest. No site content is sent. This is the same API WordPress core uses for its built-in checksum tool. Provider: WordPress Foundation. Privacy policy: https://wordpress.org/about/privacy/. Terms: https://wordpress.org/about/

WordPress.org plugin checksums (downloads.wordpress.org) Used to verify whether changed plugin files match the checksums of the version installed from the WordPress.org plugin directory. The plugin sends the plugin slug and version to fetch the public checksum manifest. No site content is sent. Provider: WordPress Foundation. Privacy policy: https://wordpress.org/about/privacy/. Terms: https://wordpress.org/about/

ipapi.co GeoIP lookup (ipapi.co) — optional, OFF by default Disabled unless the administrator turns on “IP geolocation” on the Settings page. When enabled, it displays a human-readable country and city for IP addresses recorded on the Login Activity page. The plugin sends only the IP address being looked up, and only when an administrator opens the Login Activity page — never during normal site traffic. Results are cached locally for 30 days so each unique IP is queried at most once per month. If the option is left off (the default), no IP address is ever sent and login records simply show the raw IP. Provider: ipapi. Privacy policy: https://ipapi.co/privacy/. Terms: https://ipapi.co/terms/

Slack incoming webhook (URL configured by the site administrator, optional) If the site administrator enters a Slack incoming webhook URL on the Settings page, critical and high-severity alerts are POSTed to that URL as a short notification payload (event type, severity, summary, and site host). No site content, credentials, or scan results are sent. This service is opt-in and only active when a webhook URL has been configured. Provider: Slack. Privacy policy: https://slack.com/trust/privacy/privacy-policy. Terms: https://slack.com/terms-of-service