Skip to main content

Known-threat detection

Known-threat detection​

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 indicators from the supported rules. Review the finding before deciding whether a repair is appropriate; detection alone never changes files.
  • 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​

In Awthy → Reporting → Site changes, open Known-threat protection and select Scan this site. Read its coverage result and finding summaries before deciding what to do next. Operators can also run the 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​

Eligible exact findings offer Review safe repair. If that action is unavailable, investigate manually or ask your hosting operator for help; do not assume a different file can use the same repair.

  1. Select Review safe repair for the finding.
  2. Read What will change, Affected area, Risk check, and Recovery point.
  3. Confirm that the recovery point and proposed change match the file you intend to repair.
  4. Select I reviewed the recovery point and want to queue this exact repair only when you are ready.
  5. Select Queue verified repair and wait for the result.

The preview does not change files. The queued repair stops if the preview becomes stale or the file changes. If the panel offers Prepare a new preview, review it again before approving. If status cannot be refreshed, use Retry job status to check the existing job.

Repair verified describes that repair's result, not the whole site's security. Reinfection needs review requires investigation of how the threat returned. Password resets, forced logout, and incident lockdown remain separate actions.

Last updated on