Active Exploitation
🔥 CyberForge CVE of the Day #040
🚨 CVE-2026-75865 — WPLP Cookie Consent Unauthenticated Arbitrary File Upload Enables Conditional Remote Code Execution
A newly disclosed Critical WordPress vulnerability transforms a seemingly ordinary cookie-banner logo uploader into an unauthenticated server-side file-write primitive.
And this one has already attracted attention in the wild.
At CyberForge’s final review on 2 September, Wordfence reported blocking 246 attacks targeting the vulnerability during the preceding 24 hours. The rolling counter had shown 247 earlier in our research session—an excellent reminder that this is live telemetry rather than a fixed historical total.
🔑 Key details:
⭐ Severity: Critical — CVSS v3.1: 9.8
📐 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
🧠 Weakness: CWE-434 — Unrestricted Upload of File with Dangerous Type
🎯 Target: WPLP Cookie Consent for WordPress
📦 Plugin slug: gdpr-cookie-consent
🔓 Authentication: None
🌐 Attack vector: Network
⚙️ Attack complexity: Low
👆 User interaction: None
⚔️ Impact: Arbitrary file upload with conditional RCE and site takeover
🛡️ Affected: Every version through and including 4.4.1
✅ Fixed: WPLP Cookie Consent 4.4.2
🌍 Active exploitation: Attack attempts observed and blocked by Wordfence
🧪 Public PoC: No independent executable PoC identified during CyberForge research
📋 CISA KEV: Not listed as of 2 September 2026
📉 EPSS: Not yet available at review time
👤 Researcher: Supakiad S. (m3ez) — E-CQURITY Thailand
🧬 What actually went wrong?
WPLP Cookie Consent includes functionality for uploading a logo used by the consent interface. That operation crosses two security boundaries which fail together in affected releases.
First, Wordfence reports an authorization bypass affecting the WPLP connector REST endpoints. A sensitive upload operation that should be restricted can therefore be reached without a WordPress account or administrator session.
Second, the plugin’s saas_upload_logo() function fails to validate the submitted file type adequately.
The result is not merely an attacker changing a banner image. It allows an unauthenticated internet client to upload an arbitrary file to the affected server.
⚔️ The attack chain:
1️⃣ An attacker identifies an internet-facing WordPress site running WPLP Cookie Consent 4.4.1 or earlier.
2️⃣ They send an unauthenticated file-upload request to the affected upload-logo REST functionality.
3️⃣ The WPLP connector authorization weakness allows the request to reach the upload handler.
4️⃣ Missing file-type validation in saas_upload_logo() permits dangerous content instead of restricting the operation to a genuine, safe image.
5️⃣ The server stores the attacker-controlled file.
6️⃣ If that file lands in a web-accessible location where the server executes its type, the attacker requests it and obtains code execution as the PHP/web-service identity.
7️⃣ The intruder may then access WordPress secrets, modify the site, add persistence, steal data or deploy additional tooling within the permissions available to that process.
⚠️ Arbitrary upload versus automatic RCE
This distinction is crucial.
The unauthenticated arbitrary file upload is confirmed. Remote code execution is a realistic but deployment-dependent consequence.
For a direct web-shell chain, the uploaded object must retain an executable form, land somewhere reachable, and be handled by the web server as server-side code. PHP execution policy varies between Apache, Nginx, PHP-FPM, managed WordPress platforms, containers and hardened hosting environments.
One server may execute a .php file beneath a writable web directory. Another may explicitly deny PHP execution from uploads or route only approved application entry points to PHP-FPM.
The vulnerability therefore should not be marketed as guaranteed one-request RCE against every installation. Equally, calling it only a harmless upload issue would badly understate the danger on conventional permissive deployments.
The accurate headline is:
🔥 Critical unauthenticated arbitrary file upload with conditional remote code execution.
Code obtained through this route would initially run with the operating-system permissions of PHP-FPM, Apache or the relevant web service. It does not automatically grant root, container escape, hosting-administrator access or control of every neighbouring site.
But the web identity often has access to exactly the secrets and files needed to compromise WordPress.
💥 Potential impact
A successful web shell could potentially allow an attacker to:
🔹 Read database credentials and authentication salts from wp-config.php
🔹 Access customer, subscriber, form, order or consent records stored by WordPress
🔹 Modify themes, plugins, pages and rendered content
🔹 Create rogue WordPress administrator accounts
🔹 Inject redirects, phishing pages, malicious JavaScript or SEO spam
🔹 Plant multiple backdoors to survive removal of the first uploaded file
🔹 Use the compromised site to attack visitors or distribute malware
🔹 Reach internal services available to the web workload
🔹 Pivot into neighbouring sites where shared-hosting isolation is weak
🔹 Destroy or encrypt data available to the service account
The exact blast radius depends on filesystem permissions, secret scoping, network segmentation, hosting architecture and whether the affected WordPress instance shares resources with other applications.
📊 Why the 9.8 score fits
The Wordfence CNA vector records:
🌐 Network reachability
⚙️ Low attack complexity
🔓 No privileges required
👆 No user interaction
🎯 Unchanged scope
💥 High confidentiality, integrity and availability impact
The Scope: Unchanged metric does not mean the outcome is minor. It reflects how CVSS models the affected security authority; successful execution can still yield complete control of the WordPress/PHP environment available to the compromised process.
At review time, no authoritative CVSS v4.0 vector had been published for this record. CyberForge therefore preserves the verified CVSS v3.1 score rather than manufacturing a v4 conversion.
🌍 The exploitation picture:
Wordfence’s live firewall counter is the strongest current threat signal: 246 blocked attacks during the preceding 24 hours at final verification.
That supports the conclusion that exploitation attempts are happening in the wild.
It does not prove:
❌ That the blocked requests achieved file upload or code execution
❌ That 246 unique attackers or victim sites were involved
❌ That every request carried a functional payload
❌ That a named threat actor or coordinated campaign is responsible
❌ That successful compromises have been publicly verified
So the correct status is:
🚨 Active exploitation attempts
observed; successful compromise not publicly confirmed in the evidence reviewed.
No independent executable PoC repository, Exploit-DB entry, Packet Storm release or Metasploit module was identified during CyberForge research. However, the public advisory already identifies the vulnerable function and endpoint class, and active attempts matter far more than waiting for a polished GitHub script.
The CVE was not in CISA’s Known Exploited Vulnerabilities Catalog on 2 September, and FIRST had not yet produced an EPSS probability for this exceptionally young record. Neither absence should outweigh direct vendor telemetry and a confirmed fixed release.
📦 Exposure and affected versions
The official range is simple:
❌ WPLP Cookie Consent 4.4.1 and earlier — vulnerable
✅ WPLP Cookie Consent 4.4.2 — fixed
The official WordPress directory showed more than 10,000 active installations at review time. That count represents a meaningful target pool for automated scanners, including small sites that may not consider themselves attractive enough for targeted intrusion.
Inventory using the exact plugin slug gdpr-cookie-consent. Similar-looking cookie-banner products are not automatically affected.
Check production sites, staging systems, development clones, disaster-recovery copies and client installations. A forgotten public clone can be just as exploitable as the main website.
An inactive plugin directory should be removed as sound hygiene, but this specific vulnerable REST route normally requires the plugin code to be active and register it. Do not declare a deactivated copy remotely exploitable without confirming route reachability.
🛠️ The fix:
Upgrade to WPLP Cookie Consent 4.4.2 or later from a trusted source.
The official CVE record links WordPress plugin changeset 3674117 as the remediation. The public 4.4.2 changelog uses broad language about improved security, validation and data handling rather than spelling out the CVE mechanics, while Wordfence explicitly marks 4.4.2 as the patched version.
After updating:
✅ Verify the version actually loaded by WordPress
✅ Clear application and PHP opcode caches where relevant
✅ Confirm every web node and cloned instance received the update
✅ Preserve and review historical telemetry from the vulnerable exposure window
Patching closes the known vulnerable path. It does not delete a web shell or reverse changes already made by an attacker.
🔎 Defender hunting guide:
1️⃣ Inventory exposure
Search WordPress management platforms, SBOMs and filesystems for gdpr-cookie-consent. Record the running version and whether the site was internet accessible while using 4.4.1 or earlier.
2️⃣ Review HTTP telemetry
Search CDN, reverse-proxy, WAF and web-server logs for unauthenticated POST or multipart upload traffic involving WPLP connector or upload-logo REST activity.
Prioritise successful 2xx responses, repeated attempts across multiple sites, mismatched image content types, unusual extensions and a subsequent request to a newly created file.
The authoritative disclosure does not publish the complete REST route, request method, multipart field name or response format. Do not build detection around one guessed URI copied from an unverified secondary article.
3️⃣ Hunt the filesystem
Inspect every web-writable location—not only wp-content/uploads—for recently created or modified:
🔍 .php, .phtml, .phar, .php5 and other executable files
🔍 .user.ini, .htaccess or handler-changing configuration
🔍 Image-named files containing PHP tags or obfuscated executable content
🔍 Unfamiliar files in upload, cache, temporary, plugin and theme directories
🔍 Core, theme or plugin modifications that do not match trusted packages
🔍 Unexpected must-use plugins and timestamp anomalies
The primary advisory does not disclose the upload destination, so hunting only the media directory creates a dangerous blind spot.
4️⃣ Correlate workload behaviour
Investigate PHP or web-server processes spawning sh, bash, PowerShell, curl, wget or unfamiliar interpreters; unusual outbound DNS/network connections; access to credential files; and executable writes outside normal deployment activity.
5️⃣ Review WordPress state
Check for new administrators, unexplained password resets, application passwords, altered plugins/themes, suspicious scheduled tasks, redirects, and changes to siteurl, home or admin_email.
🛡️ Defensive action:
✅ Update every instance to 4.4.2 or later immediately
✅ Verify deployment rather than trusting an update queue
✅ Disable or remove the plugin if it is not required
✅ Temporarily block unauthenticated access to the affected plugin REST operation if patching is delayed
✅ Deny PHP/script execution in upload and cache directories where compatible
✅ Restrict web-writable paths and run the service with least privilege
✅ Isolate virtual hosts and containers to prevent cross-site movement
✅ Monitor application files and writable directories for unexpected changes
✅ Centralise and retain CDN, WAF, web, PHP and endpoint telemetry
✅ Keep clean, isolated and tested backups
A WAF is a valuable compensating layer, but it is not a permanent substitute for the fixed plugin. Signatures can miss alternative encodings, payloads and routes.
🚑 If compromise is suspected:
Do not simply update the plugin, delete the first suspicious file and declare victory.
Isolate the affected workload, preserve logs and filesystem metadata, hash suspicious files, identify every modification and establish which credentials the web process could access. Rebuild from a trusted fixed image where integrity cannot be proved.
Rotate WordPress administrator credentials, database credentials, authentication salts, hosting-panel accounts, deployment keys and exposed API tokens as appropriate. Inspect neighbouring sites and internal systems accessible from the compromised workload.
🧩 The CVE-2026-82970 wrinkle:
There is a fascinating identity complication.
CVE-2026-82970 also describes unauthenticated arbitrary file upload in WPLP Cookie Consent through 4.4.1, fixed in 4.4.2, and classified as CWE-434.
Wordfence attributes CVE-2026-82970 to researcher Jiemook. CVE-2026-75865 credits Supakiad S. and specifically names saas_upload_logo() plus the upload-logo REST endpoint.
The evidence reviewed does not conclusively establish whether these are:
🔹 Two independent vulnerable upload paths
🔹 Parallel discoveries of one underlying weakness
🔹 Overlapping records requiring later reconciliation
🔹 A duplicate assignment awaiting rejection or amendment
Patchstack’s currently visible product advisory points to CVE-2026-75865, while Wordfence continues to display both records.
Defenders should track both identifiers and deploy their shared remediation—4.4.2 or later—without double-counting installations or claiming two confirmed exploit primitives.
🔥 CyberForge verdict:
CVE-2026-75865 is exactly the kind of WordPress flaw attackers love to automate: public REST reachability, no authentication, low complexity and attacker-controlled content reaching the filesystem.
The affected feature may only appear to upload a cookie-banner logo, but it runs inside the same trusted PHP environment that holds WordPress code, database credentials, user records and content.
This is not guaranteed universal RCE. The attacker still needs the uploaded object to retain an executable form and reach a server configuration willing to execute it. But where that condition holds, the jump from a public request to a web shell can be brutally short.
The current defensive posture is patch and hunt.
Internet-facing sites running 4.4.1 or earlier deserve emergency treatment. Upgrade to 4.4.2+, verify the running build, examine the historical exposure window and harden script execution in writable directories.
The live blocked-attempt counter confirms attacker interest. The lack of a standalone PoC, EPSS score or KEV listing is no reason to delay a confirmed vendor fix for an unauthenticated Critical file-upload vulnerability.
🔗 Full visual advisory:
https://github.com/advisories/ghsa-q77m-569p-rj42
🔗 Wordfence technical advisory and live attack telemetry:
https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/gdpr-cookie-consent/wplp-cookie-consent-441-unauthenticated-arbitrary-file-upload-via-upload-logo-rest-endpoint
🔗 Official security changeset:
https://plugins.trac.wordpress.org/changeset/3674117/gdpr-cookie-consent
🔗 Official CVE record:
https://www.cve.org/CVERecord?id=CVE-2026-75865
🔗 Full NVD vulnerability details:
https://nvd.nist.gov/vuln/detail/CVE-2026-75865
#CyberForge #CVEOfTheDay #CVE202675865 #WordPress #WPLPCookieConsent #ArbitraryFileUpload #CWE434 #RCE #WebShell #AppSec #BlueTeam #ThreatHunting #IncidentResponse #PatchNow
Post summary
WPLP Cookie Consent 4.4.1 and earlier suffer a critical unauthenticated file‑upload vulnerability with conditional RCE; active exploitation is confirmed by Wordfence, a patch is available, and detailed technical information is supplied.
