CVE-2026-108697 in CoreShop
Summary
by MITRE • 10/11/2026
CoreShop through 2026.2.2 contains a missing authorization vulnerability that allows low-privileged backend users to list permission-restricted resources because ResourceController listAction skips the isGrantedOr403() check. Authenticated Pimcore users lacking resource permissions can request the generated list routes to enumerate payment providers, carriers, price rules, stores, and tax rules including ids, names, and identifiers.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in CoreShop versions up to 2026.2.2 represents a critical failure in access control mechanisms within the backend administrative interface. Specifically, this is an instance of Broken Access Control where the application fails to properly enforce restrictions on resources that are intended to be accessible only by users with elevated privileges. The root cause lies within the ResourceController class, specifically in the listAction method which handles requests for listing various resource types such as payment providers, carriers, price rules, stores, and tax rules. In a secure implementation of this functionality, the controller should verify that the authenticated user possesses the necessary permissions before returning any data. However, due to the omission of the isGrantedOr403() check, the application bypasses these authorization checks entirely for list operations. This architectural flaw allows any authenticated backend user, regardless of their assigned role or permission set, to access sensitive administrative endpoints that should be restricted.
From a technical perspective, this vulnerability exploits the lack of server-side validation on resource-level permissions. When an attacker authenticates with low-privileged credentials, they can send HTTP requests to specific list routes generated by CoreShop. Because the isGrantedOr403() function is skipped, the application does not evaluate whether the user has the required grants for these resources. Consequently, the server processes the request and returns a comprehensive JSON or HTML response containing detailed information about the configured entities. This includes unique identifiers such as UUIDs or database IDs, human-readable names, and other identifying attributes associated with payment gateways, shipping carriers, pricing logic, store configurations, and tax regulations. The absence of this check effectively neutralizes the role-based access control model implemented elsewhere in the application, creating a significant security gap that can be exploited programmatically through simple API calls or web browser interactions.
The operational impact of this vulnerability is substantial as it facilitates unauthorized information disclosure and enumeration. Attackers with low-level access can map out the entire configuration landscape of the e-commerce platform. By enumerating payment providers, an attacker might identify specific gateways in use, potentially aiding in targeted attacks against those third-party services or understanding the financial infrastructure. Listing carriers reveals logistical partners and shipping configurations, which could be used for supply chain analysis or fraud planning. Access to price rules and tax rules exposes sensitive business logic regarding pricing strategies, discounts, and regional tax compliance data. Furthermore, obtaining store identifiers and names allows attackers to profile specific retail entities within a multi-store setup. This level of visibility can serve as reconnaissance for more severe attacks, such as privilege escalation attempts, where knowledge of internal structures aids in crafting exploits against other components, or it may lead directly to financial fraud if combined with other vulnerabilities like injection flaws in related forms that lack similar protections.
This vulnerability aligns closely with CWE-284 Improper Access Control and CWE-639 Authorization Bypass Through User-Controlled Key, as the attacker leverages their authenticated session to access resources they are not authorized to view. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts, where an adversary uses legitimate credentials to gain initial foothold or persistence, and specifically relates to data staging techniques such as T1560 Archive Collected Data if the enumerated information is packaged for exfiltration. It also touches upon Discovery tactics like T1046 Network Service Scanning when used to map out available services and endpoints within the application layer. The severity of this issue depends on the sensitivity of the data exposed, but given that it involves core business logic entities like payment and tax configurations, it is considered high-risk in most enterprise environments.
Mitigation strategies must focus on restoring proper authorization checks at the controller level. Developers should ensure that all list actions within ResourceController invoke the isGrantedOr403() method or an equivalent permission verification mechanism before processing requests for restricted resources. This ensures that every access attempt is validated against the user's assigned roles and permissions defined in Pimcore’s security layer. Additionally, implementing a defense-in-depth approach by adding middleware-level checks can provide an extra safeguard against such omissions. For immediate remediation without code changes, administrators should restrict backend access to only those users who absolutely require it, applying the principle of least privilege strictly. Regular security audits and static application security testing (SAST) scans that specifically look for missing authorization calls in controller methods are recommended to prevent similar issues from being introduced during future development cycles. Updating CoreShop to a patched version where this check is properly implemented is the most effective long-term solution.