CVE-2026-93650

Executive Summary

CVE-2026-93650 is an improper restriction of excessive authentication attempts (CWE-307) in the Saleor e-commerce platform, affecting versions up to and including 3.20.118, 3.21.54, 3.22.47, and 3.23.14. The flaw resides in the get_client_ip function within saleor/account/throttling.py, which derives a client's identity for authentication throttling from spoofable request headers, allowing an attacker to evade rate-limiting controls during credential-stuffing or brute-force attacks. The vendor has classified this as intended behavior, and no patch is currently available, leaving affected deployments reliant on reverse-proxy and header-configuration hardening.

Technical Analysis

The vulnerability is an instance of CWE-307, Improper Restriction of Excessive Authentication Attempts. Rate-limiting and authentication-throttling controls function correctly only if the throttle key reliably identifies a unique client. In Saleor, that key is produced by get_client_ip in saleor/account/throttling.py. The NVD description states the function is affected by a manipulation that "can lead to improper restriction of excessive authentication attempts," and the vendor's own issue tracker (#19203) explicitly admits that "IP can be spoofed in most deployments." This means the value returned by get_client_ip — and therefore the throttling bucket that authenticates login attempts — can be influenced by attacker-controlled input.

Two deployment conditions are relevant. First, when the application trusts forwarded-address headers (X-Forwarded-For or RFC 7239 Forwarded) without a correctly configured trusted-proxy chain, an attacker can vary the apparent source IP per request, effectively rotating the throttle key on each authentication attempt. Second, the vendor notes that a REAL_IP_ENVIRON-type setting fully bypasses get_client_ip, meaning on installations using that configuration the throttling logic does not receive the intended client identifier at all.

The proposed but unmerged fix is right-to-left RFC 7239 hop selection — i.e., selecting the correct hop from the forwarding chain — which would restore trustworthy client identification when a well-configured reverse proxy sits in front of Saleor. Until that lands, the security of the authentication throttle is contingent entirely on correct edge-proxy configuration, which the vendor asserts is the administrator's responsibility ("Saleor expects XFF to be configured properly").

The attack surface is the Saleor GraphQL authentication endpoints reachable over the network. The CVSS 3.1 vector is AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N (3.7 Low): network-reachable, high attack complexity (correctness of spoofing depends on deployment), no privileges or user interaction required, and confined mostly to a low confidentiality impact (account compromise enables data access). The "high complexity" rating reflects that exploitation requires the target's proxy/header configuration to be permissive.

Exploitation Scenarios

No public exploit code or Nuclei template is available; the following chain is inferred from the vulnerability class (CWE-307) and the header-spoofing mechanism described in the NVD record and vendor issue. Specific payloads are not disclosed.

1. Reconnaissance / target identification. The attacker identifies a Saleor deployment and locates its authentication flow (the login endpoint). Using the Shodan dorks above, exposed Saleor instances can be fingerprinted by title, HTML footprint, or the presence of the /graphql/ endpoint.

2. Triggering the flaw. The attacker submits authentication attempts while manipulating the forwarded-address header that get_client_ip consumes. Because get_client_ip derives the throttle key from a spoofable source, each request can present a different apparent IP, causing Saleor's per-IP throttling to treat every attempt as coming from a distinct client. This defeats the "excessive authentication attempts" restriction entirely. On deployments using the REAL_IP_ENVIRON-type setting, the throttle is bypassed outright.

3. Payload / execution method (class level). The attack is a rate-limit-evading credential attack: the adversary iterates credential guesses (credential stuffing against leaked username/password pairs, or brute force of weak passwords) at a rate the throttle was designed to prevent. No memory-corruption or code-execution primitive is involved; the "exploit" is the systematic rotation of the throttle key.

4. Post-exploitation impact. Successful guessing yields an authenticated account. Depending on the role compromised — customer or administrator — the attacker gains access to that account's data and actions; administrative compromise expands impact to order, customer, and configuration data. The CVSS confidentiality component (C:L) captures this account/data exposure; integrity and availability are rated as no impact.

Impact Assessment

The direct impact is a weakened authentication barrier: pervasive credential-stuffing and brute-force campaigns are no longer constrained by IP-based throttling. The CVSS 3.1 base score is 3.7 (Low) with vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N. Subscore interpretation:

• AV:N (Network) — exploitable remotely against any reachable Saleor instance.
• AC:H (High) — success depends on permissive forwarded-header handling in the target's deployment.
• PR:N / UI:N — no prior credentials and no user interaction required.
• S:U (Unchanged) — impact is confined to the vulnerable component.
• C:L (Low) — primary impact is unauthorized access to account data; I:N/A:N — no integrity or availability impact scored.

Business impact centers on account takeover at scale: fraud, unauthorized order/customer data access, and downstream abuse of compromised accounts. EPSS has not yet been scored by FIRST.org, so no probabilistic exploitation forecast is available; the exploit has nonetheless been publicly disclosed and "may be utilized." CISA KEV listing: NO. No affected-version, OSV package, vendor-fix, or workaround data was supplied by tracked sources, so remediation must be treated as configuration-based and vendor-dialog-driven rather than patch-based.

Detection Guidance

Detection for this CVE is inherently behavioral rather than signature-based, because the exploit abuses legitimate authentication requests with varied forwarding headers. Correlate authentication attempts with header anomalies (frequent X-Forwarded-For / Forwarded changes from the same connection or TLS session), elevated login failure rates, and impossible IP churn.

Sigma Rule

title: Saleor Authentication Throttle Evasion via Spoofed Forwarded IP (CVE-2026-93650)
id: 8c4a1f2e-7b3d-4a96-9e21-2f5b6d0c9a11
status: experimental
description: Detects Saleor login attempts where the client IP used by get_client_ip changes across requests, indicative of CWE-307 throttle evasion.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-93650
author: valtersit.com
date: 2026/01/01
logsource:
  product: saleor
  service: authentication
detection:
  selection:
    event_action|contains:
      - 'login'
      - 'authenticate'
    outcome: 'failure'
  header_anomaly:
    forwarded_ip|count() > 10
  timeframe: 5m
  condition: selection and header_anomaly
fields:
  - client_ip
  - forwarded_ip
  - account
level: medium
tags:
  - attack.t1110
  - cve.2026.93650

YARA Rule

rule CVE_2026_93650_Saleor_Throttle_Evasion
{
    meta:
        description = "Detects Saleor build/marker referencing vulnerable throttling module CVE-2026-93650"
        author = "valtersit.com"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-93650"
        cve = "CVE-2026-93650"
    strings:
        $throttle = "saleor/account/throttling.py" ascii
        $fn       = "get_client_ip" ascii
        $xff      = "X-Forwarded-For" ascii
        $fwd      = "Forwarded" ascii
        $realip   = "REAL_IP_ENVIRON" ascii
    condition:
        uint16(0) == 0x0A0D or $throttle or ($fn and 1 of ($xff, $fwd, $realip))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-93650 Saleor Auth Throttle Evasion - Excessive Forwarded Header Auth Attempts"; flow:established,to_server; http.method; content:"POST"; http.header; content:"X-Forwarded-For"; http.uri; content:"graphql"; threshold:type both, track by_src, count 20, seconds 60; classtype:attempted-recon; sid:202693650; rev:1; reference:cve,2026-93650; metadata:service http;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [ authentication where event.outcome == "failure" and event.action in ("login","authenticate") ]
  [ authentication where event.outcome == "failure" and event.action in ("login","authenticate")
    and not source.ip in ("10.0.0.0/8","192.168.0.0/16","172.16.0.0/12") ]

Splunk SPL Query

index=web sourcetype=saleor OR sourcetype=django
| search (action="login" OR action="authenticate") outcome="failure"
| eval fwd=coalesce(x_forwarded_for, forwarded, real_ip)
| bin _time span=5m
| stats dc(fwd) as distinct_ips count as attempts values(src) as sources by user, _time
| where distinct_ips >= 10 AND attempts >= 15
| sort - distinct_ips

Wazuh OSSEC Rule

<group name="saleor,authentication,cve-2026-93650">
  <rule id="202693" level="10">
    <decoded_as>json</decoded_as>
    <field name="action">login|authenticate</field>
    <field name="outcome">failure</field>
    <description>CVE-2026-93650: Saleor authentication failures with spoofable forwarded IP</description>
    <mitre><id>T1110</id></mitre>
  </rule>
  <rule id="202694" level="12" frequency="20" timeframe="300">
    <if_matched_sid>202693</if_matched_sid>
    <same_source_ip />
    <description>CVE-2026-93650: Excessive Saleor auth failures indicating throttle evasion / brute force</description>
    <mitre><id>T1110</id></mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED) — no patch evidence from any tracked source; affected-version and OSV data are empty, and the proposed fix (right-to-left RFC 7239 hop selection) remains unmerged per vendor issue #19203. The vendor considers this intended behavior and places responsibility for correct forwarded-header configuration on the administrator.

1. Immediate mitigations.

   • Configure the reverse proxy/load balancer to control which forwarded-address headers reach Saleor. Strip client-supplied X-Forwarded-For and RFC 7239 Forwarded headers at the edge and let only trusted proxies set them.
   • Do not deploy Saleor with the REAL_IP_ENVIRON-type setting unless the environment is fully trusted, since it bypasses get_client_ip.
   • Ensure all internet-facing traffic traverses a trusted proxy that normalizes client IPs, and restrict direct access to the application port.
   • Strengthen authentication beyond IP throttling: multi-factor authentication, account lockout tied to the account (not just the source IP), CAPTCHA, and monitoring of distributed credential-stuffing patterns.

2. Patch / upgrade steps. No vendor patch exists as of this report. Track the Saleor issue #19203 thread for the proposed right-to-left RFC 7239 hop-selection fix and apply it once merged and released. Until then, apply the configuration hardening above as the effective control.

3. Long-term hardening. Adopt an allow-list model for trusted proxy hops; validate the full forwarding chain rather than a single header; implement account-based and global authentication rate limits that do not rely solely on client IP; deploy anomaly detection for distributed brute-force; and monitor upstream releases for the eventual CVE-2026-93650 remediation.

References

1. NVD — CVE-2026-93650: https://nvd.nist.gov/vuln/detail/CVE-2026-93650
2. MITRE CWE-307 — Improper Restriction of Excessive Authentication Attempts: https://cwe.mitre.org/data/definitions/307.html
3. MITRE ATT&CK T1110 — Brute Force: https://attack.mitre.org/techniques/T1110/
4. Saleor project issue #19203 (vendor admission: "IP can be spoofed in most deployments"; proposed unmerged fix): https://github.com/saleor/saleor/issues/19203
5. FIRST EPSS — not yet scored for this CVE (verified, no value fabricated); CISA KEV — not listed.

No threat actor campaigns or confirmed exploit-in-the-wild activity are reported in the supplied data; the NVD description states only that the exploit "has been publicly disclosed and may be utilized."