Every site is under fire.Make sure nothing lands.

In the Avakode build (the free zip), yes, and it is the same advisories. The feed is off until you switch it on in Settings, and the wordpress.org package has no feed at all: its only request goes to wordpress.org, for the checksums. What Pro sells is time: the Avakode build’s feed is served seven days behind the licensed one, and the screen says which of the two you are reading rather than implying they are the same. The download is a public document identical for every site — no licence key, no site address, no list of your plugins. The matching against what you have installed happens on your own server, after the download.

A PHP file sitting in a core directory that the release wordpress.org published does not contain — and, once you tick “Also monitor plugins & themes” in Settings, one sitting in a plugin directory that the plugin’s published release does not contain. That is the shape a backdoor has, and no scan-to-scan comparison can see it: a shell that was already on disk when the baseline was taken looks exactly like an unchanged file. Once “Also monitor plugins & themes” is on, anything with no published hashes — a premium plugin, any theme — is marked “no reference” and stays on the snapshot comparison; until then the file check covers core only. It is never counted as clean, because a tick beside something nothing checked is worse than no tick.

Not the free plugin: the Pro add-on does this, and only if you switch it on, and then only when it can prove the point. The advisory has to name the version that fixes it, WordPress has to be offering an update that reaches it, and that version has to fall outside the advisory’s own affected range — an update that is merely newer is refused, and so is one it cannot check. It runs on cron, one plugin per run, obeys your allow and deny lists, skips a staging copy and a plugin directory that is a symlink, waits a day after any failure, and tells you by e-mail and in the audit log.

Press “Verify chain”. Every row carries the hash of the row before it, so an edited field breaks its own row and a deleted row leaves the next one pointing at a hash the table cannot produce. On a very large log the check covers the oldest fifty thousand rows and says plainly that it was truncated, rather than dying half-way and showing you an empty screen.

No. You create a token scoped to one zone and one permission; it is encrypted and stored on your own site, and your site calls Cloudflare directly. Avakode never sees it. With the add-on on, the site also refreshes Cloudflare’s own published list of edge addresses once a day — a public document — so a site behind a newer edge does not quietly start logging every visitor as the edge itself.

In the Avakode build, “Explain this event” spends one Forge credit; the button says so before you press it, and the answer is stored with the event so reading it again is free. The wordpress.org package has no such button. What reaches the network depends on the build. From the wordpress.org package it is one request: the checksum lookup at wordpress.org, and only when the file check runs. The Avakode build adds six more, and each waits for you: the daily advisory download, once you switch the feed on in Settings; the “Explain this event” press, which sends that one event together with your site’s address and a few facts about it (the first press on a site with no licence and no trial yet starts the free trial, which sends your administrator e-mail address); the Restore press, which fetches that one core file from core.svn.wordpress.org; the “Connect Avakode account” press on the Settings screen, which sends the product name, your site’s address and the return address, then takes you to avakode.com to approve (once you are connected, Settings reads your remaining credits, and Disconnect revokes the connection); the feedback card, only when you press “Send feedback”, with your score, your comment and version numbers; and the health check at api.avakode.com/health, only when you press Run diagnostics on the Forge Suite screen (or a repair button beside it). In the Avakode build, the advisory download and the health check say nothing about your site. The hourly AI batch is Pro and off until you enable it.

In Guard Forge → Cases the free plugin turns findings into cases: a file the integrity scan cannot explain, a series of login attempts and, in the Avakode build, an advisory that matches an installed plugin or theme version. In the free plugin you can acknowledge a case, assign it, ask for verification, explain a changed file, and block the IP behind a series of login attempts (that marks the case mitigated). Lockdown and “Apply fix” (the update that closes an advisory) come with Pro, and only the recheck built into the plugin can set Fixed: when it cannot decide, a case nobody has acted on yet reads Unverified, and a case you have already decided on stays as you left it. A monthly report shows four counts (detected, checked, fixed, unknown) and downloads as a CSV file. It does not investigate or clean a compromised site: “fixed” means the recheck found the condition gone.