Kirki EUVD-2026-103213

Exploitation requires the target site to host at least one PUBLISHED page built from a Kirki template that includes a user-type dynamic content block - this specific template/block must be present and live, and is the sole hard prerequisite. When that condition is met, no authentication, privileges, or user interaction are needed (PR:N/UI:N), and target user IDs are freely enumerable through standard WordPress REST endpoints, so the attacker needs no prior knowledge of valid accounts. The limiting factor is entirely the non-default presence of the vulnerable template: sites running Kirki ≤6.3.2 without such a published page containing a user-type dynamic block are not exploitable via this vector. Impact is confined to disclosure of string-valued profile and user-meta fields; no integrity or availability impact.

This is a genuine but bounded priority. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5) is internally consistent with the description: network-reachable, unauthenticated, no user interaction, pure confidentiality impact via an IDOR (CWE-639) in the 'context' parameter. However, several higher-risk signals are ABSENT: no EPSS score was provided, the CVE is not listed in CISA KEV, and no public proof-of-concept is indicated - so there is no public exploit identified at time of analysis. The impact is strictly information disclosure (C:H, I:N, A:N), not code execution or takeover, which tempers real-world severity despite the 'HIGH' rating. A notable tension exists between the AV:N/AC:L framing and the stated prerequisite that the site must already host a published page using a Kirki template containing at least one user-type dynamic content block - this is a non-attacker-controlled deployment condition that NVD's AC:L does not reflect; many installations will not be exploitable at all, so realistic exposure is narrower than the 7.5 suggests. Treat as a medium-priority patch-soon item: trivially exploitable WHERE the vulnerable template is present, but not universally exploitable across all installs.

An unauthenticated attacker enumerates valid user IDs via standard WordPress REST endpoints (e.g. /wp-json/wp/v2/users), then issues a crafted request manipulating the 'context' parameter against a published page built with a Kirki user-type dynamic content block. The REST response discloses targeted users' sensitive profile data (email, display name, nicename, registration date, avatar URL, and string-valued meta such as first/last name and description). No public exploit code is identified, but the technique is straightforward given the enumerable IDs and low attack complexity.