Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain Author-level WordPress account
-
DeliveryInject script into post_title field
-
ExploitPayload stored unsanitized in plugin data
-
ExecutionVisitor types in YMC filter search box
-
ImpactScript executes in victim browser
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 | Storing the payload requires an authenticated account with Author-level capability or higher on the target WordPress site, and the YMC Smart Filter plugin (≤3.12.19) must be installed and active. Triggering the stored payload requires NO authentication and NO special configuration: because the autocomplete REST search endpoint (FG_REST_Frontend_Search_Controller) is registered with a permission callback that unconditionally returns true, any visitor - including unauthenticated users - executes the script merely by typing into the YMC filter search box on a page that surfaces the injected post_title. The primary limiting factor is the Author-level write prerequisite, which restricts who can plant the payload; sites that do not grant untrusted users Author access are substantially less exposed. |
| Impact | This is a moderate-priority, not high-urgency issue. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N, base 6.4) reflects a network-reachable, low-complexity stored XSS where storing the payload requires authenticated Author-level privileges (PR:L) and a scope change (S:C) because the script executes in other users' browser contexts. The notable aggravating factor from the description is that the autocomplete REST endpoint uses a permission callback that unconditionally returns true, so any unauthenticated visitor can TRIGGER the stored payload by using the filter search box - the authentication barrier applies only to planting the payload, not to firing it. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so this is 'no public exploit identified at time of analysis.' The Author-level prerequisite meaningfully limits the attacker population to users who already have content-creation trust on the site, which is why real-world risk is lower than the CVSS might suggest for a self-hosted single-author blog, but higher for multi-author or membership sites where Author accounts are granted liberally. Impacts are limited (C:L/I:L, A:N) - consistent with typical XSS session/credential and content-manipulation effects rather than full compromise. Overall: a real, patchable vulnerability worth remediating, but it is privilege-gated and shows no evidence of active or automated exploitation. |
| Exploit ScenarioDerived | On a multi-author WordPress site, an attacker with an Author account edits a post and injects a malicious script into the post_title field, which the plugin stores without sanitization. Later, any site visitor - including unauthenticated ones - types into the YMC filter search box, the autocomplete REST endpoint (open to everyone via its always-true permission callback) returns the unescaped title, and the DOM-based script executes in the victim's browser. No public exploit code is identified in the provided data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 17, 2026
Stored DOM-based cross-site scripting in the YMC Smart Filter plugin for WordPress (all versions through 3.12.19) allows a user with Author-level access or higher to plant script inside a post title that is later rendered unsafely by the plugin's front-end search widget, executing in the browser of anyone who views the injected page or types into the filter search box. The autocomplete REST search endpoint registers a permission callback that unconditionally returns true, so triggering the payload requires no authentication whatsoever, while only Author-level capability is needed to store it; this mismatch is reflected in the CVSS scope change (S:C) and the PR:L rating. Impact is limited to client-side script execution in the visitor's session (C:L/I:L/A:N); no public exploit code or confirmed active exploitation was identified at time of analysis, and the primary exposure limiter is whether a site hands Author accounts to untrusted users.
RemediationAI
Upgrade the YMC Smart Filter plugin to version 3.12.20 or later, which contains the changed REST front-end search controller referenced in the advisory; verify the deployed version under Plugins in wp-admin after updating, since the fix is delivered as a plugin update rather than a core change. Because the write prerequisite is an Author-level account, immediately audit who holds Author, Editor and Administrator roles and remove or downgrade any untrusted or stale accounts - this does not remove already-stored payloads but prevents new ones and is the highest-leverage compensating control where patching must be scheduled. Review existing post titles for injected markup (search the posts table for '<script', 'onerror=', 'onload=' and similar patterns) and clean any hits, since the payload persists in the database until the underlying post is edited. If the plugin cannot be updated promptly, deactivate it - trading away the filter/search user experience - or restrict the REST autocomplete route at the web server or WAF (block /wp-json/ requests hitting the plugin's front-end search namespace and the equivalent ?rest_route= query form) for unauthenticated clients, accepting that this degrades the autocomplete feature; note that blocking all /wp-json/ traffic can break other plugins and the block editor. Deploying a Content-Security-Policy that disallows inline script reduces successful execution of any residual stored payload, at the cost of possible breakage of other inline-script-dependent plugin features.
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
The root cause is CWE-79 (improper neutralization of input during web page generation), specifically the stored/DOM variant: the 'post_title' value is persisted without adequate sanitization on input and is written into the DOM by the plugin's front-end JavaScript (ymc2/assets/js/frontend/ymc-public.min.js) without output escaping, so the browser parses attacker-controlled markup as script rather than text. The vulnerable data path is the plugin's REST layer: FG_REST_Frontend_Search_Controller::... (line ~135-148 in the 3.12.19 tag) handles the autocomplete search request, and the shared abstract controller FG_REST_Abstract_Controller (line ~66) registers route permissions in a way that yields an always-true permission callback for this endpoint. That design means the search route is publicly reachable via the WordPress REST API (/wp-json/...) with no nonce or capability check, so an unauthenticated visitor's keystrokes in the YMC filter search box are enough to cause the stored markup to be re-rendered and executed. Because the sink is client-side, classic server-side output filtering and content-security-policy configuration are the relevant secondary defenses; the underlying WordPress capability model (Author can create and publish own posts, including titles) is what makes the write step possible without administrative rights.
Know when Ymc Filter 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:L/UI:N/S:C/C:L/I:L/A:N
Author-level write access is required to store the payload (PR:L); the open REST trigger needs no victim interaction (UI:N); execution in other users' browser context is a scope change (S:C) with limited confidentiality/integrity impact.
Primary rating from Vendor (Wordfence).
CVSS VectorVendor: Wordfence
DescriptionCVE.org
The YMC Filter plugin for WordPress is vulnerable to Stored DOM-Based Cross-Site Scripting via the 'post_title' parameter in all versions up to, and including, 3.12.19 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The autocomplete REST endpoint is registered with a permission callback that unconditionally returns true, meaning any site visitor - including unauthenticated users - can trigger the payload simply by typing in the YMC filter search box, while only Author-level access is required to store it.
Threat Intelligence Overview
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.
More in Ymc Filter
View allSQL injection in the YMC Filter (YMC Smart Filter / Filter Grids) WordPress plugin lets remote attackers inject maliciou
Information disclosure in the YMC Filter WordPress plugin before 3.11.3 lets unauthenticated remote attackers read the t
Stored cross-site scripting in the YMC Filter WordPress plugin (all versions before 3.12.9) allows Author-role users to
Stored cross-site scripting in the YMC Filter WordPress plugin (versions 3.6.0 through 3.12.7) enables any Contributor-l
EUVD-2026-103276
GHSA-r26w-hjm4-pvpr
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB