TL;DR
- A changed WordPress risk score is a signal to investigate, not proof that the site was hacked.
- Save the old and new scores, timestamps, reasons, component versions, and recent maintenance activity before changing anything.
- Separate website changes from updates to CVE records, severity metrics, or the scoring system.
- Check components, core file integrity, configuration, accounts, and logs before deciding whether to remediate or escalate.
When a WordPress risk score changed, start with evidence rather than panic. A score is an assessment produced from inputs and scoring rules. WP Triage, for example, gives each site a 0–100 score, identifies the top three issues, and recommends a fix order. A higher result deserves attention, but it does not establish compromise.
Use the workflow below to build a short timeline, test the leading explanation, and record the decision another administrator can reproduce.
Start by recording exactly what changed
Preserve the original result before applying updates, deleting accounts, or cleaning files. Record the affected site, old score, new score, scan timestamps, displayed reasons, and any changed component scores.
Also capture the WordPress version, active and inactive plugins, themes, hosting changes, recent deployments, DNS or SSL work, firewall alerts, and maintenance tickets. Export screenshots or reports where possible. A scoring system can change its output when any input changes, even if nobody edited the site.
| Record | Example evidence |
|---|---|
| Score event | Old score, new score, timestamp, affected site |
| Software state | Core, plugin, and theme versions |
| Recent activity | Deployments, hosting work, updates, alerts |
A risk score starts an investigation; supporting evidence determines whether compromise occurred.
Separate a real site change from a scoring-data update
To understand why a WordPress risk score changed, compare the score timestamp with activity on the site and with changes in the data used to assess it. Check core, plugin, and theme updates, hosting work, DNS, SSL, firewall rules, and deployments.
Then review the relevant vulnerability record. The NVD CVE FAQ explains CVE records and their maintenance; vulnerability information can change after initial publication. CVSS also uses defined metric groups. The FIRST CVSS v4.0 specification describes Base, Threat, Environmental, and Supplemental metrics. A revised metric value can alter severity without a new file appearing on your server.
That distinction prevents a common mistake: treating a database update as evidence of a fresh deployment. Check both timelines before blaming either the site or the scanner.
Check WordPress core, plugins, and themes for new exposure
Build a component inventory with the name, version, active status, update status, source, and affected-version range in each advisory. Prioritise internet-facing plugins, abandoned software, premium extensions with unclear update channels, and components tied to a newly published WordPress plugin vulnerability.
Verify the advisory before acting. A CVE does not automatically affect every release of a plugin. The affected-version range and fixed version determine whether your installation is exposed. WordPress recommends keeping core, plugins, and themes updated and removing software you do not need in its hardening guidance.
Worked example: a data change raises the score
A plugin remains at the same version after Tuesday’s scan. On Wednesday, its vulnerability record receives a revised severity assessment. The next scan produces a higher score, although no deployment occurred. The correct response is to verify the affected range, update through a trusted channel if exposed, and preserve the advisory and scan evidence.
Verify that the installed WordPress files have not changed
A WordPress file integrity check can test core files against the checksums for the installed version. Run it from the WordPress installation directory, or provide the appropriate path option through your hosting setup:
wp core verify-checksums
The official WP-CLI documentation states that the command downloads checksums for the current version, compares them with installed files, and avoids loading WordPress during verification. Use the matching version and locale if the command reports a problem.
A mismatch requires review, not an automatic conclusion of hacking. Core checksums do not prove that plugin files, themes, uploads, database content, credentials, or server settings are clean. Review the changed paths, file ownership, permissions, deployment records, and hosting logs. Keep the result with the investigation record.
Core checksum verification is one narrow test inside a wider integrity review, not a complete WordPress hacked site check.
Review configuration and access changes that affect risk
Compare the current WordPress security configuration with the last known-good state. Review administrator accounts, authentication settings, file editing, debug settings, XML-RPC exposure, database credentials, permissions, and server configuration. The WordPress hardening handbook covers these controls, but the right setting depends on the host, plugins, and operational needs.
Change one control at a time and document the trade-off. For example, disabling dashboard file editing can reduce an attack path, but administrators still need a tested deployment method for legitimate changes.
Worked example: maintenance created a new risk
A maintenance task creates an administrator account and enables the file editor. The score rises afterward. Compare the account creation time with access logs, confirm who authorised the task, inspect the account’s activity, then disable or remove access only after preserving evidence and confirming a safe recovery path.
Use WP-CLI and logs to test the leading explanation
Run read-only checks first: confirm the core version, list plugins and themes, inspect users, and verify core checksums. Use commands documented for your WP-CLI version and hosting environment; don’t assume every command is safe on every production system. The official WP-CLI security checks guide provides supported inspection workflows for site owners.
Compare WordPress, web-server, firewall, hosting, and deployment logs around the score change. Log retention depends on the host and configured services, so note missing periods rather than treating silence as proof of safety.
For every check, record the command or dashboard path, timestamp, result, evidence location, and follow-up action. This turns a WordPress security audit into a reproducible investigation instead of a collection of guesses.
| Check | Record | Decision use |
|---|---|---|
| Component inventory | Name, version, status | Find exposure |
| Checksum result | Changed or missing paths | Review integrity |
| Logs | Requests, accounts, deployments | Test the timeline |
When not to treat a score change as proof of compromise
Pause before declaring an incident when:
- the score changed after a CVE or CVSS record update, with no corresponding site activity;
- the scanner changed its documented inputs or scoring method;
- the result concerns an installed but inactive component whose affected range does not include your version;
- the only finding is a checksum mismatch caused by a documented deployment or localisation file;
- you lack logs and cannot yet distinguish an authorised change from an unknown one.
These conditions still require review. They simply call for evidence before destructive cleanup or an incident declaration.
Decide whether to remediate, escalate, or keep monitoring
Remediate confirmed exposure with a verified update, removal of unused software, corrected access, or restoration of known-clean files. Test updates against the site’s hosting setup and record the change. WP Triage can help prioritise the work, but it does not replace a firewall, virtual patching, backups, or remote updates.
Worked example: remediation follows evidence
A checksum mismatch appears in a core directory. Separate review finds no matching deployment, an unknown administrator, and suspicious requests in hosting logs. Preserve the evidence, restrict access, rotate affected credentials, involve a qualified incident responder, and restore from a known-clean source according to the evidence. A single score or scan cannot prove the site is clean.
Keep a compact record containing the score change, evidence reviewed, root cause, action taken, and next review date. A WordPress risk score changed event becomes manageable when each conclusion has a timestamp and a supporting artifact.
Frequently asked questions
Does a changed WordPress risk score mean my site has been hacked?
No. A changed score signals that the scoring inputs, vulnerability data, scoring method, or site state changed. Compromise requires supporting evidence such as unauthorised accounts, unexplained file changes, malicious code, suspicious requests, or altered configuration.
How often should a WordPress risk score be checked after a security update?
Check after the update has completed and the site has passed its normal functional checks, then continue according to the monitoring schedule used by your agency or hosting setup. Preserve the pre-update score so the comparison remains meaningful.
Use this sequence: preserve the score evidence, check recent changes, review vulnerabilities, verify core integrity, inspect access and logs, then remediate or escalate based on evidence.