Kirki WordPress Plugin EUVD-2026-113951

Requires an authenticated WordPress user whose role holds Kirki edit access - granted to the Editor role by default - on a site running Kirki plugin before 6.4.1 with its page REST API (PUT /wp-json/kirki/v1/pages/{page_id} and the save_page_data, duplicate, and delete handlers in PageController.php) reachable. No user interaction and no non-default configuration are needed because Editors receive the access out of the box. The limiting factor is the authentication barrier: the attacker must already hold an Editor-level (or equivalently Kirki-authorized) account, so this is not anonymously exploitable; the required privilege is the only effective constraint beyond having the vulnerable version installed. Updating to 6.4.1 removes the flaw.

This is a genuine but moderate-priority issue rather than an inflated high-CVSS finding. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 7.2 (High) and is network-reachable with low complexity, but PR:L is the decisive limiter: exploitation requires an authenticated account that has been granted Kirki edit access, which the description says is the Editor role by default - not an anonymous remote attacker. The dominant impact is integrity (VI:H): an Editor can alter title, slug, and publication status of any post, post type, or WooCommerce product they do not own; confidentiality (VC:L) and availability (VA:L) are secondary, covering exposure of private/draft content and removal of published content. The vuln.today Decision label is 'this_week', consistent with a real but non-emergency fix window. No CISA KEV listing is present, no EPSS probability was supplied, and there is no confirmed working exploit code - so there is no evidence of active or widespread exploitation. The missing EPSS score means automated exploitation likelihood cannot be weighed; treat the this_week label plus Editor-privilege requirement as the governing signals. Net: a real authorization flaw worth patching this week, most relevant on multi-author, membership, or WooCommerce sites where many semi-trusted users hold the Editor role.

An attacker holding a WordPress Editor account (or any role granted Kirki edit access) on a site running Kirki before 6.4.1 sends a crafted PUT request to /wp-json/kirki/v1/pages/{page_id} referencing a post they do not own. Because the handler enforces only a coarse role-to-access middleware check and no per-object capability check, the attacker rewrites the unrestricted post_status to publish a private/draft post (exposing content) or unpublish/alter published posts, custom post types, or WooCommerce products. No public exploit code is identified at time of analysis; a VulnCheck advisory documents the flaw, and AV:N/AC:L make the network request itself trivial once authenticated.