The nmedia Frontend File Manager Plugin for WordPress suffers from an authorization bypass vulnerability classified as CWE-639 (Authorization Bypass Through User-Controlled Key). This vulnerability exists in all versions up to and including 23.4 due to the plugin's failure to verify file ownership before processing file rename requests via the REST API endpoint '/wpfm/v1/file-rename'. Specifically, the plugin accepts a 'fileid' parameter that identifies the target file to rename but does not confirm whether the authenticated user owns or has permission to modify that file. As a result, any authenticated user with Subscriber-level privileges or higher can rename files uploaded by other users. The vulnerability is exploitable remotely over the network without user interaction, requiring only valid authentication credentials. The impact is limited to integrity, as attackers can alter file names, potentially causing confusion, mismanagement, or indirect disruption of workflows. Confidentiality and availability are not directly affected. The CVSS v3.1 base score is 4.3 (medium), reflecting the low complexity of attack and limited impact scope. No patches or official fixes are currently linked, and no known exploits have been reported in the wild. This vulnerability highlights the importance of proper access control and ownership validation in multi-user file management systems within WordPress plugins.

This vulnerability allows authenticated users with minimal privileges (Subscriber-level or higher) to rename files uploaded by other users, compromising the integrity of file data within affected WordPress sites. While it does not expose file contents or cause denial of service, unauthorized renaming can disrupt content management, cause confusion among users, and potentially facilitate further social engineering or privilege escalation attacks if combined with other vulnerabilities. Organizations relying on the Frontend File Manager Plugin for collaborative content management face risks of internal sabotage or accidental misconfiguration. The impact is more pronounced in environments with multiple users uploading and managing files, such as educational institutions, media companies, or large enterprises using WordPress for content collaboration. Since the attack requires authentication, the risk is limited to insiders or compromised accounts, but the low privilege requirement broadens the potential attacker base. The absence of known exploits reduces immediate threat but does not eliminate risk, especially as attackers may develop exploits once the vulnerability becomes widely known.

To mitigate this vulnerability, organizations should: 1) Immediately restrict user roles and permissions to the minimum necessary, especially limiting Subscriber-level users from accessing file management features if possible. 2) Monitor and audit file rename activities within the plugin to detect unauthorized changes. 3) Apply any forthcoming patches or updates from the plugin vendor promptly once available. 4) If patches are not yet available, consider temporarily disabling the Frontend File Manager Plugin or restricting access to the '/wpfm/v1/file-rename' REST API endpoint via web application firewall (WAF) rules or custom code to enforce ownership validation. 5) Implement additional access control checks at the WordPress level or via custom plugins to verify file ownership before allowing rename operations. 6) Educate users about the risks of sharing credentials and enforce strong authentication policies to reduce the risk of account compromise. 7) Regularly back up files and site data to enable recovery from unauthorized modifications. These steps go beyond generic advice by focusing on role restriction, monitoring, and temporary technical controls until an official patch is released.