WeChat Zero-Click Worm Exploited via Incoming Calls: Detection and Remediation Guide for iOS and Android

Security researchers at Calif have demonstrated a fully weaponized zero-click worm targeting WeChat — one of the world's largest messaging platforms with over a billion active users — on both iOS and Android. The worm propagates through an incoming WeChat call. The victim never has to answer, tap, or even look at their phone. The only precondition is that the attacker must already be in the victim's WeChat contact list. Calif demonstrated the worm spreading across three test phones, reported the flaw to Tencent in July, and Tencent has since remediated it.

This is the class of vulnerability that keeps mobile security teams awake at night. Zero-click exploits in messaging applications are the bread and butter of commercial spyware vendors and nation-state operators because they defeat the single most reliable defense we teach users: don't tap suspicious links. There is no link. There is no tap. The attack surface is the application's own real-time call handling and media parsing stack — code that must, by design, process untrusted data before any human interaction occurs.

The wormable characteristic is what elevates this from a serious bug to an architectural threat. A compromised account can call every contact in its address book, and each of those contacts can do the same. In an organization where staff use WeChat for business communications — common across APAC operations, supply chains, and joint ventures — a single compromised device becomes a self-propagating account takeover campaign with a built-in trusted-contact delivery mechanism.

Defenders need to act on three fronts immediately: verify WeChat clients are updated to the remediated version, hunt for evidence of compromise on managed mobile devices, and reassess WeChat's role in your organization's communications architecture given the demonstrated exploitability of its call-handling stack.

Technical Analysis

What We Know

How the Attack Works — Defender's View

The public summary does not disclose the vulnerable component by name, but the attack shape tells us a great deal. Zero-click exploitation via an incoming call in a messaging app almost always lives in one of three places:

1. Call signaling parsing — the code that processes the call setup/invite payload before the callee's device ever rings or presents UI. Malformed signaling data reaches the parser automatically.
2. Real-time media stack — audio/video codec or RTP processing that initializes on call receipt, prior to answer.
3. Push-to-wake / background processing paths — on iOS especially, VoIP pushes (PushKit) wake the app to process incoming call data in the background, giving an attacker code execution in a context the user never sees.

The exploit chain results in account takeover, which implies the attacker obtained enough control to extract or reuse WeChat session material (tokens, keys) or to operate the account in place. The worm logic then enumerates the victim's contact list and places calls to each contact, repeating the cycle.

Key exploitation characteristics defenders should internalize:

• The contact precondition is not a meaningful barrier at scale. Attackers seed contact relationships through social engineering, previously compromised accounts, or by accepting inbound contact requests — and once one account falls, every contact of that account is exposed automatically.
• There is no malicious artifact for the user to notice. No attachment, no message preview, no notification that must be dismissed. Mobile EDR and behavioral telemetry are your only sensors.
• Both major mobile OS platforms are affected, which suggests the flaw was in WeChat's own shared call-handling code rather than a platform API — meaning platform-level mitigations (iOS Lockdown Mode, Android hardening) may offer partial but incomplete protection.

Exploitation Status

This is a researcher-built PoC that was responsibly disclosed and remediated by Tencent before public release. There is no public indication of in-the-wild abuse and no CISA KEV entry. However, the technique is now publicly documented, and the pattern — zero-click, wormable, contact-graph propagation in a billion-user messaging platform — is precisely the profile that commercial exploit brokers and state actors pursue. Treat unpatched clients as actively at-risk, and treat any organization with WeChat-dependent workflows in contested regions or industries as elevated-risk.

Detection & Response

Mobile zero-click detection is genuinely hard, and I won't pretend otherwise. You will not write a high-fidelity signature for a patched, undisclosed parser bug. What you can do is hunt the behavioral residue of exploitation and account takeover: process instability in the WeChat app (repeated crashes are the classic fingerprint of zero-click exploitation attempts), unexpected child processes or execution behavior spawned by the messaging app, anomalous call signaling volume consistent with worm propagation, and post-compromise account anomalies (new device registrations, contact enumeration bursts, outbound call storms). The detections below target those behaviors. Tune thresholds to your environment's WeChat baseline before enabling at high severity.

Sigma Rules

---
title: WeChat Process Crash Loop - Possible Zero-Click Exploitation Attempt
description: Detects repeated crashes of the WeChat mobile application process, a common artifact of memory-corruption exploitation attempts against messaging app call-handling stacks.
references:
  - https://thehackernews.com/2026/09/wechat-zero-click-worm-took-over.html
  - https://attack.mitre.org/techniques/T1649/
author: Security Arsenal
date: 2026/09/10
status: experimental
id: 8f2c1b74-3e9a-4d56-b7c2-1a9f5e3d8204
tags:
  - attack.execution
  - attack.t1649
logsource:
  product: android
  category: application_crash
detection:
  selection:
    process_name|contains:
      - 'com.tencent.mm'
  condition: selection
falsepositives:
  - Legitimate app instability after OS updates or on low-memory devices
level: medium
---
title: WeChat Spawning Unexpected Child Process on Android
description: Detects the WeChat application process spawning shells, interpreters, or installer processes — behavior consistent with post-exploitation activity following zero-click compromise of a messaging app.
references:
  - https://thehackernews.com/2026/09/wechat-zero-click-worm-took-over.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/10
status: experimental
id: 4d7e9a15-6c2b-48f1-93e0-2b8c4f6a7319
tags:
  - attack.execution
  - attack.t1059
logsource:
  product: android
  category: process_creation
detection:
  selection_parent:
    ParentProcessName|contains:
      - 'com.tencent.mm'
  selection_child:
    ProcessName|endswith:
      - '/sh'
      - '/su'
      - '/pm'
      - '/am'
      - '/dex2oat'
      - '/app_process'
  condition: selection_parent and selection_child
falsepositives:
  - Rare; some legitimate app self-update mechanisms may invoke package manager components
level: high
---
title: WeChat Outbound VoIP Call Storm - Potential Worm Propagation
description: Detects a single source host or account initiating an abnormally high volume of outbound WeChat calls to distinct contacts within a short window, consistent with worm-like propagation via the contact graph.
references:
  - https://thehackernews.com/2026/09/wechat-zero-click-worm-took-over.html
  - https://attack.mitre.org/techniques/T1580/
author: Security Arsenal
date: 2026/09/10
status: experimental
id: 2b9f4e61-8a3d-4c70-a5e9-7d1c3b6f2085
tags:
  - attack.discovery
  - attack.lateral_movement
logsource:
  category: netflow
detection:
  selection:
    application|contains:
      - 'wechat'
      - 'tencent'
    service|contains:
      - 'voip'
      - 'stun'
      - 'turn'
  condition: selection
falsepositives:
  - Heavy legitimate WeChat calling; baseline per-user call volume before alerting
level: medium

KQL — Microsoft Sentinel / Defender

The first query hunts mobile threat defense telemetry ingested into Sentinel for WeChat crash clustering and suspicious network behavior from mobile devices. The second hunts outbound connection storms from any WeChat desktop clients in the environment — relevant because a worm-compromised mobile account is often operated from attacker-controlled desktop sessions, and WeChat desktop anomalous behavior is an observable proxy.

// Hunt 1: WeChat instability and anomalous network activity from mobile devices (requires MTD/MDM ingestion via CEF/Syslog)
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor contains "tencent" or ApplicationProtocol contains "wechat" or Message contains "com.tencent.mm"
| summarize EventCount = count(), DistinctDestinations = dcount(DestinationIP), Destinations = make_set(DestinationIP, 20) by DeviceName, SourceIP, bin(TimeGenerated, 1h)
| where EventCount > 50 or DistinctDestinations > 30
| sort by DistinctDestinations desc;

// Hunt 2: WeChat desktop client spawning unexpected processes or making unusual outbound connections
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "WeChat.exe"
| where FileName !in~ ("WeChat.exe", "WeChatApp.exe", "WeChatPlayer.exe", "WeChatUtility.exe", "conhost.exe")
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine
| join kind=leftouter (
    DeviceNetworkEvents
    | where TimeGenerated > ago(7d)
    | where InitiatingProcessFileName =~ "WeChat.exe"
    | summarize ConnectionCount = count(), RemoteIPs = make_set(RemoteIP, 15) by DeviceName, bin(TimeGenerated, 1h)
    | where ConnectionCount > 100
) on DeviceName
| project-reorder TimeGenerated, DeviceName, FileName, ProcessCommandLine, ConnectionCount, RemoteIPs;

Velociraptor VQL

For environments with WeChat desktop on Windows endpoints (common in APAC-facing business units), hunt for WeChat processes exhibiting post-exploitation behavior — unexpected child processes or connections inconsistent with normal Tencent infrastructure.

-- Hunt for WeChat client anomalies: unexpected child processes and high-volume outbound connections
LET proc_hunt = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)wechat'
   OR CommandLine =~ '(?i)wechat'
   OR Exe =~ '(?i)tencent'

LET suspicious_children = SELECT Pid, Ppid, Name, CommandLine, Exe, CreateTime
FROM pslist()
WHERE Ppid IN (SELECT Pid FROM proc_hunt)
  AND Name =~ '(?i)(cmd|powershell|wscript|cscript|mshta|rundll32|regsvr32|certutil|bitsadmin|wmic)'

LET net_hunt = SELECT Pid, Name, Path, RemoteAddr, RemotePort, State
FROM netstat()
WHERE Name =~ '(?i)wechat'
  AND State = 'ESTABLISHED'

SELECT 'suspicious_child' AS FindingType, Pid, Name, CommandLine, Exe, CreateTime AS Timestamp, '' AS RemoteAddr, '' AS RemotePort
FROM suspicious_children
UNION ALL
SELECT 'wechat_connection' AS FindingType, Pid, Name, '' AS CommandLine, Path AS Exe, '' AS Timestamp, RemoteAddr, RemotePort
FROM net_hunt

Remediation / Verification Script

For organizations managing Android fleets via ADB/MDM, this Bash script verifies the installed WeChat version on connected devices, checks for crash artifacts consistent with exploitation attempts, and flags devices running outdated builds. For iOS, enforcement belongs in your MDM (Intune, Jamf) via minimum-version compliance policies — the script's second half generates the Android-side evidence you need for the same posture.

#!/bin/bash
# WeChat zero-click worm (Calif/Tencent 2026) - Android fleet verification
# Requires: adb in PATH, devices enrolled and reachable via ADB or run via MDM shell

REPORT="wechat_audit_$(date +%Y%m%d).csv"
echo "device_serial,wechat_installed,version_code,version_name,recent_wechat_crashes" > "$REPORT"

for SERIAL in $(adb devices | awk 'NR>1 && $2=="device" {print $1}'); do
  echo "[*] Auditing $SERIAL"

  PKG_CHECK=$(adb -s "$SERIAL" shell pm list packages 2>/dev/null | grep -c "com.tencent.mm")
  if [ "$PKG_CHECK" -eq 0 ]; then
    echo "$SERIAL,no,," >> "$REPORT"
    continue
  fi

  VCODE=$(adb -s "$SERIAL" shell dumpsys package com.tencent.mm 2>/dev/null | grep -m1 "versionCode" | tr -d ' ' | cut -d= -f2 | cut -d' ' -f1)
  VNAME=$(adb -s "$SERIAL" shell dumpsys package com.tencent.mm 2>/dev/null | grep -m1 "versionName" | tr -d ' ' | cut -d= -f2)

  # Crash artifacts: repeated tombstones / dropbox entries for WeChat indicate possible exploitation attempts
  CRASHES=$(adb -s "$SERIAL" shell "ls /data/tombstones/ 2>/dev/null" | grep -c "tencent" )
  DROPBOX=$(adb -s "$SERIAL" shell dumpsys dropbox 2>/dev/null | grep -ci "com.tencent.mm")

  echo "$SERIAL,yes,$VCODE,$VNAME,dropbox:$DROPBOX tombstones:$CRASHES" >> "$REPORT"

  if [ "$DROPBOX" -gt 5 ]; then
    echo "[!] ALERT: $SERIAL shows $DROPBOX recent WeChat crash entries - investigate for zero-click exploitation attempts"
  fi
done

echo "[+] Audit complete: $REPORT"
echo "[i] ACTION: Cross-reference version codes against the current WeChat release in Google Play / Tencent's official channel."
echo "[i] ACTION: Any device below the remediated build must be updated or restricted from corporate data via MDM policy."

Remediation

1. Enforce client updates immediately. Tencent has remediated the flaw server-side and/or in current client builds (Calif confirmed remediation post-disclosure). Because no CVE or fixed-version number has been published, the operative control is: all WeChat clients must be on the latest version from official channels (Apple App Store, Google Play, or Tencent's official distribution) — no exceptions. In your MDM, set a minimum app version compliance policy for WeChat and quarantine or restrict non-compliant devices from corporate resources until updated.

2. Disable WeChat auto-update gaps. On managed devices, enforce automatic app updates. Zero-click messaging bugs have a long tail of exploitation precisely because users defer updates. The patch only protects devices that receive it.

3. Restrict the contact-graph precondition. The exploit requires the caller to be an existing contact. Enforce WeChat privacy settings on corporate-used accounts: require verification for contact additions, disable discovery via phone number/QR where operationally feasible, and train users in APAC-facing roles to treat inbound contact requests with the same suspicion as phishing emails — because that is the delivery mechanism for the next variant of this attack.

4. Segment WeChat from corporate data. Given a demonstrated account-takeover primitive with no user interaction, WeChat on devices holding sensitive corporate data is a material risk. Move WeChat usage into a work-profile/container (Android Enterprise work profile, iOS managed apps) with strict data-sharing boundaries, or restrict WeChat to dedicated devices for staff whose roles genuinely require it.

5. Hunt the residue. Deploy the crash-loop and call-storm detections above against your mobile fleet telemetry. Any device showing repeated WeChat crashes within the disclosure window (July 2026 onward) should be treated as potentially compromised: revoke its WeChat session, re-register the account, review the account's recent outbound calls/messages for propagation attempts, and rotate any credentials accessible from that device.

6. Monitor for downstream account abuse. Account takeover via this vector hands the attacker the victim's trusted identity. Alert on new-device WeChat logins, password/session changes, and bulk contact interactions. Notify business partners if a corporate-linked account shows compromise indicators — worm propagation means your partners' contact lists are the next target.

7. Track vendor disclosure. Tencent has not published a public advisory with a fixed-version identifier or CVE at the time of writing. Monitor Tencent's security channels and Calif's research publication for the technical writeup; when version-specific data lands, convert step 1 from "latest version" to a precise minimum build and re-baseline your fleet.

There are no CISA KEV deadlines associated with this issue as of publication, but the wormability and zero-click characteristics warrant treating this with KEV-level urgency inside your own remediation SLAs — 72 hours for client update enforcement is a defensible target.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub