CVE-2026-77016 in Workeera Plugin
Summary
by MITRE • 08/27/2026
The Workeera WordPress plugin before 1.0.6 does not restrict which values may be written to a user's own candidate profile, and does not validate or contain the stored file path before deleting it, allowing users with a role as low as subscriber to delete arbitrary files on the server.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in Workeera WordPress plugin versions prior to 1.0.6 represents a critical security flaw rooted in insufficient input validation and improper access control mechanisms within the user profile management functionality. This issue specifically affects how the plugin handles file path operations during the deletion process for candidate profiles. The core technical deficiency lies in the application's failure to restrict which values can be written to or manipulated by users with low-privilege roles, such as subscribers. In a secure system architecture, even basic user roles should have their actions sandboxed to prevent any interaction with server-side file systems that could lead to unintended consequences. The plugin fails to implement adequate boundary checks on the input fields associated with candidate profile data, allowing an attacker to inject arbitrary path strings into the application logic without proper sanitization or validation.
From a technical perspective, this flaw enables what is classified as an Arbitrary File Deletion vulnerability. When the user attempts to delete their own candidate profile information, the backend script processes the provided file paths for deletion but does not verify that these paths are confined to expected directories or safe locations on the server's filesystem. By manipulating the input data, a malicious actor can traverse directory structures using standard path traversal sequences such as dot-dot-slash characters. This allows them to specify files located outside of the intended plugin storage areas, potentially targeting critical system configuration files, database credentials stored in plain text within other plugins or themes, or core WordPress installation files. The lack of validation on the stored file path before executing the deletion command means that any valid absolute or relative path provided by the user is processed directly by the operating system's file removal routines.
The operational impact of this vulnerability is severe and can lead to complete compromise of the web server environment. An attacker with a subscriber-level account, which requires no authentication beyond basic registration in many WordPress setups if open registration is enabled, or even authenticated low-privilege users on closed sites, can systematically delete essential files. The destruction of critical configuration files such as wp-config.php would render the website inaccessible and expose sensitive database connection details to any user who might view source code or error logs. Furthermore, deleting theme files or plugin assets can cause a denial of service by breaking the site's frontend functionality. In more sophisticated attack scenarios, this file deletion capability could be used in conjunction with other vulnerabilities, such as arbitrary file upload flaws, to facilitate remote code execution. By removing security-related files like .htaccess rules that restrict access to sensitive directories, an attacker can further expose internal application logic and data stores to public access.
This vulnerability aligns closely with Common Weakness Enumeration (CWE) identifiers including CWE-22 for Improper Limitation of a Pathname to a Restricted Directory, which describes the failure to validate input against expected directory boundaries, and CWE-732 for Incorrect Permission Assignment for Critical Resource, reflecting the overly permissive access controls that allow low-privilege users to perform destructive file operations. In terms of the MITRE ATT&CK framework, this behavior corresponds to techniques under the Impact tactic, specifically T1485 Data Destruction or T1070 Indicator Removal on Host, as the attacker is actively removing artifacts and critical components from the host system to disrupt service or hide tracks after exploitation. The attack vector is classified as Local due to the requirement of having an account with at least subscriber privileges, though in many WordPress deployments this represents a significant risk given that registration can be open by default.
Mitigation strategies for this vulnerability require immediate action by both plugin developers and site administrators. For users currently running Workeera versions earlier than 1.0.6, the primary remediation step is to upgrade to version 1.0.6 or later where these input validation checks have been implemented. Developers must ensure that all file path inputs are strictly validated against a whitelist of allowed directories and characters before being passed to system-level deletion functions. Implementing canonicalization techniques to resolve symbolic links and relative paths can help prevent directory traversal attacks. Additionally, applying the principle of least privilege is essential; user roles should be configured so that only administrators or users with specific elevated permissions are granted access to profile management features involving file operations. Server-side hardening measures such as restricting write permissions on critical directories via proper filesystem ownership settings and using open_basedir directives in PHP configurations can provide an additional layer of defense, limiting the blast radius even if application-level validation fails. Regular security audits and code reviews focusing on input handling for file system interactions are recommended to prevent similar flaws from being introduced in future updates or other plugins.