Roughly half of modern WordPress malware persists in the database rather than on disk. File scanners never see it. Guardian Gaze's database scanner reads wp_options,wp_posts, wp_postmeta and other tables directly, looking for encoded payloads, injected scripts, hidden admin users and persistence mechanisms that re-infect a site after a "clean".
Database-resident malware is the category most file-only scanners blind themselves to. A payload stored in a wp_options row is loaded by WordPress on every request, executes, and leaves no file-system trace. The most common pattern we see: site is "cleaned" by deleting infected files, then re-infects itself a day later because the loader is still living in wp_options.
Guardian Gaze treats the database as a first-class scan target. We read it directly, decode every serialised blob, normalise the content, and run the same four detection layers (signature, heuristic, cross-reference, LLM) as we do on files.
The site-settings table. Common infection sites: injected scripts loaded by wp_head, malicious redirect URLs, stage-two loaders, backdoor configurations, fake plugin auto-loaders. We read both serialised and plain values.
Posts, pages and any custom post type. Common infections: SEO spam pages, injected iframes, hidden links inside legitimate posts, redirect URLs in post_content, attacker-controlled custom post types.
Per-post metadata, often serialised. Attackers hide payloads here knowing most scanners don't unwrap PHP-serialised data. We deserialise every row before analysis.
The user table. We surface accounts created after a known scan baseline, especially with Administrator role, and flag suspicious user-meta entries that look like persistence hooks.
A file scanner that flags "suspicious .php in uploads/" is useful. A file scanner plus database scanner that says "this file is loaded by wp_options row _active_backup_pluginvia auto-loader hook" is significantly more actionable. Guardian Gaze cross-references findings between layers so a single threat surfaces as one coherent issue rather than two unconnected ones.
The most common cleanup failure pattern: site owner finds and deletes an infected file, but the wp_options row that loads it is still there. As soon as WP loads, the row's content runs, tries to load the deleted file, fails, and on many sites, also re-downloads or re-creates the file from a second source. Cleanup that only touches files almost always misses persistence. Cross-referenced cleanup gets both.
The database scanner connects directly to MySQL using your existing WordPress database credentials. It only reads, no writes, no schema changes, no triggers. Findings are sent to our API for analysis and stored in Guardian Gaze's own dashboard, not in your database.
Large tables are paginated and processed in chunks so the scan never holds long-running locks. On a typical site, the database scan adds 30 to 60 seconds to a deep scan. On a heavily-loaded WooCommerce site with millions of orders, we run the database scanner in the lowest-traffic hour by default.
| Capability | Free | Pro | Agency |
|---|---|---|---|
| wp_options scan | ✗ | ✓ | ✓ |
| wp_posts & wp_postmeta scan | ✗ | ✓ | ✓ |
| wp_users / hidden admin detection | ✗ | ✓ | ✓ |
| Serialised payload deserialisation | ✗ | ✓ | ✓ |
| Cross-reference with file findings | ✗ | ✓ | ✓ |
| LLM analysis of suspicious rows | ✗ | ✓ | ✓ |
| Custom-table scanning (custom post types) | ✗ | ✓ | ✓ |
| Scheduled database scans | ✗ | Hourly | Hourly |
Upgrade to Pro to add database scanning to your existing Guardian Gaze install. No schema changes, no downtime, results in under 10 minutes.