EUVD-2026-83264
GHSA-6276-frvw-567j
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify Saleor GraphQL login endpoint
-
DeliveryCraft auth request with spoofed X-Forwarded-For
-
ExploitRotate forged IP per attempt to evade throttle
-
ExecutionIterate credential guesses without lockout
-
ImpactCompromise account via brute-force
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Brute-force prevention, rate limiting
|
| Exploitation Conditions | Exploitation requires that Saleor sits behind a reverse proxy or deployment where the X-Forwarded-For header is not properly sanitized or pinned, so a client-supplied XFF value reaches get_client_ip() and is trusted as the throttling key; per issue #19203 this holds in 'most deployments,' and a REAL_IP_ENVIRON-type setting further bypasses get_client_ip(). The attacker targets the authentication flow and must send many requests, each carrying a rotated spoofed IP. LIMITING FACTORS: high attack complexity (AC:H) because reliable bypass depends on the site's proxy/XFF trust configuration the attacker cannot control; correctly configured XFF handling neutralizes it; impact is confined to defeating rate-limiting to enable brute-force (confidentiality-limited), with no direct integrity or availability effect; the vendor considers this working-as-intended and no patched version is merged. |
| Impact | This is a low real-world priority despite public POC availability. The CVSS 4.0 vector (2.9, AV:N/AC:H/AT:N/PR:N/UI:N/VC:L) correctly captures a network-reachable but high-complexity weakness with only limited confidentiality impact and no integrity or availability impact. The core issue is that get_client_ip() in saleor/account/throttling.py trusts the X-Forwarded-For header, letting an attacker rotate spoofed IP values to evade Saleor's per-IP authentication throttling and mount credential brute-force - this is a throttling/rate-limit bypass (CWE-307), not the 'Information Disclosure' its tag claims. A public POC exists (zast-ai bruteforce.md), which is an exploit-code signal (E:P), but this must NOT be conflated with active exploitation: there is no CISA KEV listing and no EPSS score in the input, consistent with a niche, low-interest issue rather than mass exploitation. Two signals limit real risk and pull the score down: (1) the vendor explicitly disputes this as working-as-intended ('Saleor expects XFF to be configured properly'), and (2) the project's own issue #19203 concedes IP can be spoofed 'in most deployments,' so exploitability hinges on how the reverse proxy / XFF trust chain is configured. AC:H is justified because reliable bypass depends on a proxy or XFF-handling misconfiguration the attacker does not control. The fix (RFC 7239 right-to-left hop selection) is proposed but still UNMERGED, so no patched version can be cited yet. |
| Exploit ScenarioDerived | An attacker points a credential brute-force tool at Saleor's login/token GraphQL mutation and injects a fresh, spoofed X-Forwarded-For value on each request. Because get_client_ip() trusts that header, the per-IP throttling counter never accumulates against the real source, so the attacker keeps guessing passwords past the intended lockout. A public POC (zast-ai bruteforce.md) demonstrates the technique, but success is high-complexity and depends on the deployment's proxy/XFF trust configuration. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 18, 2026
Missing rate-limit enforcement in Saleor's authentication throttling allows attackers to defeat brute-force protection by spoofing the client IP used as the throttle key, and publicly available exploit code exists. Saleor versions up to and including 3.20.118, 3.21.54, 3.22.47, and 3.23.14 are affected: get_client_ip() in saleor/account/throttling.py trusts a client-supplied X-Forwarded-For value when the deployment does not sanitize or pin that header, so an attacker who rotates spoofed IPs across repeated login attempts is never throttled. The vendor disputes the report as working-as-intended, the proposed fix (right-to-left RFC 7239 hop selection) remains unmerged, and the project's own issue #19203 concedes 'IP can be spoofed in most deployments'; impact is limited to weakening authentication throttling (C:L) with no integrity or availability effect, so this is a low real-world priority despite the public POC.
RemediationAI
No vendor-released patch identified at time of analysis: Saleor's maintainers classify the behavior as working-as-intended, the project's proposed fix (right-to-left RFC 7239 hop selection in get_client_ip) is still unmerged, and the issue is tracked at https://github.com/saleor/saleor/issues/19203, so remediation must come from deployment hardening rather than a version upgrade. The primary compensating control is to make the client IP non-spoofable at the edge: configure your reverse proxy or load balancer to strip any inbound X-Forwarded-For and set its own authoritative value (e.g. overwrite XFF with the real peer address, or pass the client address in a dedicated trusted header), and correspondingly review the Saleor REAL_IP_ENVIRON-style setting so it points only at a header the proxy guarantees; the trade-off is that layered proxies and CDNs require careful hop accounting or legitimate client addresses will be recorded incorrectly. If XFF cannot be pinned (multi-tenant CDN fronting, third-party gateways), add defense-in-depth rate limiting and lockout at the application layer independent of get_client_ip - per-account attempt counters, progressive delays, or CAPTCHA on the login mutation - accepting the usability cost of occasional false lockouts on shared NAT addresses. As a lower-confidence stopgap, network-level throttling by source address at the WAF/edge provides some protection but is evaded by distributed sources and cannot distinguish legitimate heavy traffic; monitoring for many distinct apparent source IPs hitting the authentication flow is a useful detection signal even where prevention is incomplete. Details and the public proof-of-concept are published at https://github.com/zast-ai/vulnerability-reports/blob/main/saleor/bruteforce.md and https://vuldb.com/vuln/407477.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is a CWE-307 (Improper Restriction of Excessive Authentication Attempts) weakness in Saleor, a Python/Django GraphQL e-commerce platform. Saleor's login throttling derives its rate-limit key from get_client_ip() in saleor/account/throttling.py, which reads a client address from request headers rather than from a trusted, proxy-pinned source. In deployments where Saleor sits behind a reverse proxy or load balancer and the X-Forwarded-For header is neither stripped nor overwritten at the edge, an attacker can set XFF to an arbitrary value per request, making every login attempt appear to originate from a distinct address and rendering the throttle ineffective. The project's issue #19203 further notes that a REAL_IP_ENVIRON-type setting bypasses get_client_ip() entirely, extending the exposure to configurations that trust a proxy-provided environment variable. The proposed remedy - selecting the correct hop from the right-hand side of the XFF chain per RFC 7239 - has not been merged, so the trust decision is left to each deployment's reverse-proxy configuration. CVSS 4.0 scores this 2.9 (AV:N/AC:H/PR:N/UI:N/VC:L) and the independent 3.1 assessment concurs: AC:H reflects that reliable bypass depends on the target's XFF trust posture, which the attacker cannot control, and correctly configured XFF handling neutralizes the issue.
Know when Saleor gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
Network-reachable and unauthenticated (AV:N/PR:N) but AC:H since bypass depends on proxy/XFF misconfiguration; only a throttling bypass aiding brute-force, so C:L/I:N/A:N.
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
Lifecycle Timeline
3DescriptionCVE.org
A vulnerability was determined in Saleor up to 3.20.118/3.21.54/3.22.47/3.23.14. This vulnerability affects the function get_client_ip of the file saleor/account/throttling.py. Executing a manipulation can lead to improper restriction of excessive authentication attempts. The attack can be executed remotely. The attack requires a high level of complexity. It is stated that the exploitability is difficult. The exploit has been publicly disclosed and may be utilized. The projects own issue #19203 internal ticket admits "IP can be spoofed in most deployments" and that its REAL_IP_ENVIRON-type setting bypasses get_client_ip; fix (right-to-left RFC 7239 hop selection) proposed but still unmerged. The vendor explains within an email, that "[t]his is not a vulnerability, this is working at intended, Saleor expects XFF to be configured properly".
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Missing Authorization in GitHub repository saleor/saleor prior to 3.1.2. Rated medium severity (CVSS 6.5), this vulnerab
Cross-site Scripting (XSS) - DOM in GitHub repository saleor/react-storefront prior to c29aab226f07ca980cc19787dcef101e1
Saleor Issue was introduced by merge commit: e1b01bad0703afd08d297ed3f1f472248312cc9c. Rated medium severity (CVSS 5.3),
In Mirumee Saleor 2.7.0 (fixed in 2.8.0), CSRF protection middleware was accidentally disabled, which allowed attackers
Account pre-registration hijacking in Saleor's GraphQL `accountRegister` and `confirmAccount` mutation flow allows an un
Denial of service affects Saleor e-commerce platform versions 2.0.0 through 3.22.x via unlimited GraphQL query batching.
Unauthenticated attackers can exploit an insecure direct object reference vulnerability in Saleor e-commerce platform ve
GraphQL query complexity abuse in Saleor e-commerce platform enables unauthenticated denial-of-service through alias-bas
Broken authorization in Saleor's centralized GraphQL permission utility allows unauthenticated callers to silently modif
Saleor Storefront is software for building e-commerce experiences. Rated medium severity (CVSS 6.5), this vulnerability
In Saleor Storefront before version 2.10.3, request data used to authenticate customers was inadvertently cached in the
Saleor e-commerce platform (versions 2.10.0 through 3.23.0a2) contains an authentication bypass vulnerability in the acc
Exploit-DB