CVE-2026-33756: Saleor E-Commerce Platform DoS Vulnerability

CVE-2026-33756 Overview

Saleor, a popular open-source e-commerce platform, contains a resource exhaustion vulnerability in its GraphQL API query batching functionality. From version 2.0.0 to before versions 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118, Saleor supports query batching by submitting multiple GraphQL operations in a single HTTP request as a JSON array but fails to enforce any upper limit on the number of operations. This flaw allows an unauthenticated attacker to send a single HTTP request containing many operations, effectively bypassing the per-query complexity limit and exhausting server resources.

Critical Impact

Unauthenticated attackers can perform denial of service attacks against Saleor e-commerce installations by sending malicious batched GraphQL requests that exhaust server CPU and memory resources, potentially taking down online stores.

Affected Products

• Saleor versions 2.0.0 through 3.20.117
• Saleor versions 3.21.0 through 3.21.53
• Saleor versions 3.22.0 through 3.22.46
• Saleor versions 3.23.0a0 through 3.23.0a2

Discovery Timeline

• April 8, 2026 - CVE-2026-33756 published to NVD
• April 8, 2026 - Last updated in NVD database

Technical Details for CVE-2026-33756

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The core issue stems from Saleor's GraphQL endpoint accepting batched queries without imposing any restriction on the number of operations that can be included in a single request. While Saleor implements per-query complexity limits to prevent individual queries from being too resource-intensive, this protection is rendered ineffective when an attacker can submit an unlimited number of queries simultaneously.

The vulnerability is particularly dangerous because it can be exploited without authentication. An attacker simply needs to craft an HTTP POST request to the GraphQL endpoint containing a JSON array with thousands of GraphQL operations. Each operation may individually comply with complexity limits, but collectively they can overwhelm server resources.

Root Cause

The root cause is the absence of input validation on the batch size of incoming GraphQL requests. The GraphQL request handler processes arrays of operations without checking the array length, allowing attackers to bypass the intended resource protection mechanisms. This is a classic example of improper resource allocation where the system fails to impose limits on user-controllable inputs.

Attack Vector

The attack can be executed remotely over the network without requiring any authentication or user interaction. An attacker constructs a malicious HTTP request containing a JSON array with numerous GraphQL operations and sends it to the Saleor GraphQL endpoint (typically /graphql/). The server attempts to process all operations sequentially or in parallel, consuming CPU cycles and memory until resources are exhausted.

A typical attack payload would consist of a POST request to the GraphQL endpoint with a Content-Type: application/json header and a body containing a JSON array of hundreds or thousands of GraphQL queries. Each query could target resource-intensive operations like product searches or checkout calculations to maximize impact.

Detection Methods for CVE-2026-33756

Indicators of Compromise

• Unusually large POST requests to the /graphql/ endpoint containing JSON arrays
• Sudden spikes in server CPU or memory utilization correlated with GraphQL endpoint activity
• HTTP requests with extremely large Content-Length headers targeting the GraphQL endpoint
• Repeated requests from single IP addresses containing batched GraphQL operations

Detection Strategies

• Implement web application firewall (WAF) rules to inspect POST request bodies for oversized JSON arrays
• Monitor GraphQL endpoint response times and flag significant degradation patterns
• Set up alerting for unusual request payload sizes to the GraphQL API endpoint
• Analyze access logs for patterns of repeated batched requests from suspicious sources

Monitoring Recommendations

• Configure application performance monitoring (APM) to track GraphQL query execution times and resource consumption
• Set baseline metrics for normal GraphQL batch sizes and alert on anomalies exceeding expected thresholds
• Enable detailed logging for GraphQL operations to support forensic analysis
• Monitor network traffic for large POST payloads targeting e-commerce API endpoints

How to Mitigate CVE-2026-33756

Immediate Actions Required

• Upgrade Saleor to patched versions: 3.23.0a3, 3.22.47, 3.21.54, or 3.20.118 immediately
• Implement rate limiting at the reverse proxy or WAF level to limit requests per IP address
• Configure maximum request body size limits in your web server or load balancer
• Review and restrict access to the GraphQL endpoint if public access is not required

Patch Information

Saleor has released security patches across multiple version branches. The fixes are available in versions 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118. Organizations should update to the appropriate patched version for their deployment. Detailed patch information is available in the GitHub Security Advisory GHSA-24jw-f244-qfpp.

The following commits contain the security fixes:

• Commit 7be352f
• Commit cdb66da
• Commit d6a94e9
• Commit e42aa4d
• Commit f0371bd

Workarounds

• Deploy a reverse proxy with request body size limits to reject oversized batch requests before they reach Saleor
• Implement custom middleware to validate and limit the number of operations in batched GraphQL requests
• Use a WAF rule to inspect JSON payloads and block requests containing arrays exceeding a reasonable operation count
• Temporarily disable GraphQL query batching if business requirements permit

# Example nginx configuration to limit request body size
# Add to your Saleor nginx server block

location /graphql/ {
    client_max_body_size 100k;
    limit_req zone=graphql_limit burst=10 nodelay;
    proxy_pass http://saleor_backend;
}

# Define rate limiting zone in http block
limit_req_zone $binary_remote_addr zone=graphql_limit:10m rate=10r/s;