Database scanning, for the malware that doesn’t live in files.

A site gets cleaned. Every infected PHP file is found, removed and replaced from a known-good copy. The scanner reports clean. Three days later the redirects come back, and nobody can explain how, because the files that were removed are still gone.

The explanation is almost always the same: the payload was never only in a file. WordPress stores an enormous amount of executable intent in its database, options that are loaded on every request, post content that is rendered into every page, metadata that is unserialised and acted upon, comment fields that are echoed into HTML. A backdoor that writes itself back into the filesystem on the next page load does not need to survive the cleanup. It only needs one row to survive it.

This is why database scanning is in the free plugin rather than behind a licence. A scanner that reads only the filesystem gives you a confident answer to half the question, and a confident half-answer during an incident is worse than an uncertain whole one.

wp_options is the highest-value target on a WordPress site, because autoloaded options are read into memory on every single request. A malicious option does not need anyone to visit a particular page; it executes constantly. Typical contents: injected scripts loaded through wp_head, redirect destinations, stage-two loaders that fetch the actual payload from elsewhere, and fake transients that reinstate a backdoor after deletion.

wp_posts holds posts, pages and every custom post type. Injected SEO spam lives here, as do hidden iframes, redirect scripts in post_content, and attacker-created custom post types that never appear in the admin menu, invisible in the interface, perfectly visible to a search engine crawler, which is how most owners find out.

wp_postmeta is where PHP-serialised data lives, and it is chosen deliberately because most scanners read serialised values as opaque strings. Guardian Gaze deserialises every row before analysis, so a payload nested inside an array inside a serialised blob is examined rather than skipped.

wp_comments is the table people forget entirely. Comment content and author fields are user-controlled input that gets rendered into HTML, which makes them a natural home for injected links and script fragments, particularly on sites where comments are unmoderated or a legacy comment table was never cleaned out.

Hidden iframes: an iframe sized to a pixel, or positioned off-screen, loading a third-party URL. The visitor sees nothing. Their browser loads whatever the attacker is serving that week.

Base64-encoded payloads: encoding is not itself malicious and plenty of legitimate plugins encode data. What is suspicious is encoded content that is subsequently executed, or an encoded blob sitting in a settings row that has no reason to hold one.

Spam links: injected anchors pointing at pharmaceutical, gambling or counterfeit-goods domains, usually hidden with CSS so that only crawlers see them. This is the payload class that costs you search rankings before it costs you anything else.

JavaScript redirects: conditional redirects that fire for mobile visitors, or for visitors arriving from a search engine, and stay silent for anyone typing the address directly, which is precisely why the site owner cannot reproduce what their customers are reporting.

eval() and backdoor-style code: the construct that takes attacker-supplied input and executes it. Stored in a database row, it is a persistent remote shell that does not appear in any file listing.

Every finding carries a severity rating, so a critical backdoor is not presented with the same visual weight as a suspicious-looking but ultimately harmless encoded setting.

Finding a malicious row is only useful if you can act on it. Anything the scanner flags can be cleaned from the dashboard directly, which matters more than it sounds: the alternative is writing DELETE and UPDATE statements against a live production database, at whatever hour you found out, on the basis of a table name and a row ID.

That is how sites get broken during cleanups. A slightly wrong WHERE clause removes legitimate settings, a serialised value is edited without correcting its length prefix and the option silently stops unserialising, and now you have two problems.

On Pro, the LLM layer adds a second opinion to the same findings, reasoning about what a flagged entry is written to accomplish rather than only that it matched a pattern, and explaining it in plain English before you decide.