🐦🔥 Platform Overview
The target platform (referred to in this write-up as ShopX) is massive global e-commerce platform that operates across dozens of countries (TLDs) like .com, .de, .no, etc. It allows users to purchase everything. With such a massive user base, managing communication and email preferences (Newsletters, Deals, etc.) is a core part of their user engagement workflow.
Each regional website serves localized content (language, country, marketing preferences) while relying on shared backend services for common functionalities.
🐦🔥 Initial Goal
My initial objective was to understand how email preferences are managed across the platform and whether those preferences were:
- Scoped per domain
- Or centrally managed across all ShopX domains
At this stage, there was no assumption of a vulnerability, only an interest in mapping how the system handles email-related settings.
🐦🔥 Early Reconnaissance Attempts → Searching for the Email Identifier (Dead Ends)
While intercepting requests related to email preference updates, I noticed a parameter named emailaddress:
The value did not resemble a plain email address. Instead, it appeared to be a short, opaque, URL-safe string — likely a hash identifier.
emailaddress=E-5dlr8ozMNtk0brg90NSsxLs64nUaBFBefore identifying the actual attack vector, I attempted multiple common approaches to understand and manipulate the emailaddress parameter.
1. Plaintext Email Substitution
My first attempt was to check whether the backend accepted the email address in plaintext format instead of the opaque identifier.
I replaced the original emailaddress value with a standard email address, for example:
emailaddress=test@example.com➡️ Result:
- The request was rejected
- No preference changes were applied
This confirmed that the backend strictly expects a specific hashed format and does not accept raw email values.
2. Parameter Pollution Attempts
Next, I tested whether parameter pollution could influence how the backend resolves the email identifier.
Examples included:
emailaddress=E-5dlr8ozMNtk0brg90NSsxLs64nUaBF&emailaddress=test@example.com
emailaddress=test@example.com&emailaddress=E-5dlr8ozMNtk0brg90NSsxLs64nUaBF➡️ Result:
- The backend did not process any of the supplied
emailaddressvalues
Neither the hashed identifier nor the plaintext email was accepted
- No preference updates were applied
As a result, parameter pollution was ruled out, and the issue was confirmed to be unrelated to input parsing or parameter precedence.
3. Endpoint Enumeration
I reviewed the majority of publicly accessible endpoints related to:
- Account management
- Newsletter subscription
- Profile updates
- Marketing preferences
Despite extensive inspection, no endpoint exposed the email hash directly, nor did any endpoint allow generating it for an arbitrary email address.
4. Web Archive & Historical Data
Next, I searched for potential historical leaks or deprecated endpoints using:
- Web archive services (Wayback Machine and Common Crawl)
- JavaScript files
The goal was to identify:
- Hardcoded examples
- Legacy endpoints
- Debug parameters
➡️ Result:
No references to the emailaddress hash format were found.
At this point, the identifier appeared well-hidden and not trivially obtainable.
🐦🔥 The "Aha!" Moment: Regional Synchronization
I realized that Shopx doesn't require email verification to create an account. You can register, and you are immediately logged in then make email preference without need to it.
I also noticed that the preferences subdomain cloud.email.shopx.com is shared across all regional versions of the site in iframe.
Although the vulnerable endpoint is hosted on a separate subdomain, it is embedded via iframe and actively used by multiple in-scope domains. Therefore, the host is functionally in-scope and part of the affected application workflow.
POST /iframe_prod?emailaddress=E-5dlr8ozMNtk0brg90NSsxLs64nUaBF&country=NO&language=nb&output=embed HTTP/1.1
Host: cloud.email.shopx.com
submitted=true&Birthday=yes&Newsletter=yes&Deals_discounts=yes&BestSellers=yes&Save+preferences= Response: 500 Internal Server Error (But the change was reflected instantly on the account).
🚨This led me to a theory: Does the same email produce the same hash regardless of the country domain?
🐦🔥 The Discovery & Exploitation
The vulnerability lies in the fact that the system generates the same "Deterministic Hash" for an email address globally, and because no verification is required, an attacker can "generate" a victim's hash on demand.
Step-by-Step Walkthrough:
- The Target: Let's say the victim is
test@example.comonshopx.com. I don't have their hash. - The Bypass: I go to a different regional domain where the victim hasn't registered , such as
shopx.no. - Account Creation: I register a new account using the victim's email (
test@example.com) onshopx.no. Since no verification is needed, I am now "the owner" of this email on the Norwegian branch. - Harvesting the Hash: I navigate to the Email Preferences on the Norwegian site. I intercept the request and — Bingo! — the
emailaddresshash is there. - Cross-Regional Attack: I take that hash and use it in a request directed at the
country=US&language=en. Even though I don't have the victim's password on the.comsite, the preference server accepts the hash as a "Direct Object Reference."
POST /iframe_prod?emailaddress=E-5dlr8ozMNtk0brg90NSsxLs64nUaBF&country=US&language=en&output=embed HTTP/1.1
Host: cloud.email.shopx.com
submitted=true&Birthday=yes&Newsletter=yes&Deals_discounts=yes&BestSellers=yes&Save+preferences=🐦🔥 The General Proof of Concept (PoC)
By sending the following request, I successfully disabled all email notifications for the victim's primary account For example in shopx.com:
POST /iframe_prod?emailaddress=[Stolen_Hash_From_Other_Domain]&country=US&language=en&output=embed HTTP/1.1
Host: cloud.email.shopx.com
submitted=true&Birthday=yes&Newsletter=yes&Deals_discounts=yes&BestSellers=yes&Save+preferences=Response: 500 Internal Server Error (But the change was reflected instantly on the victim's account).
🚨 This process can be performed on any other domain by simply changing the country and language parameters.
🐦🔥 Risk
- Mass Unsubscribe: An attacker could script this to unsubscribe thousands of users if they have a list of emails.
- Cross-domain account impact without authentication
- Forced opt-in / opt-out of marketing communications
- Privacy Violation: Knowing the hash allows an attacker to see the current subscription status of a user, leading to "Account Discovery."
- Abuse of the email system for marketing manipulation or user harassment
- Abuse of centralized email infrastructure
Final Thoughts
Authorization issues in centralized services are often overlooked because each individual application appears to behave correctly on its own.
However, when multiple domains rely on the same backend without proper isolation, small trust assumptions can turn into cross-domain security flaws.
In this case, the issue did not stem from weak hashing, parameter manipulation, or input validation bypasses — but from reusing a valid identifier across different security contexts without enforcing ownership or domain-level authorization.
😔 After identifying and documenting this vulnerability with a clear PoC, I submitted it to the organization's bug bounty program. Unfortunately, the report was marked as Out of Scope, resulting in a −3 point penalty, despite the vulnerable functionality being embedded and actively used across in-scope domains. This outcome felt particularly unfair given the real, in-scope security impact.
