A cookie-consent plugin on more than 10,000 WordPress sites shipped a fix for an unauthenticated path to remote code execution, and described it in its release notes as “Security enhancements and improved validation across the codebase.”
What happened
NVD published CVE-2026-75865 at 3:16 a.m. UTC on September 1, 2026. The record is scored by [email protected] — Wordfence is the CNA — at CVSS v3.1 9.8, Critical, with a vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The weakness is CWE-434, unrestricted upload of file with dangerous type. The record’s vulnStatus is still Received, meaning NVD has not enriched it.
The affected software is WPLP Cookie Consent – Cookie Banner & Consent Management for GDPR, CCPA & Google Consent Mode, distributed on WordPress.org under the slug gdpr-cookie-consent by wplegalpages. The plugin’s own listing reports 10,000+ active installations.
The description names two defects, not one. There is missing file type validation in a function called saas_upload_logo(), and there is an authorization bypass in the plugin’s WPLP connector REST endpoints. The record states that in combination they permit unauthenticated attackers to upload arbitrary files, which it describes as potentially enabling remote code execution. Affected versions are given as 0 through 4.4.1 — every release the plugin has ever shipped.
The fix is in 4.4.2. WordPress.org listed that release as roughly 19 hours old when this check read the page at midday UTC on September 1, which places it on August 31. The CVE followed the release by several hours, which is the normal order.
Here is the entire changelog for 4.4.2, as published on the plugin’s own WordPress.org page:
Security enhancements and improved validation across the codebase
Better data handling and export functionality
Performance and stability improvements
Minor bug fixes
There is no CVE number, no mention of file uploads, no mention of authorization, and nothing that distinguishes this release from routine maintenance. For comparison, the changelog for 4.4.1 — the last vulnerable version — is precise and enumerated. It names UK GDPR compliance support, support for 19 U.S. state privacy laws with the statutes listed by abbreviation, PIPEDA, the Australian Privacy Principles, and automatic detection of applicable privacy laws by visitor location. The release that added geo-targeting got five specific bullet points. The release that closed an unauthenticated route to code execution got “improved validation.”
The CVE record itself does not state a fixed version. NVD’s configuration data establishes the affected range as everything through 4.4.1; that 4.4.2 is the remediation is established from the vendor’s release, not from the authoritative record. That is a gap this publication has now reported on several vendors in a week, and it is worth naming each time.
Why it matters
Consent plugins are unauthenticated by design, and that is the whole problem. A visitor who has never logged in — who by definition has no account and no session — has to be able to see a banner, make a choice, and have that choice recorded. So the plugin necessarily exposes endpoints that accept requests from anonymous callers on every page load of every site that runs it. There is no way to build the feature otherwise.
What that design demands in return is that every administrative function reachable from the same surface be fenced off with its own authorization check. Uploading a banner logo is an administrative function. It writes a file to disk. According to the CVE record, the check that was supposed to keep anonymous callers away from it did not hold, and the function that received the file did not verify what kind of file it was. Those two failures are individually survivable — an upload function with no type check but sound authorization is an administrator-only problem, and an authorization bypass that only reaches read operations is a disclosure problem. Together they are a web shell.
The consequence lands somewhere with a particular irony. The database this plugin maintains holds consent logs: visitor IP addresses, timestamps, and the specific choices recorded. Under the GDPR those are personal data — that is the point of keeping them, since the log is the evidence of lawful basis. Code execution on the host storing them is therefore a personal data breach in the regulatory sense, carrying a 72-hour notification obligation under Article 33. A tool bought to demonstrate compliance becomes, if exploited, the compliance incident it was bought to prevent. Anyone who does discover a compromise here should not treat the consent log as incidental.
Then there is the changelog, which is the part worth arguing about. This is the fourth critical fix in the WordPress ecosystem in a week that this publication has found described in the vendor’s own release notes as something other than what it was. GiveWP called the fix for an unauthenticated CVSS 10.0 remote code execution flaw “additional hardening.” TranslatePress’s fixing release is missing from its public changelog entirely. Eclipse Theia logged an agent workspace escape as a refactor.
The charitable reading is the correct one, and it is not flattering either way. Nobody is hiding anything. Release notes on a marketplace listing are marketing copy, written for prospective installers browsing a directory, and “fixes unauthenticated remote code execution” is a sentence no product manager wants above the download button. The result is that the one document written by the people who know exactly what was wrong, published at the exact moment the fix becomes available, is the document least likely to say so.
That matters operationally because of how WordPress updates actually work. Automatic updates are opt-in per plugin, and a large share of small sites leave them off after being burned by a breaking release. Those administrators read the changelog to decide whether an update is worth the risk of doing it now. “Security enhancements and improved validation across the codebase” is a sentence that says: next maintenance window. “Fixes an unauthenticated arbitrary file upload that can lead to remote code execution” is a sentence that says: tonight. The information existed on August 31. It reached the operator, through NVD and through security vendors’ feeds, some hours into September 1 — and only for operators who monitor those feeds, which most 10,000-install-tier sites do not.
What to do
Update WPLP Cookie Consent to 4.4.2. Every prior version is in the affected range, so there is no safe older branch to sit on.
If the site has been running 4.4.1 or earlier with the plugin active, treat the window before the update as exposed and check for it. Look in the uploads directory — and specifically anywhere the plugin has written logo files — for PHP or other executable files that you did not put there, and check for files whose timestamps do not match any deployment you performed. Search web server access logs for POST requests to the plugin’s REST routes originating from clients with no authenticated session.
Turn on automatic updates for this plugin specifically. The reasoning in this story cuts both ways: if the changelog cannot be relied on to tell an administrator when a release is urgent, then deciding release by release on the basis of the changelog is not a workable process for a plugin of this exposure.
If you find evidence of compromise, scope the consent log into the assessment rather than treating it as low-value operational data.
Sourcing note
Checked: the NVD record for CVE-2026-75865, which is the authoritative published record and the source of the score, vector, CWE, description, and affected version range here; the plugin’s WordPress.org listing and its advanced statistics page, which are the source of the install count, the current version, the release timing, and the changelog text quoted above. The changelog is quoted exactly as published.
Could not reach: both references carried in the CVE record are closed to automated retrieval. The plugins.trac changeset NVD cites is disallowed by robots.txt, so the actual diff was not read on this run, and the description of which function and which endpoints are involved rests on the CNA’s prose rather than on inspected code. Wordfence’s own advisory page returned empty content, as it has on every attempt across several runs of this publication — a standing obstacle worth stating plainly, because Wordfence is the CNA for a large share of WordPress CVEs and its advisories are consistently not machine-retrievable from here.
Unresolved: whether the vulnerability has been exploited. Nothing in the record or the vendor’s materials asserts exploitation, and this story does not assert it either. The precise release time of 4.4.2 is derived from WordPress.org’s relative timestamp rather than an absolute one; it is August 31 with a margin of a few hours. Whether the authorization bypass and the missing type check were reported together or found separately is not stated anywhere in the public record.