Kirki CVE-2026-104734

Exploitation requires an authenticated session with access to the plugin's template import AJAX endpoint (includes/Ajax/TemplateExportImport.php → ExportImport/TemplateImport.php deserialization path). The input CVSS encodes PR:H (administrator-level), but the description states that by default Editor-level users are granted FULL_ACCESS via the KIRKI_USERS_DEFAULT_FULL_ACCESS configuration, so Editor privilege is sufficient unless that default is changed. The decisive limiting factor is that Kirki contains NO POP chain of its own: the vulnerability has no security impact unless a separate plugin or theme that provides a usable POP gadget chain is also installed on the target site. No user interaction is needed beyond the attacker's own authenticated request (UI:N). Effective exploitation therefore depends on (a) attacker holding at least Editor role, and (b) a POP-chain-bearing extension being present.

This is a conditional, privilege-gated PHP Object Injection (CWE-502) flaw whose raw CVSS 3.1 base score of 7.2 (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H) overstates immediate real-world risk. Three signals pull the practical priority down: (1) no public exploit identified at time of analysis - no POC provided and the CVE is not in CISA KEV, so there is no confirmed-actively-exploited status; (2) the Wordfence description explicitly states there is NO known POP chain in the vulnerable plugin itself, meaning the bug has NO impact in isolation and only becomes dangerous if a separate plugin or theme supplying a usable POP chain is also installed; and (3) the CVSS vector encodes PR:H (authenticated, high privilege), so an attacker must already hold an elevated WordPress role. Two signals push risk up: the description notes that by default Editor-level users receive FULL_ACCESS to the import endpoint via the KIRKI_USERS_DEFAULT_FULL_ACCESS configuration, so the real authentication bar is Editor rather than Administrator - a conflict with the PR:H assigned in the input vector, which should be flagged to defenders (per CVSS the vector says PR:H/authenticated, but the description implies PR:L/Editor is sufficient in default configuration - verify against the plugin's role mapping). Combined with S:U (no scope change) and the dependency on third-party POP chains, this reads as a high-CVSS but context-dependent issue: a meaningful hardening target on sites that grant Editor access to semi-trusted users AND run POP-chain-bearing plugins, but not a drop-everything emergency absent exploitation evidence. EPSS was not provided in the input and cannot be cited.

An authenticated user with Editor-level access (granted FULL_ACCESS to the import endpoint by default) submits a crafted template-import payload to the plugin's AJAX TemplateExportImport endpoint, where untrusted input is deserialized, instantiating an attacker-controlled PHP object. If another installed plugin or theme provides a usable POP (property-oriented programming) gadget chain, the injected object triggers it during destruction/execution to delete files, read sensitive data, or run code. No public exploit code was identified at time of analysis, and the attack is inert on a site that has no POP chain available.