WordPress security

Confirm WordPress before testing

VICE checks the verified domain for WordPress page, header, and public asset markers before running focused probes. This keeps the result tied to observed CMS behavior instead of a guessed technology label.

If WordPress cannot be confirmed, the audit reports a coverage limitation instead of inventing a score or vulnerability.

Review public identity exposure

WordPress can reveal account names through author redirects and the public REST users endpoint. VICE records the observed behavior so you can compare it with the site’s intended publishing model.

• Author archive redirects that expose a login or display name.
• Public responses from the REST users endpoint.
• Evidence markers that identify the tested path without storing sensitive response content.

Inspect XML-RPC, login, and cron

Reachability alone does not prove exploitation. Each finding should describe the stronger behavior observed, its confidence, and the recommended control.

• Reachable XML-RPC behavior that can increase the efficiency of password attempts.
• The default WordPress login path and its public behavior.
• Public HTTP access to the WordPress cron endpoint.

Launch the focused audit

Open WordPress in a verified domain workspace and start the scan. The run appears in the central audit list with the same status and history as every managed audit.

Actionable issues are added to the domain Findings view. WordPress also remains available inside full and custom audits.

Read exposure in context

A public author name may be intentional on a publishing site, while a login identifier reused elsewhere creates more risk. Review the evidence against the account model, authentication controls, and operational requirements.

A failed request or unreachable site is a coverage limitation. It is not a critical WordPress finding.

Fix and retest

Rerun the focused WordPress audit from the same workspace and compare equivalent coverage before marking a finding solved.

• Restrict public user enumeration when the site does not require it.
• Disable XML-RPC when unused, or protect required methods with strong authentication and rate limits.
• Protect login flows with rate limits, strong credentials, and multi-factor authentication where available.
• Prefer a server scheduler for WordPress cron when public HTTP triggering is unnecessary.