sales@hackhalt.com

Home / Threats / CVE-2026-82184

WPLP Cookie Consent - Cross-Site Request Forgery (CSRF) (CVE-2026-82184)

CVE-2026-82184

The WPLP Cookie Consent WordPress plugin before 4.4.2 does not have any authorisation or CSRF checks when storing visitor consent state, and the code that does so runs on every front-end page load, allowing unauthenticated attackers to overwrite a site-wide option with arbitrary data.

CVE-2026-82184

MEDIUM CVSS 5.3 Published 2026-09-09 Updated 2026-09-09
AI Risk Moderate (52/100) Active Exploit: No strong signal Published Exploit: No public exploit references Priority: P4 Planned
Severity Band MEDIUM
CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Affected Components 1
Reference Links 1
AI Risk Engine Moderate (52/100)
Exploitability Low
Active Exploitation No strong signal
Published Exploit Status No public exploit references

Threat Timeline

  1. 2026-09-09 CVE published and first recorded in the threat feed.
  2. 2026-09-09 Record updated with latest vulnerability metadata.
  3. 2026-09-12 AI technical context refreshed for mitigation and impact guidance.
  4. Now Monitoring for follow-up changes, linked references, and new related CVEs.

AI Context

Machine-generated threat intelligence

AI Updated 28 days ago

AI enriched 28 days ago (2026-09-12 17:19 UTC)

Technical Summary

The WPLP Cookie Consent WordPress plugin before 4.4.2 does not have any authorisation or CSRF checks when storing visitor consent state, and the code that does so runs on every front-end page load, allowing unauthenticated attackers to overwrite a site-wide option with arbitrary data.

Potential Impact

Severity is MEDIUM (CVSS 5.3). Depending on deployment context, affected components may be exposed to unauthorized actions or data integrity risk.

Exploitability Assessment

Exploitability is assessed as Low based on low-bar exploit prerequisites.

Primary risk drivers: low-bar exploit prerequisites

Mitigation Recommendations

Validate affected product versions, prioritize patching, and monitor references for vendor remediation guidance. If immediate patching is not possible, apply compensating controls and limit exposure of vulnerable surfaces.

Detection & Monitoring

Track authentication anomalies, unexpected file writes, and suspicious plugin API activity around affected components.

Business Impact Lens

AI risk score 52/100 (Moderate, Low) with priority P4 Planned. Prioritize remediation where affected components process customer data, admin sessions, or Internet-exposed workflows.

Affected Products

WPLP Cookie Consent PLUGIN · wplp-cookie-consent Affected: < 4.4.2 Fixed in: 4.4.2

References

What to do about this

Patch on your next cycle Worth fixing, but not ahead of other work.

Fix it

Update WPLP Cookie Consent to 4.4.2 or later.

That is the complete fix. Everything below is what protects you in the meantime.

Cannot update today? Request / payload inspection (WAF) in Hack Halt ProSecure blocks this class of attack before WordPress processes the request.

Inspect request parameters and bodies for injection, traversal and file-inclusion payloads, and refuse the request rather than logging it.

Compare Hack Halt plans Start free

Not sure if you are affected?

Scan your site to see whether it runs WPLP Cookie Consent, and at which version.

Free, no installation, no account. It reads what your site already publishes, then tells you which plugins carry known vulnerabilities and what to do about each one.

Scan my site free See what Hack Halt does

Am I affected by this vulnerability?

You are affected if your site runs WPLP Cookie Consent. Versions below 4.4.2 are vulnerable; that release and later are not. No account is needed to exploit this, so a public site is reachable by anyone.

How do I fix it?

Update WPLP Cookie Consent to version 4.4.2 or later. That is the complete fix. Until you can update, Request / payload inspection (WAF) in Hack Halt ProSecure contains this class of attack at the request layer.

What can an attacker actually do?

This is a Cross-Site Request Forgery (CSRF) flaw. An attacker who exploits it can make a logged-in administrator perform an action just by visiting a page.