Key findings

• We analyzed RedNote on Android and iOS for network security issues and found that all versions of RedNote fetch viewed images and videos over HTTP, which enables network eavesdroppers to learn exactly what content users are browsing.
• Some versions of RedNote contain a vulnerability that enables network attackers to learn the contents of any files that RedNote has permission to read on the users’ devices. This issue was introduced by an upstream software development kit (SDK) used by RedNote, NEXTDATA, but is not present in Android versions downloaded from the Google Play Store nor in the iOS version.
• All versions of RedNote that we analyzed also transmitted insufficiently encrypted device metadata, sometimes over TLS without certificate validation, enabling network attackers to learn device and network metadata, such as device screen size and the mobile network carrier. This issue was introduced by an upstream SDK, MobTech.
• We responsibly disclosed the relevant issues to NEXTDATA on November 13, 2024, to MobTech on November 26, 2024, and to RedNote on January 16, 2025. At the time of publication, no party had responded to our disclosures.
• All the issues we discovered could be mitigated through the use of TLS. Yet again, this work highlights the importance of using well-supported encryption implementations.

Introduction

RedNote, or XiaoHongShu, is a popular Chinese social media application with upwards of 300 million active users. RedNote is notable not just due to its popularity within China, but especially due to its popularity with Chinese tourists travelling internationally, the Chinese diaspora, and recently, Americans. In January 2025, the application gained global attention as approximately three million US users joined RedNote in the wake of the US government’s decision to ban TikTok. 

We analyzed RedNote as a part of our ongoing work reviewing popular applications for network security issues. Other researchers and media outlets have also taken interest in the application’s security, censorship, and privacy properties after its surge in popularity among US users. After we disclosed the vulnerabilities to all relevant vendors, including RedNote, NEXTDATA, and MobTech, another security researcher published his findings which included some, but not all, of the issues we disclose in this report.

First, we found that all versions of RedNote we analyzed fetch viewed images and videos without any encryption, which enables network eavesdroppers to learn exactly what content users are browsing. Second, we found a vulnerability on some versions of RedNote for Android that enables network attackers to learn the contents of files on users’ devices. This issue was introduced by an upstream software development kit (SDK) used by RedNote, NEXTDATA (also known as 数美 or Shumei), for “fraud prevention.” Finally, we found that all versions of RedNote we analyzed transmit insufficiently encrypted device metadata, sometimes over TLS without certificate validation. This final issue was also introduced by an upstream analytics SDK, MobTech.

This work is primarily a network security analysis, which evaluates attacks that would allow Internet service providers (ISPs), virtual private networks (VPNs), or other network attackers to surveil RedNote users on their network. We did not perform any other security or privacy analysis and did not evaluate other forms of data collection (e.g., third-party tracking or first-party data collection by RedNote). In other words, our analysis does not concern whether certain user data is collected by RedNote and does not concern whether that data could be made available to the Chinese government via data access requests. Our analysis threat model primarily concerns whether any ISP, government, or network operator can surveil or attack RedNote users on their network. We focus on this particular threat model because RedNote is especially popular with Chinese tourists travelling abroad and the Chinese diaspora. The issues that we found make these users especially vulnerable to surveillance by non-Chinese governments, which might not already have methods to obtain data about those individuals.

We also did not perform a full security audit of RedNote and did not make any attempt to exhaustively find every security vulnerability in the software. This report outlines the issues we have discovered. However, the absence of our reporting of other vulnerabilities should not be considered evidence of their absence.

We discovered the NEXTDATA and MobTech issues in November 2024. We responsibly disclosed the issue to NEXTDATA on November 13, 2024, and to MobTech on November 26, 2024. After we did not receive any response, we then disclosed all relevant issues to RedNote on January 16, 2025. As of February 12, 2025, we have not received any responses. As neither RedNote, MobTech, nor NEXTDATA responded to our security disclosures, we have decided to make our findings public in accordance with our disclosure policy.

Methods

We originally analyzed and found issues with RedNote version 8.41.0, downloaded from the Xiaomi Mi Store, as tested on Android 14, in October 2024. We later re-confirmed the issues in February 2025 on RedNote version 8.69.3 as available on the RedNote website and the Xiaomi Mi Store and on RedNote version 8.59.2 from the Google Play Store. We also confirmed similar issues in RedNote version 8.69 as available on the Apple App Store.

We examined these applications using both static and dynamic analysis methods. We used jadx to statically analyze and decompile Dalvik bytecode; and IDA Pro to statically analyze and decompile native machine code. We used frida to dynamically analyze the application on Android. Finally, we used Wireshark to perform network traffic capture and analysis; and mitmproxy to manipulate network traffic in our proof-of-concept exploits.

Findings

In this section we detail three major issues we discovered relating to RedNote’s network security (see Table 2 for a summary). We close the section by discussing other miscellaneous issues we found in RedNote’s network security.

1. Users’ browsing behaviour observable to network eavesdroppers

Network eavesdroppers can observe users’ browsing behaviour on all versions of RedNote we analyzed.

All image and video data is loaded from RedNote content delivery network (CDN) servers over HTTP. Since RedNote is primarily a multimedia social media application, this means that network eavesdroppers can easily determine what content users are browsing on the application.

As a demonstration, we provide a screenshot of a sample network capture in Figure 1. The resource requests containing “/w/540” correspond with the video preview thumbnails displayed on the homepage. The final four requests in Figure 1 correspond precisely to videos and image posts that the user viewed, including an image that was loaded in a comment response to a post.

2. Users’ file contents readable by network attackers

Network attackers can read users’ filea contents on the Android versions of the application available for download on RedNote’s website and on the Mi Store, but not in the version downloaded from the Google Play Store or the iOS version. Network attackers can learn the contents of any files that RedNote has permission to read on the user’s device.

When an affected version of RedNote fetches a “configuration file,” it does so without proper encryption or authentication. A network adversary can alter the contents of this configuration file. RedNote then proceeds to run the commands specified in this configuration file and sends the response over the network. Although the response cannot be easily decrypted, an attacker could use the size of the returned payload as a side-channel to infer information about the result of the command run on the user’s device. We designed a proof-of-concept to demonstrate this attack.

This attack is enabled by an SDK called NEXTDATA or Shumei (数美), which is used by RedNote to identify the use of rooted or emulated devices. We disclosed this same vulnerability to Shumei via email on November 13, 2024, but, as of February 12, 2025, received no response.

NEXTDATA cloud configuration mechanism

The attack is enabled by the mechanism through which RedNote fetches and acts on a “cloud configuration file.” Based on the contents of this file, NEXTDATA uses this configuration to identify the use of emulated devices or the presence of rooting or other jailbreaking tools like Magisk. In this section, we describe the mechanism through which NEXTDATA downloads this configuration file.

We found that payloads contained in network requests received from http://fp-it.fengkongcloud.com/v3/cloudconf are encrypted using DES-ECB. Specifically, the “data” entry of the returned JSON object is encrypted using DES-ECB with the hard-coded key b'zaq1mko0'. In other words, it can be decrypted as DES_ECB_decrypt(data, b’zaq1mko0′). The JSON payload decrypted in this manner contains a field, risk_files, which contains a base64-encoded payload:

The risk_files payload is itself encrypted using AES-CBC. The key is effectively hardcoded — b'51996e9be805c9284e69bc7684800a26' — although it is computed as the first 32 ASCII bytes of the MD5 hex digest of b'smsdkshumeiorganizationflag', i.e., it is computed deterministically from a hardcoded value. The IV is also hardcoded: b'0102030405060708'. The risk_files entry, when base64-decoded, can then be decrypted using the hardcoded key and IV as AES_CBC_decrypt(risk_files, key, IV).

The following is an example of a payload decrypted in this manner:

[
  {
    "path": "file:///proc/self/maps",
    "words": [
      "/data/.+\\.so",
      ".*titan.so",
      ".*titan2.so",
      ".* rwxp .*"
    ],
    "type": "file",
    "key": "maps2",
    "option": "regex"
  },
...
]

This risk_files data is subsequently used to perform various checks from the application, including searching for the presence of files, or running regexes on files. The result from all of these checks is included in an encrypted payload in a subsequent request to http://fp-it.fengkongcloud.com/v3/profile/android. This request is encrypted with yet another custom encryption method, which uses an RSA-bootstrapped AES key. This encryption method has issues, but is not trivially decryptable. We describe this method in full, in the Appendix.

Proof-of-concept exploits

Since NEXTDATA uses static keys to encrypt the above payloads, any network attacker could derive the keys and other parameters required to decrypt and re-encrypt the payloads from within the app by reverse engineering it. We designed proof-of-concept attacks to inject and alter data into the risk_files field:

1. Modifying received rules to induce false positives and false negatives in the detection of “risky” files on users’ phones.
2. Performing a denial-of-service attack.
3. Reading contents of files on the user’s phone.

We accomplished (1) by modifying the rules that the user received to be triggered in different conditions than what the rules had originally intended. We accomplished (2) by modifying the rules that the user received to exploit denial-of-service vulnerabilities in the app’s regex engine. For example, we found that the patterns (((([a-f0-9]{1,100}){1,100}){1,100}){1,100}){1,100} and (((([a-f0-9]+)+)+)+)+ pegged victims’ CPUs when applied to files such as /proc/self/maps or /proc/cpuinfo. We expound on (3), the most significant of the three attacks, in the section below, which facilitates remote file access.

Remote file access

In this section, we describe our final proof-of-concept remote attack which uses the risk_files vulnerability to read the contents of files on a user’s phone. Since this field enables an attacker to inject any regex to run on any arbitrary set of files, an attacker could also inject risk_files data in order to detect the presence of any file that the application has permissions to read. Even without decrypting the /v3/profile/android network request, the attacker can observe the size of the payload as a side-channel to determine the presence of a file or whether a regex was run successfully. As a simple example, injecting the following into the risk_files field reveals to the network attacker whether <FILEPATH> is present on the user’s phone:

  {
    "path": "file://<FILEPATH>",
    "words": [".*"],
    "type": "file",
    "key": "xxx",
    "option": "regex"
  }

If <FILEPATH> exists on the phone, this regex generates a large number of matches, significantly inflating the encrypted payload size of the subsequent v3/profile/android request.

Not only can an attacker use the file size to identify the presence of files on the phone, an attacker can use the same side-channel to read the contents of a file. We designed a proof-of-concept attack that allows a network eavesdropper to read the BogoMIPS value from /proc/cpuinfo on the victim’s device. Although we cannot decrypt the client’s resulting transmission to the server, the attack works by transmitting 65536 regex patterns carefully constructed so that if the user’s BogoMIPS value is n, then n of these patterns will match. Since the app reports each match to the server, by coercing the user’s app into executing these patterns and reporting if they match, we are effectively leaking the BogoMIPS value in the length of the payload, as the payload’s length will be proportional to the magnitude of the BogoMIPS value. In our testing, we were able to exfiltrate the BogoMIPS value to the nearest whole BogoMIP, supporting any value from a range of 1 to 65536. However, the attack could be adapted to read different parts of any file that is accessible by the RedNote app. Testing our attack on two Android devices, the payload lengths transmitted by the app varied between 3.3 and 3.4MB.

In summary, any network attacker with a MITM position can read the contents of any file that RedNote has permissions to read on the user’s device.

3. Users’ device metadata available to network attackers

RedNote for Android and iOS both send device metadata using insufficient encryption. On the version of this application downloaded from the Google Play Store, these requests containing insecurely encrypted data are delivered over HTTP and not HTTPS. On the remaining Android versions that we analyzed and on the iOS version, though these requests are delivered over TLS, the RedNote application does not validate TLS certificates, enabling any network attacker with an active machine-in-the-middle (MITM) position to decrypt the underlying data. These requests are then additionally encrypted with an insecure encryption algorithm.

HTTPS POST requests for https://devc.zztfly.com/dinfo contain URL-encoded, base64-encoded payloads of encrypted data in the POST request body. This data is encrypted using standard AES-ECB with PKCS5 padding with the key b'sdk.commonap.sdk'. Here are snippets from a sample payload, captured from RedNote on iOS:

{"breaked":false,"dataStorage":127870980096,"mac":"02:00:00:00:00:00",
"datatime":1737492754724,"plat":2,"ram":3840327680,"factory":"APPLE",
"screensize":"1170x2532", <OTHER JSON FIELDS>,
"model":"iPhone13,2","carrier":"-1"}

We believe these issues are introduced by an upstream analytics SDK developed by MobTech. We sent emails to MobTech disclosing these issues on November 26, 2024, but, as of February 12, we have not received any reply. When we re-analyzed RedNote in January 2025, we noticed that in all versions of RedNote other than the one downloaded from the Google Play Store, MobTech SDK requests had been upgraded to use TLS, albeit without any certificate validation.

Other potential MobTech issues

In this section, we discuss other potential issues with the cryptography used by other requests sent by MobTech. These requests also contain significant amounts of device metadata, and contain weaknesses in their encryption.

We also found that many other HTTPS POST requests to zztfly.com endpoints, including upc.zztfly.com/v5/gcl and log-auth.zztfly.com/api/log, are also not validating the TLS server certificate, and use yet another custom encryption method for many of their messages. We found that these requests use RSA without OAEP padding in order to encrypt AES keys. These AES keys are subsequently used in AES-ECB mode with PKCS7 padding to encrypt ciphertexts. In this section, we describe multiple weaknesses with this cryptographic construction.

During RSA encryption, instead of OAEP, MobSDK uses this custom padding scheme:

This padding scheme is similar to PKCS#1-1.5, which has historically been susceptible to numerous attacks with widespread applicability.

In general, RSA-bootstrapped key exchange is notoriously difficult to implement correctly, provides no forward secrecy, has a long history of widespread issues, and provides no cryptographic authenticity or integrity. TLS 1.3 no longer supports RSA key exchange for these reasons.

Finally, AES in ECB mode is generally weak due to its determinism. That is, within a ciphertext, an attacker can observe if blocks are encrypting the same plaintext block. In addition, ECB-encrypted ciphertexts are highly malleable. Since the MobSDK encryption scheme provides no integrity or authenticity, an attacker can arbitrarily insert, remove, alter, or swap ciphertext blocks without being noticed by the attacker.

Other insecure requests

We observed some other data leakages and the use of insufficient encryption on RedNote. We summarize the results below.

Insufficiently encrypted configuration file

We observed RedNote Android making an HTTP POST request to the endpoint fe.xiaohongshu.com/api/feresource/v1/web, which fetches a JSON configuration file. Since this request is unauthenticated and seems to contain no method for ensuring cryptographic integrity, it can be modified by network attackers without detection. Since the configuration file seems to contain various matching regexes, this configuration file could enable a similar attack vector to the NEXTDATA vulnerability.

Insufficiently encrypted DNS requests

Both RedNote iOS and Android make HTTP GET requests similar to the following:

http://119.29.29.98/d?dn=0f94e1082a116d20242a7cdceba900f7eed0eac4b1c3e7b3&clientip=1&ttl=1&query=1&id=8713&type=addrs&alg=des

We recognize these as Tencent HTTPDNS requests. These requests use a static DES key for encryption and can thus be easily decrypted by anyone who reverse-engineers the key from the RedNote application.

Discussion

We reiterate that the network security vulnerabilities outlined in this report could enable surveillance by any government or ISP, and not just the Chinese government. For instance, these issues make the new wave of American RedNote users more vulnerable to surveillance by their own government and ISPs. As the Chinese government might already have mechanisms to lawfully obtain detailed data from RedNote about their users, the issues that we found also make Chinese users especially vulnerable to surveillance by non-Chinese governments. This is particularly relevant due to RedNote’s popularity with Chinese travellers abroad and Chinese diaspora communities. Thanks to the Snowden revelations, we know similar vulnerabilities in Chinese applications have previously been exploited by the Five Eyes intelligence alliance to surveil Chinese users globally.

The security issues we discovered in RedNote are not unique to this app. TikTok, which is RedNote’s closest competitor outside of the Chinese market, has a history of similar issues. In 2019, analysts at the US-based law firm Glancy, Prongay, and Murray found that TikTok used non-standard encryption to protect sensitive user data. The findings informed a class action lawsuit on TikTok’s privacy violations that, in 2021, after consolidation with a similar suit, was ultimately settled for $92 million USD. In our 2021 report, we found that all requests by then were encrypted with HTTPS, although some requests also continued to use non-standard encryption such as ttEncrypt.

Applications that are popular in China often use no encryption, proprietary encryption protocols, or use TLS without certificate validation to encrypt sensitive data. We discussed possible reasons for this systemic issue, and potential paths for remediation in the discussion section of our previous report analyzing Chinese keyboard apps. Our findings on the RedNote application reaffirm the importance of using well-understood encryption libraries correctly and of refraining from developing custom encryption algorithms.

Suggestions for users

RedNote users that are concerned with local ISP surveillance may choose to use a trusted VPN. However, we note that this solution simply shifts control to the VPN provider and would simply enable the VPN provider to surveil or attack end-users rather than the ISP or other local network attackers. We suggest users that are highly concerned about network surveillance from any party refrain from using RedNote until these security issues are resolved.

As we mentioned earlier, we did not review RedNote’s privacy policy, data collection, or data sharing policies. As far as we know, the risks in this regard would be similar to those for any other application based in China. Therefore, users that may be concerned with RedNote’s possession of their data or their data being collected in a Chinese legal jurisdiction may also want to refrain from using the application.

Disclosure timeline

Following our responsible disclosure policy, we disclosed the issues that we discovered according to the timeline below.

November 2024

• We discover that RedNote contains two vulnerabilities introduced by upstream SDKs, MobTech, and NEXTDATA.
• On November 13, 2024, we disclosed to NEXTDATA at [email protected].
• On November 26, 2024, we disclosed to MobTech at [email protected].

January 2025

• We re-analyzed RedNote, finding that the NEXTDATA issue is still present. We observed that the MobTech SDK’s requests have been upgraded to use TLS in RedNote.
• On January 16, 2025, we disclosed to RedNote at [email protected] and [email protected]. The second email address bounces.
• We discover that the MobTech SDK’s requests, despite having been upgraded to TLS after our disclosure, are not subject to certificate validation.
• On January 22, 2025, we followed up with MobTech and RedNote about this issue.

As of February 12, 2025, we have not received any responses from any of these parties.

Acknowledgements

We thank Pellaeon Lin, Adam Senft, and Siena Anstis for their review and feedback on this work. Research for this project was supervised by Jonathan Mayer, Prateek Mittal, and Ron Deibert.

Appendix

NEXTDATA RSA encryption

Some requests sent by NEXTDATA are encrypted using this method. The request relevant to our attack is an HTTP POST request to http://fp-it.fengkongcloud.com/v3/profile/android, which contains the following JSON payload in the request body:

{"data":
  {"pri": "<base64-encoded seed encrypted with RSA pubkey>",
   "tn": "<base64-encoded MD5 of data encrypted with RSA pubkey>",
   "fingerprint": "<base64-encoded, plaintext encrypted with key derived from 
    seed>",
   "sessionId": "<epoch time in ms>",
   "fpEncode":11},
"encrypt":1, 
"organization": "<alphanumeric string>", ... }

This is RSA-bootstrapped AES encryption. First, NEXTDATA generates a seed by randomly selecting 16 letters from a to z. pri is this seed encrypted with a pinned RSA public key. tn is the MD5 checksum of sessionId, the underlying plaintext, seed, organization, and sm_tn, all encrypted with the same pinned RSA key. Finally, fingerprint is the underlying plaintext, encrypted with AES-CBC, as follows:

fingerprint = AES_encrypt(key = MD5(seed).hexdigest(), iv = b'0102030405060708')

Though we are not able to trivially decrypt this payload, this method of encryption still has issues. For instance, due to the method of generating the AES key seed, the entropy of the AES key is approximately 75 bits, even though the full AES key is 256 bits long. We do not recommend this method of encryption and strongly recommend the use of well-understood network encryption libraries.