Sticky Chat Widget CVE-2026-73187

No special conditions beyond the plugin being installed and active - remote unauthenticated exploitation against default configurations of any WordPress site running Sticky Chat Widget version 1.4.2 or earlier. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms no authentication, no user interaction, and low attack complexity are required. The primary limiting factor is prevalence: the plugin must be present and active, which narrows the exploitable population to sites that have specifically installed this niche chat widget; the attacker must also have network reachability to the vulnerable front-end endpoint.

The signals point to a genuinely high-priority issue for anyone running the plugin: the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) confirms remote, low-complexity, unauthenticated exploitation with no user interaction, and CWE-89 with C:H means full database read exposure. However, several tempering factors apply - there is no EPSS score provided, no KEV listing, and no public POC identified, so exploitation is theoretical rather than observed at this time. One notable inconsistency is that the reported base vector sets I:N and A:L despite this being SQL injection: injection flaws often permit writes or blind time-based extraction, so the integrity impact may be understated while the low availability score is loosely justified; the confidentiality impact (C:H) is the dominant and well-supported risk. Real-world risk is ultimately gated by deployment footprint, which for this niche plugin is limited, so this is a high-severity flaw on a low-prevalence product rather than a mass-exploitation event.

An attacker identifies a target WordPress site running Sticky Chat Widget ≤1.4.2 and sends a single crafted HTTP request to the plugin's vulnerable endpoint with a malicious SQL payload in a chat/widget parameter. Because no authentication or user interaction is required (AV:N/PR:N/UI:N), the injected query executes against the WordPress database, letting the attacker extract administrator password hashes, session tokens, or secret keys. No public POC is identified at time of analysis, so exploitation would require the attacker to independently reverse-engineer the vulnerable parameter.