EUVD-2026-96777
GHSA-62f8-22fh-vpq2
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSend unauthenticated POST to settings endpoint
-
DeliveryStore unescaped JavaScript in plugin settings
-
ExploitAdmin opens settings page or visitor loads output
-
ExecutionScript executes in victim browser
-
ImpactHijack admin session / create rogue admin
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Output encoding, context-aware escaping
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | The plugin's settings-save routine in KeyWord Collector through version 1.4 performs no authorization check and no nonce/CSRF validation, so an unauthenticated attacker can POST arbitrary values to it directly against a default installation; the stored values are then output without escaping. The specific limiting factor is user interaction (UI:R): the injected JavaScript only executes when a logged-in administrator subsequently opens the KeyWord Collector settings page, or when any site visitor loads a front-end page that renders the plugin's output. No authentication, special plugin configuration, or non-default setting is required - only that the plugin is installed and the poisoned page is later viewed. |
| Impact | This is a genuinely actionable issue, not merely a high-CVSS paper risk. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R) describes a network-reachable, low-complexity, unauthenticated flaw, and the missing authorization/nonce check means an attacker can write the stored payload with no account - a true pre-auth broken-access-control bug that collapses into stored XSS (CWE-79). The strongest escalating signal is that public exploit code exists (WPScan). Mitigating signals: exploitation still requires user interaction (UI:R) - the stored script only fires when an administrator opens the settings page or a visitor loads the output-bearing page - so it is not fully autonomous. No EPSS score was provided and the CVE is NOT in CISA KEV, so there is no evidence of active in-the-wild exploitation; current status is publicly available exploit code only. One conflict to flag explicitly: the published impact metrics C:H/I:H/A:H are aggressive for a stored-XSS bug - standard FIRST guidance maps reflected/stored XSS to a scope change with Low impacts (C:L/I:L/A:N). The 8.8 likely reflects the realistic worst case that admin-context JavaScript can create rogue administrators and fully take over the site; defenders should treat impact as potential-full-compromise but understand the raw triple-High is an upper bound, not a measured outcome. |
| Exploit ScenarioDerived | An unauthenticated attacker sends a crafted POST request directly to the plugin's unprotected settings-save handler, injecting a malicious JavaScript payload into a stored setting. When a logged-in administrator later opens the KeyWord Collector settings page (or any visitor loads a front-end page rendering the unescaped output), the script executes in their browser session, enabling admin session/cookie theft or creation of a rogue administrator for full site takeover. Public exploit code for this flaw is available via WPScan. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 11, 2026
Stored cross-site scripting in the WordPress plugin KeyWord Collector through version 1.4 allows an unauthenticated remote attacker to POST arbitrary values directly to the plugin's settings-save routine, which enforces neither a capability/authorization check nor a nonce (CSRF) check, and the stored values are then rendered without output escaping. The injected JavaScript executes when a logged-in administrator later opens the plugin settings page, or when any site visitor loads a front-end page that displays the plugin's output; publicly available exploit code exists for this issue. Our independent assessment scores the flaw 6.1 under CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, which is more conservative than the 8.8 figure circulated elsewhere: exploitation is unauthenticated and requires no non-default configuration, but it is constrained by user interaction (UI:R) and the demonstrated consequence is script execution in a victim's browser session rather than direct server-side compromise.
RemediationAI
No vendor-released patch with a specific fixed version was identified in the available data, and the plugin's CPE lacks a resolvable vendor namespace, so there is no upstream release to upgrade to as of this analysis - the primary action is to deactivate and uninstall KeyWord Collector, or at minimum remove it from any site where the settings page and front-end output are reachable, and to audit wp_options for injected script content left behind by prior exploitation. If the plugin cannot be removed, compensating controls in descending order of effectiveness are: block unauthenticated POST requests to the plugin's settings-save endpoint at the web server or WAF (this stops new injection but does nothing about already-stored payloads, so it must be paired with a cleanup pass); restrict access to the plugin's settings page and to /wp-admin via IP allowlisting or an authentication proxy, which prevents the administrative trigger path but adds administrative friction and does not protect front-end visitors if the plugin renders output publicly; and enable a restrictive Content-Security-Policy on front-end and admin pages to blunt inline script execution, which is a partial mitigation that frequently breaks other plugins and admin UI. Because the injected data is stored, wiping the affected option rows after applying a block is mandatory - filtering only inbound requests leaves previously planted payloads live. Consult https://wpscan.com/vulnerability/93503140-af69-4734-bf65-bc781b761c47/ and https://vuldb.com/vuln/416530 for any vendor update, and re-check for a patched plugin version before reintroducing it.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
KeyWord Collector is a WordPress plugin (CPE cpe:2.3:a:unknown:keyword_collector:*:*:*:*:*:*:*:* - no validated vendor namespace is published, and EUVD lists all 0 through 1.4 builds as affected) that stores administrator-supplied keywords and displays them on the site. The root cause class is CWE-79 (Improper Neutralization of Input During Web Page Generation), compounded by a missing authorization/CSRF control on the settings-write path: the routine that persists configuration accepts requests without verifying a WordPress capability such as manage_options and without validating a nonce, so the state-changing save endpoint is reachable by an unauthenticated party. Because the persisted values are echoed back into the settings page and into front-end output without HTML/attribute encoding, the plugin effectively provides a persistent (stored) injection sink. WordPress's admin-ajax/admin-post patterns are the typical reachable surface for this kind of flaw, and stored XSS in an administrative page is disproportionately dangerous because it executes in the context of a logged-in admin with a valid session and, on many sites, an unexpired auth cookie. The applied CVSS vector confirms unauthenticated reachability (PR:N) and privileges-required is not a barrier, while scope change (S:C) in the assessed vector and the UI:R requirement reflect that the payload must be viewed by an administrator or a site visitor before it fires.
Know when Keyword Collector gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Pre-auth network injection (PR:N, AV:N, AC:L) requiring a victim to load the payload (UI:R); per standard XSS mapping, scope changes (S:C) with Low C/I and no availability impact.
Primary rating from Vendor (WPScan).
CVSS VectorVendor: WPScan
Lifecycle Timeline
3DescriptionCVE.org
The KeyWord Collector WordPress plugin through 1.4 does not have any authorisation or nonce check when saving its settings, and does not escape them before output, allowing unauthenticated attackers to store malicious JavaScript that executes when an administrator opens the KeyWord Collector WordPress plugin through 1.4's settings page or when a visitor loads a page displaying its output.
Technical POC Analysis
CWE-79 (Improper Neutralization of Input During Web Page Generation), stored variant.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Organizations running the KeyWord Collector WordPress plugin at version 1.4 or earlier face a stored cross-site scripting risk that can compromise administrator browser sessions and expose site visitors to malicious script execution. Because exploitation is unauthenticated and publicly available exploit code exists, site integrity, visitor trust, and potentially sensitive administrative data are at risk until the plugin is removed or mitigated. Leadership should prioritize remediation because no vendor-released patch has been identified at time of analysis.
No vendor-released patch identified at time of analysis; interim mitigations include deactivating or removing KeyWord Collector through version 1.4, restricting access to the plugin settings page, blocking unauthenticated POSTs to the settings-save routine via WAF or virtual patching, disabling front-end display of plugin output, enforcing MFA and least privilege for administrators, applying Content Security Policy, and monitoring for stored script payloads or suspicious admin activity.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.
Exploit-DB