Skip to main content

Known-threat detection

Known-threat detection​

Last verified: 2026-07-21

Awthy checks allowlisted WordPress files for the reviewed ea-wp-injector threat family. Detection runs locally and does not require an Awthy Hub connection. This is a focused known-threat check, not a general malware scanner, firewall, forensic service, backup, or guarantee that the rest of a site is uncompromised.

Read the result before acting​

  • Clean means every required root completed against the named bundled rules and no unresolved finding remains.
  • Findings means Awthy found reviewed indicators. Review the finding and incident guidance; this release does not offer automatic cleanup.
  • Partial means a budget, unreadable path, changing tree, or unavailable root prevented complete coverage. It is not a clean result.
  • Failed means the scan could not finish safely. Check diagnostics and rerun after correcting the reported class of problem.
  • Overdue means no completed scan has been recorded within the expected window.

Finding screens and support output use display-safe labels and stable IDs. They do not expose file bodies, absolute server paths, credentials, raw hashes, rule operands, or unredacted diffs.

Run a scan with WP-CLI​

Managers can start a scan from Awthy. Operators can run the same bounded engine from the WordPress directory:

wp awthy threat scan --format=json
wp awthy threat findings --format=json
wp awthy threat show <finding-uuid> --format=json

The scan command reports whether traversal and absence reconciliation completed. A partial exit or complete: false requires another bounded run; do not turn it into a clean report in automation.

Keep scheduled scans reliable​

WordPress cron normally runs when the site receives traffic. For quiet or operationally managed sites, configure one OS or hosting scheduler to run due WordPress events every five minutes:

*/5 * * * * cd /path/to/wordpress && wp cron event run --due-now --quiet

Run it as the site's filesystem owner with the correct PHP and WordPress environment. Set DISABLE_WP_CRON only after the replacement scheduler works. Avoid overlapping schedulers. Confirm wp cron event list includes awthy/threat_scan_scheduled, then check Awthy system diagnostics for a completed, current scan.

What to do after a finding​

Do not delete a file merely because it looks unusual. Preserve a current recovery copy, review Awthy's safe finding summary, and investigate how the change arrived: administrators and sessions, application passwords, plugins and themes, WordPress core, scheduled tasks, hosting/control-panel access, and FTP/SFTP credentials. A removed file can be recreated while the ingress path remains open.

Use the incident-response controls when account compromise is suspected. Use the supervised standalone rescue runbook only when its exact family and recovery prerequisites match the incident.

If WordPress or Awthy cannot perform the recovery​

Do not make a browser request the recovery path when the plugin is disabled, WordPress does not boot, or the host asks for filesystem credentials. Preserve the current files and database, verify a host recovery point, and ask the hosting operator to use the signed standalone rescue package from the host PHP CLI against a disposable copy first. Do not put FTP, SFTP, or control-panel credentials into Awthy or wp-config.php; if the host cannot provide an approved filesystem-owner session and an off-root quarantine location, keep the incident report-only and escalate it.

Destructive repair preview​

When an exact-confidence finding becomes actionable, the local remediation panel (awthy-known-threat-remediation) shows a preview-only screen before any repair is queued. The preview is rendered only when the finding's confidence equals exact and the underlying signed rule bundle is verified end to end; weaker findings never reach this panel and must be escalated through a manual review path instead.

  • The screen is preview-only. No repair runs until an operator explicitly confirms it.
  • A single primary action is offered: Queue verified repair. There are no secondary "queue all" or silent "queue without preview" controls.
  • The operator must tick an acknowledgement checkbox before Queue verified repair becomes available. The acknowledgement records that the operator read the blast-radius callout and the human risk summary.
  • A blast-radius callout lists the files and directories the verified repair will touch, the recovery point it relies on, and the exact rule that authorized it. The same data is shown as a labelled blast-radius row in the finding summary.
  • Status changes during preview, queueing, and execution are announced through an accessible live region (role="status" with aria-live="polite"), so screen readers and keyboard users receive the same update as sighted users. The live region is also the source of truth for the visible status message.
  • A single repair never auto-triggers incident lockdown, forced logout, application-password revocation, password reset, or administrator/user review. Those controls remain recommended adjacent navigation only.
  • Reinfection is shown as a distinct state ("Reinfection needs review") and is never reported as clean.
Last updated on