Scanning a WordPress Site for Vulnerabilities

wp core version
wp plugin list --fields=name,status,version,update --format=json
wp theme list --fields=name,status,version,update --format=json

List WordPress core, active and inactive plugins, themes, must-use plugins and relevant custom components. Include their installed versions and source. A dashboard update badge can be helpful, but a commercial plugin with an expired licence or a custom deployment process may not participate in the ordinary update mechanism.

Use authenticated administration or a trusted host inventory where possible. The illustrative WP-CLI commands list plugins and themes; run them only in the correct installation with authorised access. Keep the inventory in a controlled location. It can reveal which software an attacker might target even though it does not contain working passwords.

Record components supplied by the host separately from files managed by your repository. Identify who is responsible for their updates. Remove genuinely unused components through an approved maintenance process after checking dependencies and preserving any needed configuration. An inactive plugin is not automatically harmless if reachable files or other behaviours remain available.

An external scanner typically discovers evidence from public responses, file paths and other fingerprints. A blocked request or hidden version can reduce visibility without fixing the underlying software. An authenticated inventory can supply information that a public scan misses, but it still depends on trustworthy local data and coverage of the relevant components.

WPScan distinguishes the scanning tool from its vulnerability-data API. Its documentation explains that an API token and applicable quota affect access to vulnerability information. A completed scan without the expected advisory data should not be described as a completed known-vulnerability assessment. Review current service terms and the tool's actual output.

Also distinguish vulnerability checking from malware detection and application testing. A known issue can exist without evidence of exploitation; a compromised site can contain no currently listed vulnerable plugin. Custom authorisation errors, unsafe business logic and compromised credentials require other investigation. The plugin vulnerability guide gives context for maintaining third-party components.

Confirm the exact product, affected version range, fixed version and advisory source. Similar plugin names and bundled libraries can produce mistaken matches. A version fingerprint alone may also be incomplete where a vendor has backported a fix. Document the evidence for the installed build rather than relying on a report title.

Read the prerequisites: whether exploitation needs authentication, a particular role, an enabled feature or access to an upload route. Consider what the issue could expose on this site. A shop handling accounts and orders has different business consequences from a disconnected test installation, even when the underlying issue has the same published severity.

Prioritise serious exposed issues promptly, especially where credible exploitation is reported, while following the site's incident and change process. Do not postpone an important repair simply because it is not the monthly maintenance date. Conversely, a finding that does not apply should be closed with a reason and evidence, not silently hidden from future reports.

Obtain updates through the vendor's supported distribution channel and preserve verification. Before changing a business-critical component, make sure you have a recoverable backup and understand whether the update changes the database. Restoring old files may not reverse a schema migration, and rolling a shop database back can lose new orders.

Use staging to test the journeys the component supports. A form plugin update needs validation, delivery and failure-state checks; a commerce update needs representative product, checkout and order-management checks. A dashboard that loads successfully does not establish that integrations still work. Keep test payments and messages separate from live operations.

After deployment, confirm the installed version or fixed build and repeat the relevant assessment. Check logs and the public journey for regressions. Record the change, its owner and the verification result. The security hardening checklist covers wider controls, but an update is not complete until the affected installation is verified.

First confirm whether a supported fixed version, vendor workaround or temporary feature restriction is available. If the plugin is abandoned or the patch breaks a necessary integration, document the exposure and the practical alternatives. A difficult replacement cost does not make the vulnerability disappear.

Consider disabling the affected feature, restricting the vulnerable route, replacing the component or removing it. Each mitigation has assumptions and a business cost. A firewall rule may reduce exposure for a particular pattern, but it should be documented as a temporary control with an owner and review date. Do not label it equivalent to a vendor repair without evidence.

Set an explicit deadline and decision-maker for the remaining work. If a component must remain temporarily, increase monitoring where useful and keep the replacement plan visible. Avoid editing vendor files without a maintainable, reviewed strategy; the next update can erase a local patch, and an improvised change can introduce another defect.

If logs, modified files or unexpected accounts suggest compromise, follow an incident response process rather than simply updating the flagged plugin and declaring the site clean. Preserve relevant evidence and involve the responsible host or security team. The entry point, persistence and exposed data may require separate investigation.

Check administrative accounts, integrations and credentials as part of the authorised response. Replacing a vulnerable file does not revoke a stolen session or remove an unrelated malicious scheduled task. Recovery may involve restoring a known-good state, rotating affected credentials and verifying the broader environment, with care around business data created after the recovery point.

Avoid publishing customer data or working credentials in a support ticket or scan report. Keep findings and evidence access-controlled, and distinguish confirmed facts from suspicions. The malware removal guide addresses that recovery workflow. Vulnerability maintenance and incident response support each other, but they answer different questions.

Choose a cadence based on the site's exposure, change rate and business impact, supplemented by alerts for important new advisories. A monthly review may organise the maintenance calendar, but it is not a reason to wait on an urgent exposed issue. Run checks after significant updates and before handing over responsibility.

For each finding, record the component, evidence, priority, owner, next action and verification date. Track unknown or failed checks explicitly. A report with no findings and no advisory-data access is a different outcome from a completed scan with no applicable known issues. Review exclusions periodically so yesterday's exception does not become an invisible permanent gap.

At handover, make sure alerts reach an address monitored by the business or contracted maintainer. Test the notification route without disclosing sensitive details. The useful deliverable is a maintained inventory and a short, current repair list with evidence of closure, rather than a folder of unread scan exports.