UNDERSTAND THE FINDING BEFORE CHOOSING THE RESPONSE
Site & File Protection
SiteWatch Site & File Protection compares WordPress core, plugin and theme files with trusted references, reviews published vulnerability advisories and selected request signals, and connects findings to reviewed repair, quarantine and hardening workflows.
Vulnerabilities
Review a version advisory with its remediation context.
Compare supported core/plugin/theme identities and versions with available published advisory data. Inspect affected ranges and known fixed versions separately from ordinary update availability.
An advisory describes a version concern. It does not prove exploitation, and unavailable information does not establish that a package is safe.
Keep provider availability and supported identity scope visible when deciding which update to review.
Request Controls
Observe focused signals before enabling blocking.
Inspect selected bounded scalar GET/POST values for documented SQL, script and traversal patterns. Review rule identifiers and configure suitable restrictions deliberately.
JSON request bodies. From SiteWatch 2.0.1, JSON bodies of up to 64 KB are inspected with the same exclusions and Observe/Block modes as query and form values. In Block mode, a post that a user who is not an administrator saves from the block editor can be rejected when its content matches a rule, as classic editor saves already could; review such matches in Observe mode first.
Endpoint budgets cover supported login, XML-RPC, REST and admin-post paths with documented exceptions. From SiteWatch 2.0.1, encoded, upper-case and prefixed spellings of the same endpoint share one counter, and a rest_route value in a form body counts as a REST request. Logging retains the relevant rule context without keeping submitted values.
This is a focused policy layer. It does not inspect JSON bodies above 64 KB, uploaded files or every application request, and it is not a complete WAF or volumetric DDoS service.
Early Protection
Enable the supported hosting path only after its probes pass.
Compatible PHP hosting can use optional inspection before WordPress loads. Existing configuration and compatibility probes are part of determining whether the early path can be enabled.
Start with observation and retain hosting recovery access while changing configuration. Unsupported hosting stays unsupported instead of being described as protected.
The early path runs within the supported PHP environment. It does not filter traffic before PHP or provide upstream bandwidth protection.
File Integrity
Compare files with the right reference.
Inspect supported WordPress core files against version/locale references and eligible public package files against available trusted versions. Private plugin/theme scopes can use manifests from trusted original packages.
Baseline comparison records additions, differences and missing files within completed collection scope. A baseline describes what was present; it is not automatically a trusted original release.
Keep incomplete inspections and unavailable references distinguishable from verified matches.
Investigation
Bring related evidence into a reviewed decision.
Connect retained scan findings, integrity differences, vulnerability results and health observations. Inspect baseline context and available nearby events before attributing a cause.
Evidence-bound acknowledgements record the reviewed state. They do not repair a vulnerability or declare the file safe forever.
Use the workspace to identify the specific target and justified next action, with hosting evidence retained where an incident needs further investigation.
Repair & Quarantine
Check the target again and retain the recovery material.
Supported repair validates an appropriate trusted replacement and checks the current target before applying it. The documented workflow stores an encrypted backup before the reviewed change.
Quarantine also uses explicit review and protected recovery. Restore validates retained content and destination state, refusing to overwrite a conflicting file.
Scope, file-size/type limits and salt-dependent backup recovery matter. Keep hosting backups and a maintenance plan; application hooks do not make arbitrary concurrent filesystem edits atomic.
Hardening
Apply supported configuration changes with their effects visible.
Review file-editor/debug settings, selected sensitive-file exposure, permission signals and unexpected root PHP files. Use supported reversible policies where the configuration and authority allow the change.
A configuration signal is evidence for review, not automatic proof of infection. Inspect the actual file or setting and its role on the site.
Supported rollback preserves later manual changes instead of indiscriminately overwriting the current policy.
A Practical Investigation
Choose a specific finding, inspect its references and retained context, then decide whether it needs observation, an update, configuration or a reviewed file response. Record the outcome and recheck the affected scope.
Questions About Site Protection
Does a suspicious pattern prove a file is infected?
No. Pattern findings must be interpreted alongside file integrity, references and the actual file context.
Does an unavailable reference mean the package is clean?
No. Missing or incomplete reference evidence remains unverified.
Is Request Controls a complete web application firewall?
No. It is a focused policy layer that inspects selected bounded GET/POST values, JSON bodies up to 64 KB from SiteWatch 2.0.1, and endpoint budgets. It does not inspect larger JSON bodies or uploaded files, and it is not a complete WAF or volumetric DDoS service.
Does repair keep a copy of the replaced file?
Yes. The documented repair workflow stores an encrypted backup before applying a validated trusted replacement. Backup recovery depends on the site salts, so keep hosting backups as well.
Continue the Review
Reviewed against SiteWatch 2.0.1 · Last updated 29 October 2026