Description

The WPLP Cookie Consent – Cookie Banner & Consent Management for GDPR, CCPA & Google Consent Mode plugin for WordPress is vulnerable to arbitrary file upload due to missing file type validation in the saas_upload_logo() function combined with an authorization bypass on the WPLP connector REST endpoints in all versions up to, and including, 4.4.1. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-01T03:16:51.370Z",
  "pubdate": "2026-09-01T03:16:51.370Z",
  "executiveSummary": "The WPLP Cookie Consent plugin for WordPress, in versions up to and including 4.4.1, contains a critical security vulnerability involving an arbitrary file upload flaw. This vulnerability stems from an authorization bypass within the WPLP connector REST endpoints, which permits unauthenticated remote attackers to interact with restricted functions.\nSpecifically, the saas_upload_logo() function fails to implement necessary file type validation, allowing for the uploading of malicious executable files to the server's filesystem. Successful exploitation grants an attacker the ability to execute arbitrary code on the underlying host, leading to complete site compromise, data exfiltration, or further lateral movement within the hosting environment.\nDue to the absence of authentication requirements and the potential for Remote Code Execution (RCE), this vulnerability is classified as critical. It poses an immediate risk to any WordPress installation utilizing the affected plugin versions. There are no known authentication prerequisites, making this an ideal vector for automated exploitation attempts in the wild.",
  "technicalDetails": "The vulnerability originates from a dual-layer security failure within the WPLP Cookie Consent plugin. The primary issue is an authorization bypass flaw localized within the plugin's REST API controller, specifically the WPLP connector endpoints. Under normal security configurations, these endpoints should be restricted to administrative users; however, the lack of appropriate access control checks allows unauthenticated actors to invoke methods intended for authenticated sessions.\nThe exploitation path centers on the saas_upload_logo() function. This function, intended for administrative customization, accepts file uploads for branding purposes. The vulnerability is triggered because the function lacks server-side file type validation and MIME type checking. It fails to enforce restrictions on file extensions (e.g., .php, .phtml, .php7) or inspect the file content to ensure it matches expected image formats (e.g., JPEG, PNG).\nAn attacker can exploit this by crafting a multipart/form-data POST request targeting the exposed REST API endpoint. By injecting a payload—such as a PHP web shell—into the request body, an attacker can bypass the intended functionality. Because the server does not validate the file type before writing the request contents to the disk, the uploaded malicious script is stored in a public-facing directory within the WordPress file structure.\nOnce the file is successfully uploaded to the server, the attacker can execute the payload by simply requesting the path of the uploaded file via a standard HTTP GET request. The server's execution environment then interprets the malicious script, granting the attacker the ability to perform any action permitted by the web server's user permissions (e.g., www-data).\nPost-exploitation impact includes full system compromise, access to sensitive database credentials located in wp-config.php, modification of core site files, and the installation of persistent backdoors. Because the vulnerability is reachable through the web server's public-facing REST API, it is exposed to the entire network, requiring no prior knowledge of the site's internal architecture or existing user accounts.\nThis vulnerability affects all versions up to and including 4.4.1. The lack of strict authorization and the absence of file validation logic in saas_upload_logo() collectively provide a trivial path to Remote Code Execution."
}