Start here
Before You Fix It: What This Check Means
CMS fingerprint shifts often indicate platform/version drift that can impact security and routing. In plain terms, this checks which CMS or hosting signals are publicly exposed and whether they look worth reviewing. Scavo derives a domain from the scanned URL and inspects HTML/headers for CMS/platform clues.
Why this matters in practice: operational drift here often causes hard-to-debug regressions across environments.
How to use this result: treat this as directional evidence, not final truth. This result reflects what was observable at scan time and should be verified in your own production context. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Compare detected slug/version to expected deployment state. Finally, re-scan the same URL to confirm the result improves.
Background sources
TL;DR: Your CMS version (WordPress, etc.) or server version is visible in HTTP headers or meta tags, helping attackers target known vulnerabilities.
When attackers can see you're running WordPress 6.3 or Apache 2.4.51, they can check public CVE databases for known exploits specific to your exact version. Removing version disclosure is simple server hardening — it doesn't fix vulnerabilities, but it removes the signpost that tells attackers exactly where to look.
What Scavo checks (plain English)
Scavo derives a domain from the scanned URL and inspects HTML/headers for CMS/platform clues.
Current behavior includes:
- WordPress indicators (
/wp-content/,/wp-includes/,wp-json, generator tags) - WordPress version extraction where visible (including
/wp-jsonfallback) - hosting platform hints from headers (for example Vercel, Netlify, Shopify, Cloudflare)
- baseline comparison against previous CMS slug/version in monitor state
How outcomes are assigned:
Warning: domain detection skipped or CMS slug changed from prior baselinePass: WordPress detected with visible versionInfo: WordPress detected but version hiddenInfo: non-WordPress/platform fingerprint detectedInfo: no known CMS fingerprint detected
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for cms_fingerprint, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
cms_fingerprint - Category:
TECHNICAL
Why fixing this matters
Unexpected stack identity changes can indicate misrouting, migration mistakes, or unauthorized infrastructure edits.
Even planned changes should be tracked: fingerprint drift with no change record is where incidents often start.
If you are not technical
- Confirm whether detected CMS/platform matches your intended stack.
- If changed unexpectedly, escalate immediately.
- Ask for update/patch posture summary for detected platform.
- Re-run Scavo once the cause is documented or fixed.
Technical handoff message
Copy and share this with your developer.
Scavo flagged CMS fingerprint (cms_fingerprint). Please verify detected CMS/platform against approved architecture, investigate unexpected fingerprint changes, and confirm update/patch posture. Share findings and re-run the scan.If you are technical
- Compare detected slug/version to expected deployment state.
- Correlate changes with release logs, DNS/CDN routing updates, and infra commits.
- Validate WordPress patch posture when WordPress is detected.
- Keep platform baseline in monitoring docs for quick incident triage.
- Treat unexplained slug change as potentially high priority.
How to verify
- Review Scavo details for current vs previous slug/version.
- Confirm header/platform hints match production design.
- Validate change-ticket record if migration was intentional.
- Re-run Scavo and confirm stable expected fingerprint.
What this scan cannot confirm
- It does not perform full vulnerability scanning.
- It cannot enumerate all hidden internal components.
- Obfuscation can reduce fingerprint confidence.
Owner checklist
- [ ] Assign owner for platform inventory and drift review.
- [ ] Keep expected CMS/platform baseline documented.
- [ ] Review fingerprint changes in release retros.
- [ ] Re-check after CDN/edge routing changes.
FAQ
Is fingerprint visibility always bad?
No. This check reports detectable identity and change, not automatic risk severity.
Why can this be info even when CMS is detected?
Because detection alone may be expected and stable.
What is the high-alert scenario?
Unexpected CMS slug change with no planned migration record.
Should we hide version info?
Security posture should rely on patching and hardening first; version hiding is not a substitute for updates.
Sources
- OWASP WSTG fingerprinting guidance
- OWASP Automated Threat: Fingerprinting
- WordPress hardening
- WordPress updates
Need a CMS/platform baseline checklist for your runbooks? Send support your expected stack map.
