PrestaShop psgdpr EUVD-2026-81067

Requires an authenticated customer account on a PrestaShop store with the psgdpr (GDPR compliance) module installed at version 1.4.3 or earlier. Exploitation is a single crafted request to the front-office GDPR consent AJAX endpoint (FrontAjaxGdpr.php) with an attacker-chosen customer identifier; no admin rights, no user interaction, and no special store configuration are needed beyond having the module active. LIMITING FACTORS: valid customer authentication is mandatory (PR:L), the psgdpr module must be installed (it is an optional add-on, not core PrestaShop), and the impact is confined to integrity of GDPR consent audit records - no data disclosure, account takeover, or service disruption is possible through this flaw.

This is a genuinely LOW real-world priority despite the medium 5.3 CVSS 4.0 score. The vendor vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) is honestly scoped: integrity-only (VI:L) with zero confidentiality (VC:N) and zero availability (VA:N) impact - the attacker can forge or corrupt GDPR consent audit-log entries but cannot read other customers' data, take over accounts, or disrupt the store. PR:L confirms authentication is required (a valid customer account), which meaningfully narrows the attacker pool. A public POC exists (VulnCheck / geo-chen research), which raises the practical reproducibility of the technique, but this is NOT the same as exploitation: there is no CISA KEV listing and no EPSS score in the provided data, so there is no evidence of active or automated exploitation. The impact ceiling is audit/compliance-record integrity - relevant for GDPR defensibility and forensic trust, but not a system-compromise vector. Bottom line: publicly reproducible authenticated IDOR with a narrow integrity-only blast radius - worth patching in normal cycles, not an emergency.

An attacker registers or uses an existing customer account on a PrestaShop store running the psgdpr module (≤1.4.3), then submits a GDPR consent-logging AJAX request while substituting a different (victim) customer identifier in the payload. Because FrontAjaxGdpr.php never checks that the supplied customer ID matches the authenticated session, the server writes a forged consent record attributed to the victim, polluting the GDPR audit trail. A public POC demonstrating this IDOR is available in the geo-chen/oss research writeup.