Accessing the Realme Customer Support Platform

Last year, I discovered multiple significant security flaws in the Taiwanese customer support platform of Realme, a big Chinese smartphone manufacturer owned by OPPO. These issues exposed both customer data and internal support accounts, creating a dangerous combination of risks. The platform is now unreachable, so it is time for a writeup.

The First Vulnerability: Unauthenticated API Access

The first issue was found in the customer support API hosted on a server belonging to the manufacturer. The API, which lacked proper authorization mechanisms, allowed anyone to access customer support tickets simply by visiting a specific URL. This meant that an attacker could view sensitive customer information without needing any form of authentication.

The API endpoint in question was structured as follows:

https://[HOST]/api/orders/[NUM]/messages?accept=true

Here, [NUM] represented a unique identifier for a support ticket. By substituting [NUM] with a random or sequential number, an attacker could retrieve detailed information about any customer support ticket.

Exploitation

Exploiting this vulnerability was alarmingly straightforward:

1. Visit the URL: https://[HOST]/api/orders/[NUM]/messages?accept=true
2. Replace [NUM] with a valid ticket ID (which could be guessed or brute-forced).

For example, visiting https://[HOST]/api/orders/21480/messages?accept=true would return the details of a specific support ticket, including the customer’s email address, full name, phone number, and the products they had purchased.

Risk

This was a clear case of a major customer data leak, exposing:

• Email addresses for phishing attacks.
• Full names and phone numbers for social engineering.
• Product information to fuel scams or fraudulent warranty claims.
• Support conversations that could damage customer trust if leaked.

The Second Vulnerability: Blind XSS in Support Messaging

In addition to the API flaw, I identified a blind cross-site scripting (XSS) vulnerability in the platform’s support messaging system.

Incoming emails and Facebook messages from customers were automatically integrated into the internal ticketing system. By sending a maliciously crafted email containing a blind XSS payload, an attacker could cause their payload to execute in the browser of any support engineer who viewed the ticket.

Exploitation

Normally, HttpOnly cookies would block traditional session theft via JavaScript. However, the Realme server was running in debug mode, a critical misconfiguration.

When the payload intentionally triggered an error i.e. a request that would return a HTTP 500 response, the debug response returned a full stack trace containing sensitive information, including:

• Session cookies (despite HttpOnly protection, since they were exposed in the debug output)
• JWT authorization headers
• Other sensitive HTTP headers

The contents of the response can be sent back to the callback server (Burp Collaborator or ProjectDiscovery’s Interactsh) via a POST request (maybe also base64-encoded). This turned a blind XSS into a complete account takeover vulnerability. An attacker could steal support engineer sessions and gain access to many functions.

Report message:

Additionally, through the blind XSS I can access things such as:

1. Employee usernames REDACTED, REDACTED, REDACTED, REDACTED, 
REDACTED (see attachment bd7fa4aa-03fb-4318-8662-62b9937ecfa8.png and 
13b7b338-8310-42fc-a1b4-8d7d786e839a.png)

2. Authorization tokens

eyJ0eXAiOiJYr[...]FWrrdFMIRCbnT4zAQ for user REDACTED

eyJ0eXAiOiJKV[...]qFiYM07MxEyDI6ce_nBw for user REDACTED

which allows me to access certain API endpoints (see attachments api-chat-waiting.png).

How These Issues Could Have Been Prevented

Both vulnerabilities reflect common security oversights:

1. Authentication & Authorization: Restrict API access with strong authentication (JWT, OAuth).
2. Sanitization: Filter and sanitize user input from emails to prevent XSS.
3. Disable Debug Mode in Production: Debug features should never be active on live servers.
4. Use Non-Sequential IDs: Randomize identifiers to reduce the risk of enumeration.

Handling of the report by OPPO

The report was sent in May 2024. The API issue was confirmed within days, in contrast to the blind XSS vulnerability, which was never addressed properly. Because of poor communication by the vendor, they failed to understand the severity of the issue. Both issues remained unfixed for more than a year, up until now.

The combination of these flaws showed how multiple issues can compound into something far more dangerous. An unauthenticated API leak already exposed customer data at scale, but coupled with blind XSS and debug mode leakage, attackers could escalate into internal account compromise and long-term access to the support system.

Conclusion

These discoveries underscore the urgent need for companies to take a holistic approach to security, covering not just their APIs, but also deployment configurations, input handling, and monitoring. Realme’s case highlights how even large organizations can fall into dangerous oversights that jeopardize both customers and internal staff.

As always, these vulnerabilities were responsibly disclosed to the affected organization, and remediation steps were expected to be taken to protect users.