EUVD-2026-20534Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from Vendor (GitHub_M) · only source for this CVE.
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
4DescriptionCVE.org
Saleor is an e-commerce platform. From 2.10.0 to before 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118, a business-logic and authorization flaw was found in the account email change workflow, the confirmation flow did not verify that the email change confirmation token was issued for the given authenticated user. As a result, a valid email-change token generated for one account can be replayed while authenticated as a different account. The second account’s email address is then updated to the token's new_email, even though that token was never issued for that account. This vulnerability is fixed in 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118.
AnalysisAI
Saleor e-commerce platform (versions 2.10.0 through 3.23.0a2) contains an authentication bypass vulnerability in the account email change workflow that allows authenticated attackers to change another user's email address by replaying a valid email-change confirmation token issued for a different account. The flaw stems from the confirmation flow's failure to verify that the token was issued for the requesting user, enabling token reuse across accounts with low attack complexity. The vulnerability affects millions of potential e-commerce deployments and is fixed in versions 3.23.0a3, 3.22.47, 3.21.54, and 3.20.118; no public exploit code or active exploitation in the wild has been identified at the time of analysis.
Technical ContextAI
This vulnerability is rooted in CWE-285 (Improper Authorization), specifically a broken access control flaw in Saleor's account email change workflow. When a user requests an email change, the system generates a confirmation token containing the new email address. However, the token validation logic fails to bind the token to the specific user account that initiated the request. An authenticated attacker can intercept or obtain a valid email-change token (through legitimate means or social engineering) and replay it while authenticated as a different account. The confirmation endpoint accepts the token without verifying that it was issued for the currently authenticated user, allowing the attacker to modify the target account's email. This is a horizontal privilege escalation attack variant where authentication is present (satisfying PR:L requirement) but authorization logic is fundamentally broken. The CPE cpe:2.3:a:saleor:saleor identifies all Saleor installations, with affected versions spanning from 2.10.0 through multiple release branches (3.20.x, 3.21.x, 3.22.x, and 3.23.0-alpha).
RemediationAI
Upgrade immediately to Saleor 3.23.0a3, 3.22.47, 3.21.54, or 3.20.118 depending on your current version line. These patched versions restore proper token-to-user binding in the email change confirmation flow, ensuring tokens can only be redeemed by the account for which they were issued. The fixes are available across four separate version branches via https://github.com/saleor/saleor/security/advisories/GHSA-hwph-9537-mc3p. If immediate patching is not possible, implement temporary monitoring for suspicious email change requests (e.g., changes initiated from different IP addresses or sessions than the confirmation token generation) and consider adding additional email verification steps such as notifying the old email address before any change takes effect. Review the specific commits referenced (7be352fa, cdb66da9, d6a94e95, e42aa4d6, f0371bdd) in the upstream repository to understand the token validation improvements applied.
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
Authenticated staff users in Saleor e-commerce platform versions 3.0.0 through 3.22.26 can upload malicious HTML and SVG
Same weakness CWE-285 – Improper Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today