CVE-2026-14433

The CVSS 7.2 rating for this stored XSS in the business_id parameter is technically accurate but practically misleading. This is an unauthenticated vulnerability in a plugin that manages real commercial relationships — bookings, customer interactions, and business profiles — meaning the attack surface extends well beyond a single page view. The key distinction is propagation, not just persistence. A stored XSS in business_id doesn't just sit waiting for someone to visit a profile page — it injects into a workflow where that identifier flows through admin dashboards reviewing bookings, business profile displays, and potentially customer-facing confirmation emails. One injection point reaches multiple trust boundaries simultaneously. The CVSS score treats this as a single-context vulnerability because that's what the scoring model measures, but in a booking system, the same business_id value renders in contexts with radically different privilege levels. The 'business_id' parameter represents exactly the kind of field developers treat as a trusted reference token — 'it's just an ID, it won't contain user content.' That categorical assumption is the root cause. When that assumption fails in a commercial plugin, the blast radius is measured not by exploit sophistication but by how many downstream systems consume that identifier unsanitized. Two non-obvious remediation gaps warrant attention. First, the fix in version 4.6.1 addresses output escaping at render time, but any business_id values injected during the vulnerable window persist in the database as trusted. If the patch doesn't include data re-sanitization, poisoned records continue circulating in active installations. Second, the plugin ecosystem's churn means some sites running 4.6.0 are abandoned — no longer actively maintained but still serving stale booking data to crawlers and cached pages. The exposure doesn't end when exploitation becomes inconvenient. Prioritize: confirm whether the 4.6.1 patch includes database sanitization for existing records, audit booking workflows for all render contexts (admin, customer-facing, email), and treat any business_id values created during the vulnerable window as potentially untrusted until proven otherwise.

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