WPLP Cookie Consent CVE-2026-75865: unauthenticated upload may lead to RCE

CVE-2026-75865 is a critical vulnerability in the WPLP Cookie Consent WordPress plugin (gdpr-cookie-consent). An authorization bypass on connector REST endpoints combines with missing file-type validation in saas_upload_logo() to let an unauthenticated attacker place an arbitrary file on the server. If that file lands where the web server can execute it, the result may be remote code execution.

Every version through 4.4.1 is affected. The fix is in 4.4.2. The NVD record published on 1 September scores the issue 9.8 Critical under CVSS 3.1. WordPress’s plugin directory reports more than 10,000 active installations, making this more than a theoretical weakness in an obscure component.

The cited sources do not confirm active exploitation at publication time. That distinction matters: a high score, an exposed attack surface and potential RCE justify immediate response, but they do not support claiming every vulnerable site has been attacked.

What actually broke

Uploading a logo should not be dangerous. A safe implementation first proves that the caller may perform the operation, then validates size, real format and an allowed extension, chooses a controlled name, and stores the image somewhere scripts cannot execute. Two separate boundaries failed here.

The first was access to REST endpoints used by the connector. According to the vulnerability description, required authorization could be bypassed, allowing a caller without an administrator session to start a trusted workflow. The second was the upload handler itself: saas_upload_logo() did not enforce an appropriate file type.

Combining those failures turns a cosmetic feature into a file-write primitive. The authorization gap opens the route to the handler, while missing validation removes the “images only” constraint. Final impact still depends on hosting configuration: PHP process write permissions, destination directory, web-server rules and whether placed files execute. The CVE nevertheless describes a path from upload to RCE, so teams should not delay the update based on assumptions about a typical WordPress setup.

Why checking an extension is insufficient

Treat an upload as a parser for untrusted input. Checking the last characters of a filename is not enough. A name may contain multiple extensions, case variations or data inconsistent with its declared MIME type. The Content-Type header also comes from the client and does not prove the object is an image.

Defence should combine several layers:

strict server-side authorization for the operation;
an allowlist of formats and content recognition, not merely a filename check;
decoding and re-encoding images without retaining active content;
a server-generated random filename instead of the client’s name;
size, dimension and processing-time limits;
storage outside the webroot, or at minimum a directory where code execution is unconditionally disabled.

Even correct format validation cannot replace access control. An administrator may upload a logo; an anonymous client should never enter that flow. Correct authorization does not remove the need to inspect the file either: a captured admin session, CSRF defect or flawed integration can still supply dangerous data.

Which sites should be treated as exposed

Start with inventory based on deployed files and management data, not whether a cookie banner appears on the homepage. A theme or setting may hide the banner while the vulnerable plugin code remains installed and reachable.

Action is required for:

active WPLP Cookie Consent installations at version 4.4.1 or earlier;
inactive plugin copies left under wp-content/plugins where PHP files may still be called directly;
staging, demonstration environments and old site copies exposed to the internet;
machine images, snapshots and deployment templates containing an old release;
sites restored from backup after they had previously been updated.

The WordPress directory lists WordPress 5.9+ and PHP 7.4+ as current requirements and says the plugin is tested through WordPress 7.1. If an old runtime prevents the upgrade, that is not a reason to leave the vulnerable component online. Isolate the site, modernize the environment or replace the plugin with a maintained option.

Updating to 4.4.2 is the first step

Deploy 4.4.2 from a trusted channel and verify the version on disk, not only the message in the dashboard. This release’s changelog mentions stronger security and validation as well as improved data handling. The public changeset lets defenders review the scope, but it should not become an excuse for a home-grown partial hotfix instead of installing the complete package.

After deployment:

remove old copies of the plugin directory, temporary files and remnants of manual installation;
invalidate PHP caches or opcache so processes do not continue running old code;
independently confirm the version on every instance and node;
test saving banner settings and a legitimate image upload;
confirm an unauthenticated request is rejected and a disallowed file is not stored.

The last check should use harmless text or otherwise inert data. A web shell or command-executing payload is unnecessary to verify the repair. The regression test’s purpose is to prove that access control and validation stop the input, not to reproduce the complete RCE chain.

If the update cannot happen immediately

The safest temporary option is disabling and removing the vulnerable plugin where the site can operate without it. Deactivation in the dashboard does not necessarily remove files from disk. If the code must remain during a short maintenance window, restrict public access to the connector’s specific routes at the reverse proxy or WAF, guided by logs and the application’s actual paths.

Do not block the entire WordPress REST API without analysis. That can break the block editor, integrations and monitoring while failing to close an alternative path. An emergency rule should be narrow, observable and assigned a removal date. It compensates until 4.4.2 is installed; it is not equivalent to the patch.

At the hosting layer, prohibit PHP and other script execution in upload directories. This reduces the impact of many WordPress bug classes, but the rule must cover every writable path, including directories created by plugins. If the application requires executable files in a writable directory, that is a prompt to change the architecture.

Hunting for evidence of exploitation

Updating closes the vulnerability but does not delete a file uploaded earlier or an account created by an intruder. The investigation window should begin at least when the vulnerable version was installed, or at the last trustworthy integrity assessment.

Review:

access logs for the plugin’s REST endpoints and connector routes, especially unusual methods, authorization errors and requests without a valid session;
new or changed files in wp-content/uploads, the plugin directory, mu-plugins, the active theme and the WordPress root;
executable extensions, double extensions or PHP content in media directories;
unexpected administrator accounts, application passwords, WP-Cron entries and system cron jobs;
changes to wp-config.php, web-server rules and autoloaded database configuration;
outbound connections from PHP and anomalous child processes of the web server.

Do not limit detection to one known filename. Arbitrary upload lets an attacker choose the artifact’s name, and after code execution the original file may be removed. Policy violations are stronger signals: code inside a media directory, a recently altered core file, a system process spawned by the web-server identity or a new administrator without a change record.

Comparison with clean WordPress, theme and plugin packages helps, but it does not cover locally generated content. You need both perspectives: integrity of known components and analysis of locations designed to be writable.

When a suspicious file appears

Do not reflexively delete it before preserving evidence. Isolate the instance from traffic, retain logs, a disk snapshot and process data, then determine scope. Assume that code execution in the WordPress context may expose database credentials from wp-config.php, authentication salts, API keys, SMTP tokens and secrets available through environment variables.

Rebuilding from a clean image is generally more reliable than manually deleting the files you noticed. After rebuilding, rotate secrets, invalidate user sessions, change administrative and database credentials, review accounts, and only then restore traffic. Inspect the recovery backup too—it may already contain the old plugin or attacker persistence.

If several sites share one hosting account, the incident boundary is not a single domain. Shared file permissions and the same PHP identity may permit movement between installations. Define scope by system identities, credentials and common resources, not by URL.

Architectural lessons for WordPress

CVE-2026-75865 shows how a small integration endpoint can bypass protection visible in the administrator dashboard. Plugin reviews should map not only settings pages but also registered REST routes, AJAX actions, webhooks, importers and background tasks. Each entry point has its own authorization and validation rules.

Organizations operating many sites should centrally collect component versions, enforce a signed or controlled update process, and alert on executable files in writable directories. Production WordPress can also run with application files mounted read-only, with an update pipeline building a fresh artifact. The upload flaw still needs a patch, but it then has far fewer places where it can persist code.

Breachroad separates sourced facts from operational assessment. NVD and Wordfence describe the affected versions, missing file-type control, authorization bypass and possible RCE. The WordPress directory and changeset establish version 4.4.2 and its published changes. Recommendations about execution controls, telemetry, rebuilding and secret rotation are our conclusions based on the usual impact of arbitrary file write in a PHP application.

Primary and reference sources

If your team operates WordPress or builds custom upload endpoints, our web application security training turns this case into practical authorization, file-validation and monitoring patterns. A web application penetration test is the next step when you need to validate the real REST, upload and permission surface in your environment.