CVE-2026-110514 in Portfolio Lite Plugin
Summary
by MITRE • 10/21/2026
The WPZOOM Portfolio Lite WordPress plugin before 1.4.34 does not check that a user is allowed to edit a post before changing its type and order, which could allow users with the contributor role and above to convert any other user's posts and pages into portfolio items, removing them from their original listings and URLs.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in WPZOOM Portfolio Lite versions prior to 1.4.34 represents a critical failure in access control logic within the WordPress plugin ecosystem. This flaw stems directly from an insufficient verification of user permissions during state-changing operations, specifically when modifying post types and ordering parameters. The core technical issue lies in the absence of proper authorization checks before executing database updates that alter the structural classification of content objects. In standard web application security principles, this is classified as a Broken Access Control vulnerability, aligning with CWE-284 which describes improper access control where an actor can act outside their intended permissions. The plugin fails to validate whether the authenticated user initiating the request possesses the specific capability required to modify the target post's type and order attributes relative to its ownership or existing role assignments.
From a technical perspective, the vulnerability allows any authenticated user with at least the contributor role in WordPress to manipulate posts belonging to other users. In the default WordPress permission model, contributors can create their own posts but cannot edit others without elevated privileges such as those held by authors, editors, or administrators. However, due to this specific flaw, the plugin does not cross-reference the current user's ID with the post author ID before processing the request to change a standard post into a portfolio item. This lack of object-level permission checking enables an attacker to bypass intended restrictions and perform actions that should be reserved for higher-privileged roles or content owners. The attack vector typically involves crafting a specific HTTP POST request containing parameters that dictate the new post type as portfolio-related, thereby exploiting the server-side logic gap without requiring any additional authentication tokens beyond valid session cookies.
The operational impact of this vulnerability is significant in terms of data integrity and user experience disruption within WordPress environments running affected versions. By converting other users' posts and pages into portfolio items, attackers effectively remove these content pieces from their original listings, archives, and standard URLs. This action disrupts the intended navigation structure of the website, potentially causing broken links for visitors and obscuring critical information that was previously accessible through standard post categories or tags. Furthermore, this manipulation can be used to deface websites by hiding legitimate content while promoting attacker-controlled portfolio items, leading to a degradation of trust in the platform's reliability. For site administrators, this represents a risk where lower-privileged users can exert disproportionate influence over site structure and content visibility, undermining the principle of least privilege that is fundamental to secure system design.
This vulnerability also maps closely to MITRE ATT&CK techniques related to lateral movement or persistence within web applications, specifically those involving unauthorized modification of application state. It highlights a common pattern in plugin development where developers focus on functional requirements while neglecting robust authorization checks for every mutable endpoint. To mitigate this risk, site administrators should immediately update the WPZOOM Portfolio Lite plugin to version 1.4.34 or later, which includes patches addressing these access control deficiencies. Additionally, implementing strict role-based access controls and regularly auditing plugins for proper permission validation can prevent similar issues. Security best practices dictate that all state-changing operations must verify both user authentication and authorization against the specific resource being modified, ensuring that users cannot interact with objects they do not own or have explicit permission to edit.