Support
Log in Sign up
WordPress · security

Every site is under fire.Make sure nothing lands.

Guard Forge hardens WordPress, locks out password guessers and gives every account a second factor — then checks your files against the build wordpress.org actually published, chains the audit log so a line cannot be edited quietly, and names the advisories that hit your plugins. All free; Pro adds the firewall, the scanner, alerts with quiet hours and the update that closes them.

being forged — launching with the Avakode suite
Official hashescore and wordpress.org plugins checked against the published build, not against yesterday’s snapshot
7days the free advisory feed runs behind the licensed one — same advisories, and the screen says which you are reading
Chainedevery audit row carries the hash of the row before it, so an edited or deleted line is detectable
The gate

Every site is under fire. The difference is whether a shot lands.

10 rules, running inside your WordPress. In this run they stopped 10 attacks and let all 3 ordinary requests through — the login redirect, the search for "union jack", the checkout note. A firewall that blocks your customers is not protection.

10 of 10 attacks stopped at the gate

0 false positives · 10 rules · 5 tries then locked

Every block is logged with the rule that fired and the request that tripped it — so a false positive is something you can read and fix, not a mystery 403.

Checksums · chain · advisories

It checks your files against the build wordpress.org published, not against yesterday.

Official hashes with a verdict for the file nobody published, an audit log chained row to row, the advisories that name your plugins — and, on Pro, the update that closes them.

Not “changed” — not in the official build

Every core file, and every plugin wordpress.org hosts, is compared with the checksums published for that exact release. Five verdicts: official, modified, missing, no reference — and the one a snapshot diff can never reach, a file that is in no published build at all. A modified core file has a one-click restore, checked against the official hash before it is written, with the old file kept where the web cannot fetch it.

An audit log that cannot be quietly edited

Each row is hashed together with the hash of the row before it, and “Verify chain” walks the lot. Change one field on one line and the line reports itself; delete a line and the gap shows, because the next row points at a hash nothing in the table produces.

The advisories, without paying for them

The published advisories for WordPress, your plugins and your themes, matched daily against what is actually installed and at which version. The free feed is served seven days behind and the screen says so; Pro reads the same advisories in real time. The download is one public document, identical for every site, and carries nothing about yours.

Patch by update (Pro)

Off until you switch it on. It installs the update only when the advisory names a fixed version, WordPress is offering one that reaches it, and that offered version is outside the advisory’s own affected range — “merely newer” is refused. One plugin per cron run, an allow list and a deny list, never on a copy of the site, never on a directory that is a symlink, and an e-mail plus an audit row for each one.

Alerts you can silence at night (Pro)

A card per channel — Telegram, Slack, a signed webhook — with a minimum severity each, a “Send test” that really sends, and a digest you can set to immediate, hourly or daily. Quiet hours hold the ordinary traffic until morning; a lockdown or a malware finding goes straight through them. Tokens and secrets are encrypted on your site and the form never prints them back.

A lockdown that throws itself (Pro)

Off until you switch it on. Then twenty different addresses locked out inside ten minutes — or, if you ask for that one too, a single finding from the malware scanner — shuts registration, comments, XML-RPC and anonymous REST writes without waiting for you. It lifts itself an hour later, writes both ends to the audit log, and never fires on a staging copy.

The lockout

Guessing costs them. Not you.

5 wrong passwords and the address is locked for 30 minutes, with every attempt written to a log you keep for 30 days. Connect Cloudflare and the block goes to the edge, so the next request never reaches your server — and behind a proxy the address comes from the trusted chain, so nobody can spoof somebody else into a lockout.

login log kept 30 days
  1. attempt 1 user admin · wrong password
  2. attempt 2 user admin · wrong password
  3. attempt 3 user admin · wrong password
  4. attempt 4 user admin · wrong password
  5. attempt 5 user admin · wrong password
  6. lockout address locked for 30 minutes · pushed to the edge
Closing the gate

Activate, read what the scan found, then add the add-on.

01

Activate

Sensible defaults are on from the first request, and the hardening score names what is still open, what each row is worth and the screen that fixes it.

02

Read what it found

The first scan tells you which files are not part of the official build, which of your plugins have a published advisory against them, and who changed what — on a log whose chain you can verify.

03

Add the add-on

The firewall, the malware scanner, real-time advisories, the update that closes them, alerts with quiet hours, and the lockdown that throws itself.

Fire at it

Send anything you like at the gate. Including the harmless things.

These are the engine’s own 10 rules and its own request corpus. Send an injection and read the rule that caught it. Then send the 3 ordinary requests — a login redirect, a shopper searching for a “union jack” flag poster, a note on a checkout — and watch them go through.

request your site, behind the gate 10 rules armed

10stopped at the gate

3ordinary requests let through

0false positives

Every block is logged with the rule that fired and the request that tripped it. That is what makes a false positive something you can read and fix, instead of a mystery 403 your customer reports as “the site is broken”.

10 stopped, 3 let through, nothing ordinary refused.
Stands with

Works with your stack

Cloudflare
wordpress.org checksums
MaxMind GeoLite2
Telegram
Slack
Signed webhooks
Apache & nginx
WooCommerce
Comparison

Guard Forge vs what your host already gives you

What you are comparing Guard Forge a host’s WAF
Where a bad request dies Before WordPress loads — and at Cloudflare’s edge once connected At the host’s edge, if the plan includes one
Login lockout Five tries, then the address is locked and the attempt is written down Rarely offered, and rarely visible to you
File integrity Against the hashes wordpress.org published for that exact release, with a verdict for a file that is in no build at all Not covered
Vulnerability advisories Matched to the versions you actually run — free seven days behind, real time with the add-on Generic advisories, if any
Closing the advisory With Pro: installs the update that leaves the affected range, on cron, under an allow list and a deny list Tells you about it, at best
Evidence afterwards A hash-chained audit log on your own site: an edited or deleted line is detectable Their dashboard, their retention, their export
Size of the managed ruleset Ten rules, chosen and explained A commercial WAF ships thousands and updates them hourly their win
Cleaning up a site that is already compromised Not its job — it tells you what changed and hands you the evidence Many hosts will do the cleanup, or sell you one their win

Guard Forge is prevention, not incident response. If the site is already compromised, buy a cleanup first and install this afterwards.

Pricing

The scan, the chain and the feed are free. The licence buys the add-on.

No upsells, no surprises.

Personal
$59 /year
1 site
Get it on avakode.com
Most popular
Professional
$129 /year
5 sites
Get it on avakode.com
Agency
$219 /year
unlimited
Get it on avakode.com
Before you buy

What runs where in Guard Forge

Which work happens inside your own install, what leaves it, what needs a paid plan, and what a lapsed licence leaves behind.

What the free tier does inside your own install

  • Files judged against the official wordpress.org build
  • An audit log chained row to row, and verifiable
  • Core and wordpress.org plugins checked against the published build, not against yesterday’s snapshot

What leaves your site when a feature is on, and where it goes

  • Usage telemetry is off until you switch it on: every send reads the site option `forge_telemetry_consent` first, and stops when it is not "1".
  • With telemetry on, batches of events POST to https://api.avakode.com/telemetry/batch.
  • The in-admin feedback form POSTs your rating and comment to https://api.avakode.com/feedback when you press Send.
  • The Forge Suite dashboard health card GETs https://api.avakode.com/health.

What needs Pro, credits or an outside service

  • Pro is a separate plugin. With no Pro add-on loaded the plan is free, whatever is stored in the database.
  • Licence activation and every AI request go to https://api.avakode.com.
  • AI actions spend credits from your Avakode balance; the price per action is decided on the server (1 credit for a translation, 3 for a whole post).
  • A request over 10,000 tokens costs a multiple of the base action price.

What happens when the licence lapses

  • Free features keep working. The wp.org base ships no licensing SDK: without the Pro add-on answering "pro" through the `forge_pro_plan` filter the plan reads free.
  • When the paid ladder answers "free" in so many words, the stored grace marker `forge_license_last_pro_at` is cleared and Pro gates close on the next admin request.
  • Pro keeps working for 6 hours of silence from the licence server — that window covers an outage, not a revoked licence.
  • A lapse removes no data. Tables and options go away only when you uninstall the plugin.

How long data is kept, and how you take it out

  • Brute-force log rows are kept 30 days by default, the audit log 60; both are settings, 1–365 days.
  • The audit-log retention setting is the second of the two, with the same 1–365 bounds.
  • A report downloads as a file from the plugin screen; the Pro audit export is a separate download.
  • Pro audit export.

The same five questions for every tool →

Switching

Nothing to import, and nothing you cannot undo.

Nothing to migrate

No account to open and no DNS to move. Activate it and the lockout, the log, the integrity scan and the advisory feed are already running.

It runs alongside a host WAF

Two layers do not conflict: theirs refuses the obvious, this one knows what WordPress is and what your plugins are.

Leaving takes your secrets with it

Deleting the plugin always removes your two-factor enrolments — those are shared secrets and recovery codes, and a database outlives a plugin. Everything else — the login log, the integrity snapshots, the audit trail — is kept unless you tick the box that says otherwise.

FAQ

What people ask before they trust a security plugin

Yes, and it is the same advisories. What Pro sells is time: the free 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 or plugin directory that the release wordpress.org published 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. Anything with no published hashes — a premium plugin, any theme — is marked “no reference” and stays on the snapshot comparison. It is never counted as clean, because a tick beside something nothing checked is worse than no tick.
Only if you switch that 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.
“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. Three things reach the network from the free plugin: that press, the daily checksum lookup at wordpress.org, and the daily advisory download — and only the press says anything about your site. The hourly AI batch is Pro and off until you enable it.
Bar the door

Close the gate before someone tries it.

The free core hardens the site, watches the files against the official hashes, chains the log and reads the advisories. Pro adds the firewall, the scanner, the alerts and the patch.

Forge AI Assistant Online

Hi! I'm the Guard Forge AI assistant. Ask me anything about the plugin — setup, features, troubleshooting, or development.

Just now
Powered by Forge AI · Browse docs