Saleor up to 3.20.118/3.21.54/3.22.47/3.23.14 throttling.py get_client_ip excessive authentication

Summaryinfo

A vulnerability was found in Saleor up to 3.20.118/3.21.54/3.22.47/3.23.14. It has been rated as problematic. This issue affects the function get_client_ip of the file saleor/account/throttling.py. The manipulation leads to excessive authentication. This vulnerability is uniquely identified as CVE-2026-93650. The attack is possible to be carried out remotely. Moreover, an exploit is present. 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".

Detailsinfo

A vulnerability, which was classified as problematic, has been found in Saleor up to 3.20.118/3.21.54/3.22.47/3.23.14. This issue affects the function get_client_ip of the file saleor/account/throttling.py. The manipulation with an unknown input leads to a excessive authentication vulnerability. Using CWE to declare the problem leads to CWE-307. The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame, making it more susceptible to brute force attacks. Impacted is confidentiality.

The advisory is shared at github.com. The identification of this vulnerability is CVE-2026-93650. The exploitation is known to be difficult. The attack may be initiated remotely. No form of authentication is needed for a successful exploitation. Technical details as well as a public exploit are known. MITRE ATT&CK project uses the attack technique T1110.001 for this issue.

The exploit is available at github.com. It is declared as proof-of-concept. 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". 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.

There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Name

• Saleor

Version

• 3.20.118
• 3.21.0
• 3.21.1
• 3.21.2
• 3.21.3
• 3.21.4
• 3.21.5
• 3.21.6
• 3.21.7
• 3.21.8
• 3.21.9
• 3.21.10
• 3.21.11
• 3.21.12
• 3.21.13
• 3.21.14
• 3.21.15
• 3.21.16
• 3.21.17
• 3.21.18
• 3.21.19
• 3.21.20
• 3.21.21
• 3.21.22
• 3.21.23
• 3.21.24
• 3.21.25
• 3.21.26
• 3.21.27
• 3.21.28
• 3.21.29
• 3.21.30
• 3.21.31
• 3.21.32
• 3.21.33
• 3.21.34
• 3.21.35
• 3.21.36
• 3.21.37
• 3.21.38
• 3.21.39
• 3.21.40
• 3.21.41
• 3.21.42
• 3.21.43
• 3.21.44
• 3.21.45
• 3.21.46
• 3.21.47
• 3.21.48
• 3.21.49
• 3.21.50
• 3.21.51
• 3.21.52
• 3.21.53
• 3.21.54
• 3.22.0
• 3.22.1
• 3.22.2
• 3.22.3
• 3.22.4
• 3.22.5
• 3.22.6
• 3.22.7
• 3.22.8
• 3.22.9
• 3.22.10
• 3.22.11
• 3.22.12
• 3.22.13
• 3.22.14
• 3.22.15
• 3.22.16
• 3.22.17
• 3.22.18
• 3.22.19
• 3.22.20
• 3.22.21
• 3.22.22
• 3.22.23
• 3.22.24
• 3.22.25
• 3.22.26
• 3.22.27
• 3.22.28
• 3.22.29
• 3.22.30
• 3.22.31
• 3.22.32
• 3.22.33
• 3.22.34
• 3.22.35
• 3.22.36
• 3.22.37
• 3.22.38
• 3.22.39
• 3.22.40
• 3.22.41
• 3.22.42
• 3.22.43
• 3.22.44
• 3.22.45
• 3.22.46
• 3.22.47
• 3.23.0
• 3.23.1
• 3.23.2
• 3.23.3
• 3.23.4
• 3.23.5
• 3.23.6
• 3.23.7
• 3.23.8
• 3.23.9
• 3.23.10
• 3.23.11
• 3.23.12
• 3.23.13
• 3.23.14

Website

• Product: https://github.com/saleor/saleor/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Submitinfo

Accepted

• Submit #933655: saleor <=3.23.14 Improper Restriction of Excessive Authentication Attempts (by ZAST.AI)

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion