Niraj Pal

<p>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.</p>
<h4>What makes Malroot different</h4>
<p>Most security plugins only scan files on disk. Malroot also looks at:</p>
<ul>
<li><strong>Database content</strong> — <code>wp_options</code>, <code>wp_posts</code>, <code>wp_postmeta</code> for injected PHP/JS payloads</li>
<li><strong>MySQL triggers and events</strong> — catches rootkits that recreate fake admins on every spam comment</li>
<li><strong>REST API routes</strong> — flags non-standard namespaces with dangerous capabilities</li>
<li><strong>mu-plugins</strong> — detects self-healing loaders that reinstall malware after deletion</li>
<li><strong>Bot-cloaked content</strong> — compares Googlebot vs human page output to detect SEO spam</li>
<li><strong>Outbound connections</strong> — logs every external HTTP request and alerts on known C2 hosts</li>
</ul>
<h4>Core features</h4>
<ul>
<li>Eight independent scanner modules with severity-based findings</li>
<li>One-click incident response that replays a complete malware cleanup</li>
<li>Auto-quarantine with full restore for files, options, postmeta, users, triggers, events</li>
<li>Real-time hooks block rogue admin creation and eval-based option injection</li>
<li>WordPress.org checksum verification — official files auto-accept silently</li>
<li>Login security with IP throttling, automated-tool detection, geo-aware new-origin alerts</li>
<li>Built-in 2FA (TOTP, RFC 6238 — works with Google Authenticator, Authy, 1Password)</li>
<li>Spam registration shield with honeypot, pattern blocklist, and bulk subscriber cleanup</li>
<li>Email and Slack alerting with deduplication</li>
<li>CSV export of findings for audit trails</li>
<li>Self-integrity check — Malroot detects tampering with its own code</li>
</ul>
<h4>Plain-language Simple View</h4>
<p>Findings are translated from technical rule IDs into plain English with clear actions:</p>
<ul>
<li>“Hidden trap found in your database” instead of “TR-005: Trigger after_insert_comment”</li>
<li>“Fake admin account found” instead of “UA-010: Known malware admin name”</li>
<li>“Hacker tool found on your site” instead of “MAL-005: WSO/FilesMan webshell signature”</li>
</ul>
<p>Each finding card answers three questions: what happened, why it matters, what to do.</p>
<h4>How verified-safe checking works</h4>
<p>When a file changes, Malroot looks up its MD5 hash in:</p>
<ol>
<li>The official WordPress.org core checksums API</li>
<li>The official plugin checksums at downloads.wordpress.org</li>
<li>A recent plugin/theme update window from the operator’s own update history</li>
</ol>
<p>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.</p>
<h4>Real-world validation</h4>
<p>Malroot was developed during the cleanup of compromised WordPress sites, including sites where the rogue plugin had embedded a MySQL trigger that recreated a <code>newsfeed</code> admin user every time a spam comment was posted. That attack pattern is now a built-in detection.</p>
<h3>External services</h3>
<p>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.</p>
<p><strong>WordPress.org core checksums API</strong> (<code>api.wordpress.org</code>)<br />
Used to verify whether changed core files match official WordPress release checksums. The plugin sends only the WordPress version string and locale (e.g. <code>6.5.4</code> / <code>en_US</code>) 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.<br />
Provider: WordPress Foundation. Privacy policy: https://wordpress.org/about/privacy/. Terms: https://wordpress.org/about/</p>
<p><strong>WordPress.org plugin checksums</strong> (<code>downloads.wordpress.org</code>)<br />
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.<br />
Provider: WordPress Foundation. Privacy policy: https://wordpress.org/about/privacy/. Terms: https://wordpress.org/about/</p>
<p><strong>ipapi.co GeoIP lookup</strong> (<code>ipapi.co</code>) — optional, OFF by default<br />
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.<br />
Provider: ipapi. Privacy policy: https://ipapi.co/privacy/. Terms: https://ipapi.co/terms/</p>
<p><strong>Slack incoming webhook</strong> (URL configured by the site administrator, optional)<br />
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.<br />
Provider: Slack. Privacy policy: https://slack.com/trust/privacy/privacy-policy. Terms: https://slack.com/terms-of-service</p>


Malroot Security

Catches database-resident backdoors, rogue admins, malicious MySQL triggers and self-healing rootkits other scanners miss.

Code Machine

<h4>Purpose</h4>
<p>Detect WordPress Plugins ‘Fatal Errors’ that might block/prevent site admins from accessing WordPress admin interface in order to deactivate the Plugin that caused the issue! UBP then report/notify (sedning email) site admin with a secure link that valid for 24 hours from which site admin can deactivate the target Plugin by simply clicking the link!</p>
<p>For development state and issue tracking follow the Plugin on <a href="https://github.com/xpointer/ubp" rel="nofollow ugc">GitHub Respository</a></p>
<h4>Mechanism</h4>
<p>The mechanism of the Plugin is to always put itself as the first Plugin to be executed by WordPress Plugins system! The Plugin then just stay away and never get itself involved until the execution of all the other scripts is then terminated! UBP Plugin role is comes when the script is terminated. It then check if the script is terminated with error. If the script if terminated with error UBP send admin mail with backup link that has a secure key by which UBP give the link owner the permission to disable the target Plugin.</p>
<h4>Advantages</h4>
<ul>
<li>There is no need to access throught FTP to force WordPress deactivate the Plugin. You can always use this Plugin to deactivate the target Plugin only with the link sent with the mail.</li>
<li>Load minimum codes/scripts that required only to get involved (listen to errors). Load code required to functional only when error detcted.</li>
</ul>
<h4>Notes</h4>
<ul>
<li>Whenever you active or deactive a Plugin, UBP will always put itself as the first Plugin in WordPress active Plugins queue.</li>
<li>The Plugin won’t install itself while the site is already blocked by the error.</li>
<li>UBP must be installed first while the site is fully functional and then it’ll help you backing up your site if any newly Plugin produced an error.</li>
<li>It Won’t help you on all type of errors you’ve in your WordPress site however it can always give you the chance to get your site functional again after installing any Plugin that prevent you from accessing your backend.</li>
<li>It has no admin user interface and therefor not configurable, however next versions will do.</li>
<li>Send admin mail whatever ‘fatal errors’ is detected and it doesn’t matter if this error blocked your site or not. It’ll also report fatal errors that might happened in a secondary request that doesn’t block you from deacivating the Plugin yourself.</li>
</ul>
<h4>Proof Of Concept</h4>
<p>I still have many useful ideas and feature to add to the Plugin however the Plugin need users reviews to proof that its really helping and its really need to be improved.</p>


Uninterrupted Backup

Detect fatal errors that might be produced by the installed active Plugins, provide secure backdoor for deactivating the target Plugin.

Malroot Security vs Uninterrupted Backup