CVE-2026-84225 in Kirki Plugin
Summary
by MITRE • 09/05/2026
The Kirki WordPress plugin before 6.3.0 does not check that a user is allowed to act on a collaboration comment before changing its state, allowing users whom an administrator has granted content-level access to the page builder to modify comments left by other users, including on pages they cannot themselves open.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/05/2026
The vulnerability identified in Kirki versions prior to 6.3.0 represents a critical failure in server-side authorization logic within a widely used WordPress plugin designed for theme customization and visual editing. This flaw specifically targets the mechanism that handles collaboration comments, which are annotations left by users on specific elements of a page being edited via the builder interface. The core technical deficiency lies in the absence of proper access control checks when processing requests to modify or change the state of these comments. Instead of verifying whether the authenticated user possesses the necessary permissions relative to both the comment itself and the underlying content it references, the application blindly accepts administrative-level actions from users with significantly lower privilege levels. This lack of validation allows any user granted basic content editing capabilities to manipulate metadata associated with other users' contributions without restriction.
From a technical perspective, this issue is classified under CWE-862, which denotes Missing Authorization, and more specifically aligns with CWE-915 regarding Improper Control of Dynamically-Managed Code Resources if the comment state affects system behavior or visibility. In the context of the MITRE ATT&CK framework for enterprise security, this vulnerability facilitates lateral movement within a compromised web application environment by allowing lower-privileged accounts to perform actions typically reserved for administrators or higher-tier editors. The attacker exploits an insecure direct object reference pattern where the identifier for the comment is passed and acted upon without verifying that the current session has ownership or explicit permission over that specific resource. This bypasses the intended security boundary, effectively elevating the functional capabilities of a standard contributor to those capable of altering collaborative workflows and potentially disrupting team coordination on sensitive pages.
The operational impact of this vulnerability extends beyond simple data modification; it undermines the integrity of the collaboration workflow inherent in modern page builders. Users with content-level access can alter comments left by administrators or other high-privilege users, including modifying notes on pages that are restricted and inaccessible to them through normal browsing means. This capability allows an attacker to obscure malicious changes made elsewhere, confuse team members regarding design decisions, or delete critical feedback intended for review before publication. In a multi-user environment such as a corporate website managed by multiple contributors, this lack of isolation between user roles can lead to significant confusion and potential security incidents where unauthorized modifications are disguised as collaborative edits.
Mitigation strategies must prioritize immediate patching to version 6.3.0 or later, which addresses the authorization checks within the comment handling routines. For organizations unable to update immediately due to compatibility constraints with other plugins, implementing a Web Application Firewall rule that restricts access to the specific API endpoints responsible for updating collaboration comments can provide temporary relief. Additionally, administrators should review user roles and ensure that only trusted individuals are granted content-level editing privileges on sensitive pages. Long-term remediation involves enforcing strict role-based access control principles where every action is validated against both the resource identity and the user's permission set before execution, ensuring that privilege escalation through API manipulation is prevented at the application logic layer rather than relying solely on frontend restrictions or client-side checks.