CVE-2026-92809: 
Prestashop vulnerability analysis and mitigation

CVE-2026-92809 is an Insecure Direct Object Reference (IDOR) vulnerability in the PrestaShop psgdpr (Official GDPR Compliance) module affecting all versions through 1.4.3. The flaw allows authenticated customers to forge GDPR consent audit log entries attributed to arbitrary other customers by submitting user-controlled customer identifiers, corrupting the integrity of GDPR compliance records. It was discovered on May 17, 2026, reported to PrestaShop, and publicly disclosed on September 16, 2026 after multiple follow-up attempts. The vulnerability carries a CVSS v3.1 base score of 4.3 (Medium) and a CVSS v4.0 base score of 5.3 (Medium) (Github Advisory, Feedly).

The root cause is an authorization bypass through a user-controlled key (CWE-639) in controllers/front/FrontAjaxGdpr.php. When handling action=AddLog POST requests, the controller reads id_customer directly from user-supplied input via Tools::getValue('id_customer') and uses it in the database insert without verifying it matches the authenticated session's customer. The token check (sha1($customer->secure_key)) authenticates that the caller is a valid logged-in customer, but does not scope the operation to that customer's own account — meaning any authenticated customer can pass an arbitrary id_customer value to insert consent records attributed to any other customer (geo-chen PoC, Vulnerable Source).

Successful exploitation corrupts the integrity of GDPR audit logs stored in the ps_psgdpr_log table, causing forged "Consent confirmation" entries to appear in the admin back-office GDPR activity log indistinguishable from legitimate records. This undermines regulatory compliance accountability, as organizations relying on these logs for GDPR evidence cannot trust their accuracy. An attacker can enumerate all integer customer IDs to flood the audit log with forged entries at scale, making forensic investigation and compliance reporting unreliable. There is no confidentiality or availability impact — the vulnerability is limited to integrity of consent documentation (Github Advisory, geo-chen PoC).

No public proof-of-concept exploit code has been released, and there is no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires only a valid customer account on the target PrestaShop store, making it accessible to any registered user with low technical skill. The attacker's own psgdpr_token (sha1 of their secure_key) is exposed in GDPR data export links after login, providing the necessary token value (Feedly, geo-chen PoC).

1. Obtain a customer account: Register or log in as a valid customer on the target PrestaShop store running psgdpr ≤ 1.4.3.
2. Retrieve your own token: Navigate to the GDPR personal data page after login and inspect the CSV/PDF export links to extract the psgdpr_token query parameter, which is the sha1 of your own secure_key.
3. Identify target customer IDs: Enumerate integer customer IDs (e.g., 1, 2, 3, ...) by trial — the endpoint accepts any integer and returns HTTP 200 regardless of whether the ID exists.
4. Submit forged consent record: Send a crafted POST request to the GDPR AJAX endpoint with the victim's customer ID:

POST /module/psgdpr/FrontAjaxGdpr
Cookie: [authenticated session cookie]

action=AddLog&id_customer=<VICTIM_ID>&customer_token=<YOUR_TOKEN>&id_module=0

5. Verify forged entry: The server responds with HTTP 200 and an empty body. The forged "Consent confirmation" entry now appears in the admin back-office under GDPR > Customer activity, attributed to the victim's name and indistinguishable from a legitimate record.
6. Scale the attack: Automate steps 3–5 across all customer IDs to flood the audit log with forged entries, rendering GDPR compliance records unreliable (geo-chen PoC, Vulnerable Source).

• Network: Repeated POST requests to /module/psgdpr/FrontAjaxGdpr with action=AddLog from a single authenticated session, particularly with rapidly incrementing id_customer values differing from the session's own customer ID.
• Logs: Web server access logs showing high-frequency AddLog requests from a single IP or session cookie; requests where the id_customer parameter does not match the authenticated customer's ID.
• Database: Unusual volume of entries in the ps_psgdpr_log table attributed to multiple customers within a short time window from a single source; consent records with timestamps inconsistent with normal user activity patterns.
• Admin Back-Office: Anomalous number of "Consent confirmation" entries for customers who have not recently interacted with GDPR consent forms, visible in the GDPR > Customer activity log (geo-chen PoC).

Update the PrestaShop psgdpr module to a version later than 1.4.3, which addresses the missing authorization check. As a workaround prior to patching, restrict customer account registration or monitor the GDPR AJAX endpoint for anomalous activity. After patching, review and validate existing GDPR consent logs in ps_psgdpr_log for suspicious entries — particularly records where the submission pattern is inconsistent with normal customer behavior. The fix should enforce that the id_customer used in GDPRLog::addLog() is sourced from the authenticated session context rather than user-supplied input (Github Advisory, Feedly).

The vulnerability was discovered by security researcher geo-chen and disclosed publicly on September 16, 2026 after a protracted disclosure process spanning nearly four months, including multiple unanswered follow-up emails to PrestaShop. VulnCheck published an advisory covering the issue. No significant broader media coverage or notable community commentary beyond the researcher's own disclosure write-up has been identified at this time (geo-chen PoC, VulnCheck Advisory).