CVE-2026-48744 in Saleor
Summary
by MITRE • 08/18/2026
Saleor is an e-commerce platform. From 3.14.67 until 3.21.67, 3.22.63, and 3.23.22, a broken authorization check in saleor/permission/utils.py can incorrectly authorize unauthenticated GraphQL requests. The flaw permits anonymous callers to use the channelUpdate() mutation to change channel order settings such as allowUnpaidOrders even when the response reports PermissionDenied. The same permission utility can expose hidden objects through the pageType() and translation() queries, including attributes whose visibleInStorefront field is false and that should be visible only to users with management permissions. This issue is fixed in versions 3.21.67, 3.22.63, and 3.23.22.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified within the Saleor e-commerce platform represents a critical failure in access control mechanisms, specifically affecting GraphQL API endpoints between version 3.14.67 and specific patched releases of versions 3.21, 3.22, and 3.23. This flaw stems from an incorrect implementation of authorization checks within the saleor/permission/utils.py module. In a secure system architecture, every request to modify or retrieve sensitive data must undergo rigorous validation against the user's assigned roles and permissions before execution. However, in this instance, the permission utility fails to properly enforce these restrictions for unauthenticated users, allowing them to bypass security controls that are designed to restrict access based on authentication status. This type of failure is classically categorized under CWE-285, which describes Improper Authorization, where an actor is able to perform actions or view data without having the necessary privileges.
The operational impact of this vulnerability is twofold, involving both unauthorized state changes and information disclosure. First, anonymous callers can exploit the channelUpdate() mutation to alter critical configuration settings for sales channels. Specifically, attackers can modify parameters such as allowUnpaidOrders, which dictates whether orders can be processed without immediate payment authorization. This capability allows malicious actors to potentially facilitate fraudulent transactions or disrupt business logic by enabling unpaid order processing in environments where it should be strictly prohibited. Notably, the vulnerability is particularly insidious because the API response may still report a PermissionDenied status even though the underlying state change has successfully occurred on the server side. This discrepancy between the reported error and actual system behavior can mislead automated security scanners or developers relying solely on HTTP responses to verify patch effectiveness, thereby extending the window of exposure for affected systems.
Secondly, the broken authorization check enables unauthorized data exfiltration through specific GraphQL queries such as pageType() and translation(). These endpoints are intended to return metadata about pages and translations but fail to filter out objects that should remain hidden from public view. Most critically, this includes attributes marked with a visibleInStorefront field set to false. In the Saleor architecture, these fields indicate content or product data that is reserved exclusively for administrative users who possess management permissions. By exposing these hidden objects, attackers can gain insight into internal business structures, unpublished products, or sensitive configuration details that are not meant for public consumption. This constitutes a severe information disclosure vulnerability, aligning with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor. The ability to enumerate and retrieve this data provides adversaries with valuable intelligence that could be leveraged in subsequent attacks against the platform's infrastructure or business logic.
From a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability facilitates several malicious tactics. The unauthorized modification of channel settings corresponds to Defense Evasion techniques such as T1078: Valid Accounts, although here it is applied to unauthenticated access bypassing standard authentication layers entirely. Furthermore, the ability to query hidden attributes and page types aligns with Discovery techniques like T1046: Network Service Scanning or more specifically API-based enumeration methods used by attackers to map out an application's data model without proper credentials. The combination of these capabilities allows for a comprehensive reconnaissance phase followed by active exploitation of configuration weaknesses, significantly increasing the risk profile for organizations running affected versions of Saleor.
To mitigate this vulnerability, immediate action is required to upgrade the Saleor platform to one of the patched versions: 3.21.67, 3.22.63, or 3.23.22 and later. These releases contain corrections for the permission utility logic that ensure unauthenticated requests are properly rejected at the authorization layer before any state changes occur. For organizations unable to upgrade immediately due to operational constraints, implementing a Web Application Firewall (WAF) rule set can provide temporary protection by blocking suspicious GraphQL mutations targeting channel updates or specific query patterns associated with page type and translation endpoints from anonymous IP addresses. Additionally, developers should review their API response handling logic; relying solely on HTTP status codes like 403 Forbidden is insufficient for verifying security controls because of the bug where successful modifications may still return error statuses. Implementing strict input validation and ensuring that authorization checks are performed consistently across all GraphQL resolvers will help prevent similar access control failures in future development cycles. Regular penetration testing focused on API authentication bypasses should also be conducted to verify that such vulnerabilities do not persist in custom integrations or extended modules built upon the Saleor core.