New Study Uncovers Multiple Vulnerabilities in WeChat and IM Apps

Instant messaging (IM) applications like WeChat have become indispensable for billions, facilitating not only communication but also payments, business, and personal data exchange.

However, their ubiquity and complexity make them prime targets for sophisticated cyberattacks.

This article explores how a single WeChat message can be leveraged for persistent client-side attacks, examining the technical mechanisms, real-world vulnerabilities, and WeChat’s layered security responses.

Attack Surfaces in WeChat:

WeChat’s client-side architecture exposes several critical attack surfaces:

• URL Links and Custom Protocols: WeChat supports custom URI schemes such as weixin://, enabling deep linking within the app.
• Attackers can exploit lax URL validation to craft malicious links, potentially redirecting users to phishing sites or triggering sensitive in-app actions without consent.
• For example, the weixin://dl/ protocol is used for page routing, and URLs containing the ticket parameter invoke the /cgi-bin/mmbiz-bin/translatelink endpoint to resolve destinations, mitigating arbitrary redirects.
• File Processing Vulnerabilities: WeChat’s custom file handling logic, designed for user convenience, can be exploited by attackers using specially crafted files.
• Notable vulnerabilities include CVE-2019-11932 (malicious GIF in WhatsApp) and CVE-2025-30401 (executable disguised as an image), both of which enabled remote code execution in IM clients1.
• Built-in Browser Components: WeChat’s Android client uses the XWEB engine, a Chromium-based browser.
• While XWEB is regularly updated, it often lags behind official Chrome releases, leaving it exposed to known vulnerabilities like CVE-2023-41064 and CVE-2023-4863 in the libwebp component.
• The JSBridge interface, which allows web pages to invoke native functions, is tightly controlled by a permission array fetched from the cloud, limiting access based on the webpage’s URL.

Attack Surface	Example Protocol/Component	Vulnerability Type	Mitigation Mechanism
URL Links	weixin://, slack://settings	Phishing, Unauthorized Actions	Strict URL validation, domain whitelisting
File Processing	GIF, Executable disguised as image	Remote Code Execution	File type validation, sandboxing
Built-in Browser	XWEB, JSBridge	Privilege Escalation, RCE	Permission arrays, process isolation
Mini-Programs	JavaScript APIs	XSS, Privilege Abuse	Dual-layer isolation, JSAPI controls

Technical Mechanisms and Security Codes

WeChat URL Validation:

To prevent configuration tampering, WeChat restricts sensitive operations like set_config_url to HTTPS domains dldir1.qq.com or dldir1v6.qq.com only. For example:

textif (protocol != "https" || (domain != "dldir1.qq.com" && domain != "dldir1v6.qq.com")) {
    rejectRequest();
}

This strict validation ensures that even if a user is tricked into clicking a malicious link, unauthorized configuration changes are blocked.

Process Isolation in XWEB:

WeChat’s XWEB browser employs multi-process sandboxing:

• The main process runs in xweb_privileged_process_0
• Rendering occurs in xweb_sandboxed_process_0

This separation limits the impact of rendering process vulnerabilities, making privilege escalation significantly harder for attackers.

Mini-Program Security Architecture:

WeChat mini-programs split execution into a rendering layer (UI) and a logic layer (business logic), each running in isolated threads.

JavaScript code in the logic layer cannot access DOM APIs, while the rendering layer cannot invoke high-privilege functions. Key JSAPI functions are exposed selectively:

Layer	Example JSAPI Functions
Rendering Layer	insertVideoPlayer, insertTextArea
Logic Layer	saveFile, addDownloadTask

This architecture prevents attackers from using cross-site scripting (XSS) in mini-programs to escalate privileges or access sensitive APIs.

Best Practices and Remaining Challenges

Despite these robust mechanisms, WeChat’s security is not without flaws:

• Cryptographic Weaknesses: WeChat’s MMTLS protocol, a modified version of TLS 1.3, contains cryptographic weaknesses such as deterministic IVs and lack of forward secrecy, making it less secure than standard implementations.
• Code Obfuscation for Mini-Programs: To counter reverse engineering, WeChat mini-programs can employ code obfuscation, anti-debugging, and encryption of HTML/JavaScript. This increases the difficulty for attackers attempting to extract proprietary algorithms or sensitive data.

Managing Token Permissions

WeChat provides server-side interfaces setCloudAccessToken to manage cloud token permissions, ensuring only authorized components can access sensitive APIs.

In summary, WeChat’s multi-layered security—spanning strict URL validation, process isolation, dual-thread mini-program architecture, and permission-based API exposure—demonstrates a comprehensive approach to mitigating persistent client-side attacks.

However, continued vigilance and adoption of cryptographic best practices remain essential as attackers evolve their methods.

Find this News Interesting! Follow us on Google News, LinkedIn, & X to Get Instant Updates!