CVE-2026-79324 in GDPR for Magento
Summary
by MITRE • 09/09/2026
Missing authorization in the Address Delete controller in Mageplaza GDPR for Magento 2 (mageplaza/module-gdpr) through 4.2.9 allows remote unauthenticated attackers to delete any customer's saved address, and to erase all stored addresses by iterating the address id, via a GET request to /customer/address/delete/id/{id}. The controller extends the legacy Action class instead of AbstractAccount, so no authentication, ownership or form key check is enforced.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Mageplaza GDPR for Magento 2 versions through 4.2.9 represents a critical failure in access control mechanisms within the customer address management subsystem. Specifically, the Address Delete controller fails to enforce proper authorization checks before processing deletion requests. This flaw allows remote unauthenticated attackers to delete any customer's saved addresses by simply iterating through valid address identifiers via HTTP GET requests directed at /customer/address/delete/id/{id}. The root cause lies in the architectural decision where this specific controller extends the legacy Action class rather than AbstractAccount, which is typically responsible for enforcing authentication and ownership validation in Magento 2 core functionality. Consequently, no session verification, user identity confirmation, or form key validation occurs during the request lifecycle, leaving the operation completely exposed to unauthorized execution.
From a technical perspective, this vulnerability exemplifies an insecure direct object reference combined with broken access control principles. The system fails to verify that the authenticated user initiating the deletion is the legitimate owner of the target address resource. In standard Magento 2 implementations, operations affecting customer data are tightly coupled with session state and require explicit proof of ownership through form keys or token-based validation mechanisms designed to prevent Cross-Site Request Forgery and unauthorized modifications. By bypassing these safeguards due to inheritance from a base class that lacks such security middleware, the application exposes sensitive personal information storage infrastructure to trivial exploitation. Attackers can automate this process using simple scripts to enumerate address IDs and systematically erase all stored addresses for targeted victims or across multiple accounts if ID patterns are predictable.
The operational impact of this vulnerability is significant, particularly regarding data integrity and customer experience. Address deletion directly affects the ability of customers to complete checkout processes that rely on saved shipping information. For e-commerce platforms, losing valid address records can lead to order fulfillment failures, increased support ticket volume, and potential loss of revenue due to abandoned carts or delayed shipments. Furthermore, this capability undermines trust in the platform's security posture, as it demonstrates a fundamental lack of protection for personally identifiable information storage structures. While the GDPR module is intended to facilitate data privacy compliance, its own implementation flaws create new risks that contradict the principle of secure by design.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-639 Authorization Bypass Through User-Controlled Key in the Common Weakness Enumeration framework. It also maps closely to MITRE ATT&CK technique T1078 Valid Accounts, as attackers leverage valid system structures without proper credentials or permissions, and potentially T1530 Data from Cloud Storage Objects if viewed through the lens of data exfiltration via destruction. The absence of form key validation further relates to CWE-352 Cross-Site Request Forgery since GET requests are inherently susceptible to CSRF attacks when they perform state-changing operations without additional verification tokens.
Mitigation strategies should prioritize immediate patching to version 4.3.0 or later where these authorization checks have been corrected. In the interim, administrators can implement web application firewall rules to block access to /customer/address/delete endpoints from unauthenticated sessions. Additionally, enforcing strict HTTP method policies that reject GET requests for any action modifying customer data provides a defensive layer against this specific exploitation vector. Developers should ensure all controllers handling sensitive user operations extend AbstractAccount or equivalent secure base classes that enforce authentication and ownership verification before processing business logic. Regular security audits of third-party extensions are essential to identify similar architectural oversights in other modules interacting with core Magento functionality.