Guide · Vulnerabilities
Read a vulnerability alert without panicking
A high score describes technical severity. It does not prove that your site runs the affected version, that the vulnerable feature is exposed or that exploitation succeeded.
Short answer
What should you verify when a vulnerability alert arrives?
First verify the exact product, affected version range, advisory source and CVE identifier. Then confirm whether the component exists on your site, is active and exposes the vulnerable feature.
Priority rises when the issue is exploited in the wild, reachable from the Internet, easy to trigger and capable of affecting important data or access. Back up, prepare a rollback, fix, then verify the outcome.
Six parts of a useful alert
Look for
- Product the exact plugin, theme, server or library name.
- Affected versions a precise range, not merely “older versions.”
- Identifier often a CVE number that lets you compare sources without mixing up issues.
- Conditions required authentication, enabled feature, role or network access.
- Impact reading, changing, disrupting, bypassing access or executing code.
- Remedy fixed version, temporary mitigation and vendor instructions.
A sales email or screenshot without these details is a signal to verify, not enough evidence to intervene.
CVSS describes technical severity
CVSS provides a shared way to describe the technical characteristics of a vulnerability. Its Base score does not know your website, data, compensating controls or the component’s value to your operations.
Two issues with the same score can therefore deserve different priorities. A medium issue reachable without an account on a public component may come before a critical issue in a module that is absent or disabled.
Worth remembering
Use the score as structured input, never as an automatic countdown.
Known exploitation changes priority
CISA’s KEV Catalog lists vulnerabilities known to be exploited in the wild. A matching CVE in the catalog is a strong signal: if the product and version match your environment, shorten the decision window.
Absence from the catalog does not make an issue harmless. It only means this particular signal has not been established by that source.
Technical detail
Public evidence of exploitation is not evidence that your site was compromised. When exposure is plausible, remediation and investigation are separate tasks.
Bring the alert into your context
-
Presence
is the affected component and version actually installed?
-
Exposure
is the vulnerable feature reachable from the Internet or only after authentication?
-
Privileges
does exploitation require an account, and with which role?
-
Business impact
which data, operations or people could be affected?
-
Compensation
can a rule, disablement or segmentation temporarily reduce exposure?
Fix without creating a second incident
Before an urgent change, confirm that a restorable backup exists and record the current state. Read the vendor instructions, test when breakage risk warrants it, then apply the fixed version or official mitigation.
After the change
- Verify the version and confirm an older copy is not still loaded elsewhere.
- Test essential functions sign-in, forms, checkout, publishing or other site-specific paths.
- Review evidence logs, new accounts, changed files or abnormal behaviour when exposure warrants it.
- Record the decision source, time, action, validation and accountable person.
Careful
A rushed update without a backup can take the site down. A delay without mitigation can leave active exposure. The plan has to manage both risks.
Shortcuts that waste time
Do not confuse version detection, an applicable vulnerability and a compromise. Do not randomly disable several components “to be safe” when you cannot attribute the result. Do not rely on one score when the vendor advisory describes precise conditions.
Finally, do not keep an abandoned component simply because no recent alert arrived. No advisory does not guarantee no weakness.
Common questions
Does a critical CVSS score mean my site was hacked?
No. The score describes technical characteristics. You still need to confirm the product, version and exposure, then look for evidence when exploitation is plausible.
Can I wait when no exploitation is known?
That signal matters, but it does not decide alone. An easily reached flaw in a sensitive function may still be urgent. Document the delay and any compensating control.
Is disabling a plugin enough?
Sometimes as a temporary mitigation, if it is truly no longer loaded and the site remains stable. Follow the vendor advisory and plan a durable fix or replacement.
Does the alert really apply to your site?
A focused review can confirm the component, exposure and checks to run before and after remediation.
Have the alert reviewed Read an audit finding