CVE-2026-107770 in Photo Engine Plugin
Summary
by MITRE • 10/16/2026
The Photo Engine (Media Organizer & Lightroom) plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 6.5.6 This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to permanently delete arbitrary media attachments via wp_delete_attachment and upload new attachments to the site, actions that require the upload_files or edit_others_posts capabilities. A Subscriber-level user can obtain their own wplr_auth_token directly from the profile.php page source, because the admin screen guard in Meow_WPLR_Sync_Admin::__construct() is commented out, causing wp_localize_script to leak the token into every admin page view; this token can then be used from a cookie-less HTTP session to invoke destructive actions on the /?wplr-sync-api endpoint.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The Photo Engine plugin for WordPress, which serves as a media organizer and integration tool with Adobe Lightroom, contains a critical authorization bypass vulnerability affecting all versions up to 6.5.6. This flaw stems from an improper verification of user privileges when handling administrative actions within the application logic. Specifically, the code fails to enforce necessary capability checks before executing sensitive operations, allowing unauthenticated or low-privileged users to perform tasks that should be restricted to administrators or editors with specific permissions such as upload_files or edit_others_posts. This represents a significant deviation from secure coding practices where access control mechanisms must strictly validate user roles against required capabilities prior to action execution.
The operational impact of this vulnerability is severe, enabling attackers to permanently delete arbitrary media attachments and upload malicious files directly to the WordPress site. By exploiting the wp_delete_attachment function without proper authorization checks, an attacker can cause data loss or disrupt website functionality by removing critical images and assets. Furthermore, the ability to upload new attachments allows for potential web shell deployment or other forms of code execution if the uploaded file is processed server-side. These actions compromise the integrity and availability of the web application, potentially leading to full site takeover depending on subsequent exploitation steps such as remote code execution via uploaded scripts.
A key factor facilitating this attack vector is a configuration error within the Meow_WPLR_Sync_Admin class constructor where an admin screen guard has been commented out. This oversight causes the wplr_auth_token to be leaked into every admin page view through wp_localize_script, making it accessible in the source code of any logged-in user with access to these pages. Even users at the Subscriber level can extract this token from their own profile.php page source. Once obtained, this token allows attackers to bypass standard authentication mechanisms by invoking destructive actions on the /?wplr-sync-api endpoint using a cookie-less HTTP session. This effectively neutralizes CSRF protections and other state-based security controls that rely on proper session management.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-359 Exposure of Private Information to an Unauthorized Actor due to the token leakage. In terms of attack patterns, it corresponds to MITRE ATT&CK techniques involving unauthorized access via API endpoints and potential privilege escalation from low-level user accounts to administrative functions. The combination of information disclosure leading to authentication bypass creates a high-severity risk profile that requires immediate remediation.
Mitigation strategies should focus on patching the plugin to version 6.5.7 or later where these authorization checks have been properly implemented. Administrators must ensure that admin screen guards are not commented out in production environments and verify that sensitive tokens like wplr_auth_token are never exposed via client-side scripts unless absolutely necessary for specific, secured functionalities. Additionally, implementing strict input validation and output encoding on API endpoints can help mitigate the impact of such vulnerabilities if they persist in older versions. Regular security audits and code reviews should be conducted to identify similar patterns where access controls might be inadvertently disabled or improperly configured during development updates.