CVE-2026-66443

The EPSS-CVSS divergence in this disclosure exposes a gap in how you should triage WordPress plugin vulnerabilities. A 7.5 severity paired with a 0.00398 exploitation probability suggests this exposure is structurally constrained in ways the CVSS score alone obscures — and you should demand specificity about what 'sensitive data' actually means rather than accepting severity ratings at face value. The most analytically interesting signal here isn't the 7.5. It's the EPSS. A probability of 0.00398 places this well below the threshold where automated exploitation typically becomes a Priority 1 concern, yet the CVSS label says HIGH. That tension deserves scrutiny. CVSS 7.5 in the Confidentiality dimension without matching Availability or Integrity impacts often indicates partial, scoped disclosure rather than catastrophic exposure. What this tells you is that the REST API endpoint is likely returning filtered or contextual data — not a complete database dump — and understanding the exposure scope is essential before treating this as a critical incident. The 'unauthenticated' descriptor is accurate but potentially misleading in isolation. WordPress REST API endpoints are technically accessible to anyone, but whether they return meaningful sensitive data depends entirely on the plugin's internal logic. An unauthenticated endpoint that returns metadata about API logs is a different risk than one exposing authentication tokens or user credentials. You should push back on vague 'sensitive data exposure' classifications and demand the specific data types at risk. The practical question for this vulnerability is whether the exposed logs contain authentication secrets, personally identifiable information, or privileged content — or merely timestamp and endpoint records that constitute 'sensitive' only in a narrow legal sense. That distinction should drive your response urgency far more than the numerical severity score. Beyond triage, consider the development workflow that created this vulnerability. WordPress REST API endpoint registration requires no authentication scaffolding by default. A developer adding a logging feature needs debug data, reaches for `register_rest_route`, and the path of least resistance is public exposure. There's no framework prompt asking 'should anonymous requests receive this data?' The cognitive load during development is on building the feature, not on threat-modeling every data access pattern. The 'unauthenticated' label implies a conscious decision to permit public access, but more likely this was an absence of decision — the developer may have genuinely not considered that log metadata constitutes exposure risk. This vulnerability also fits a broader pattern: WordPress plugins shipping REST API endpoints that expose logging or debug data to unauthenticated users. The fix is formulaic — add a `permission_callback`, gate the endpoint behind capability checks, sanitize response fields — and the vulnerability persists because developers ship debug logging during development, then ship to production because the framework never prompts them to close that gate. What you should check: whether this plugin's logging scope includes request/response bodies that could contain session tokens or payload data from authenticated users, or if the exposure is limited to structural metadata. If it's the latter, this warrants attention but not Priority 1 incident response. If it's the former, the blast radius extends far beyond what EPSS suggests — logs are intelligence reservoirs that reveal application structure, visited URLs exposing admin workflows, error patterns disclosing internal paths, and headers that may contain authentication tokens from authenticated sessions.

Reviewed through automated stages and approved by a human before publication.