Evidence
Audit chain verification failed
Verification failing means the record cannot be trusted to be complete. Preserve it before you do anything else.
- Activity & evidence
- 5 min read
Do this first
- Take a database backup now. Before investigating, before restarting anything.
- Note the failing point that verification reported.
- Switch the site to paused or read-only if agents are active. Do not let more events accumulate on a chain you do not yet trust.
The failure is the finding. Removing it destroys the only evidence of whatever caused it.
Causes that are not an attack
- A partial database restore — restoring some tables and not others leaves the chain inconsistent with itself.
- Manual database editing — a migration script, a search-and-replace across the whole database, or a developer clearing rows by hand.
- A staging clone where rows were pruned to reduce size.
- Storage-level corruption, which usually shows up in other tables too.
All four are worth confirming quickly, because they are far more common than the alternative and each has an obvious owner to ask.
When it is not one of those
If nobody restored, migrated, cloned, or hand-edited the database, treat it as a possible compromise of the site at the database level. Chain tampering requires database write access, which means the concern is larger than this plugin.
- Keep the site paused.
- Preserve the backup you took and do not overwrite it.
- Rotate or revoke every agent connection.
- Investigate the host and database access, not just WordPress.
If you believe the plugin is at fault
A chain that verification does not detect as tampered, or one that fails without any of the causes above, is in scope for responsible disclosure. Send it there rather than to the support queue or a public forum.
Activity & evidence
Keep the boundary while you fix the problem.
A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.