مكالمة واحدة تكفي: WeWorm يكشف أخطر سطح هجوم في WeChat عبر iOS وAndroid
لم يعد فتح رابط خبيث أو تنزيل ملف مجهول شرطًا لبدء هجوم على الهاتف. في نموذج هجومي كشف عنه باحثو Calif في سبتمبر 2026، كانت مكالمة واردة عبر WeChat كافية لبدء سلسلة استغلال من نوع Zero-Click تنتقل بين أجهزة iOS وAndroid من دون أن يضغط الضحية على أي شيء، بل ومن دون أن يجيب على المكالمة أصلًا.
المشروع حمل اسم WeWorm، وهو نموذج دودة بحثية تستغل خللًا في مكدس الاتصالات الصوتية داخل WeChat، ثم تستخدم الحساب الذي تمت السيطرة عليه للاتصال بجهات موثوقة أخرى ومواصلة الانتشار. الخطورة هنا لا تكمن في تنفيذ شيفرة عن بُعد فحسب، بل في الجمع بين Zero-Click RCE ونموذج الثقة الاجتماعي داخل تطبيق يضم قاعدة مستخدمين هائلة.
[!tldr] WeWorm هو نموذج بحثي لدودة Zero-Click عبر مكالمات WeChat. الخلل مرتبط بفساد في الذاكرة داخل مكدس VoIP، وتمكن الباحثون من استغلاله على Android وiOS للسيطرة على حساب WeChat خلال ثوانٍ. لا يحتاج الضحية إلى الرد على المكالمة، لكن المهاجم يجب أن يكون ضمن قائمة أصدقائه. Tencent أصدرت إصدارات مخففة للمشكلة ثم أكدت معالجة الاستغلال على مستوى الخادم لجميع المستخدمين.
#من مكالمة واردة إلى حساب مخترق
أظهر فريق Calif سلسلة الاستغلال على ثلاثة هواتف. بدأ الهجوم من جهاز Pixel 10a يعمل بنظام Android، ثم أجرى اتصالًا بجهاز iPhone 17e. أثناء استمرار رنين الهاتف، تم استغلال الخلل والسيطرة على حساب WeChat الموجود على الجهاز.
بعد ذلك تحول الهاتف المصاب إلى نقطة انطلاق جديدة: استخدم الباحثون حساب WeChat المخترق على iPhone للاتصال بجهاز Pixel 10a آخر، ثم استغلال الجهاز الثالث بالطريقة نفسها.
يمكن تلخيص مسار الانتشار بهذا الشكل:
Attacker -> WeChat Call -> Victim A
Victim A Compromised -> WeChat Call -> Victim B
Victim B Compromised -> Next Contact -> ...
هذا النموذج هو جوهر سلوك الدودة: الضحية تتحول إلى وسيط للهجوم على الضحية التالية.
#عرض Android RCE
#عرض iOS RCE
[!signal] العامل الحاسم في WeWorm ليس فقط وجود ثغرة RCE، بل قدرة الهجوم على الاستفادة من الحساب المخترق للوصول إلى جهات اتصال تعتبره أصلًا جهة موثوقة.
#لماذا يصنف الهجوم Zero-Click؟
في الهجمات التقليدية يعتمد المهاجم غالبًا على تفاعل المستخدم: فتح رابط، تشغيل مرفق، تثبيت تطبيق أو الموافقة على نافذة ما. أما في السيناريو الذي عرضه Calif، فلم يكن أي من ذلك مطلوبًا.
بحسب الباحثين:
- لا يحتاج المستخدم إلى الرد على المكالمة.
- لا يحتاج إلى لمس الهاتف أو تنفيذ أي إجراء.
- إذا تم الرد، لا يسمع المستخدم شيئًا ويستمر الاستغلال.
- رفض المكالمة يوقف محاولة الاستغلال الحالية، لكن يمكن للمهاجم إعادة الاتصال لاحقًا.
هذا يجعل سطح الهجوم مختلفًا جذريًا عن التصيد التقليدي؛ لأن عنصر وعي المستخدم لا يعمل هنا كطبقة دفاع رئيسية.
#نقطة الدخول: مكدس VoIP وفساد الذاكرة
أفاد Calif بأن أصل المشكلة هو Memory Corruption داخل مكدس VoIP الخاص بـWeChat.
WeChat VoIP Stack
|
v
Memory Corruption
|
v
Remote Code Execution
|
v
WeChat Account Takeover
لم ينشر الفريق حتى الآن التفاصيل الفنية الدقيقة للخلل أو طريقة بناء الاستغلال، وأوضح أنه يحتفظ بالتفاصيل إلى حين تقديم التحليل الكامل في مؤتمر قادم.
هذا التفصيل مهم عند تقييم المعلومات المنشورة: المعروف حاليًا هو موقع الخلل بصورة عامة ونتيجة الاستغلال، لكن تفاصيل الـ primitive المستخدمة، وآلية التحكم بالذاكرة، ومسار تحويل الخلل إلى تنفيذ أوامر عن بُعد لم تُنشر بعد.
[!research-note] لا تتوافر في الإفصاح الحالي معلومات كافية لتحديد ما إذا كان الخلل من نوع Use-After-Free أو Out-of-Bounds أو Heap Corruption أو فئة أخرى من أخطاء الذاكرة. وصف Calif المنشور يكتفي بتحديده كـ Memory Corruption Issue داخل مكدس VoIP.
#ما الذي يحصل عليه المهاجم فعليًا؟
بعد نجاح الاستغلال، ذكر الباحثون أنهم تمكنوا من السيطرة الكاملة على حساب WeChat، بما يشمل:
- قراءة الرسائل.
- إرسال الرسائل باسم المستخدم.
- إجراء المكالمات.
- التصرف من خلال الحساب باعتباره صاحبه الشرعي.
من المهم التمييز بين السيطرة على حساب WeChat والسيطرة الكاملة على الهاتف. الاستغلال المعروض يمنح تحكمًا في حساب WeChat، بينما الوصول إلى سيطرة كاملة على الجهاز يتطلب ربطه بثغرات إضافية على Android أو iOS.
WeWorm Alone
-> WeChat Account Compromise
WeWorm + Additional Platform Exploits
-> Potential Full Device Compromise
هذا الفصل مهم عند تقدير الأثر الأمني؛ فنجاح WeWorm لا يعني تلقائيًا الحصول على صلاحيات root أو السيطرة على نظام التشغيل بالكامل.
#شرط الصداقة لا يلغي قابلية الانتشار
يتطلب الاستغلال أن يكون المهاجم ضمن قائمة أصدقاء الضحية في WeChat. للوهلة الأولى قد يبدو ذلك قيدًا يحد من الخطر، لكنه في نموذج الدودة يتحول إلى جزء من آلية الانتشار نفسها.
إذا تمكن المهاجم من اختراق حساب مستخدم واحد، يصبح ذلك الحساب جهة موثوقة لدى أصدقائه. يمكن عندها استخدام الحساب المصاب للاتصال بالأصدقاء التاليين، ثم تكرار السلسلة.
Compromised Friend
|
v
Trusted Relationship
|
v
Incoming WeChat Call
|
v
Next Account Compromised
بمعنى آخر، تصبح علاقة الثقة التي صُممت لتسهيل تواصل المستخدمين قناة يمكن استغلالها لنقل الهجوم من حساب إلى آخر.
#الانتقال بين iOS وAndroid
أحد الجوانب اللافتة في WeWorm هو أن نموذج الانتشار لم يكن محصورًا في منصة واحدة. العرض البحثي بدأ من Android، ثم انتقل إلى iOS، ثم عاد مرة أخرى إلى Android.
| المرحلة | الجهاز | النظام | النتيجة |
|---|---|---|---|
| 1 | Pixel 10a | Android | نقطة انطلاق الهجوم |
| 2 | iPhone 17e | iOS | اختراق حساب WeChat أثناء رنين المكالمة |
| 3 | Pixel 10a | Android | اختراق الحساب عبر اتصال صادر من الجهاز المصاب |
هذا يوضح أن سطح الهجوم موجود داخل مكوّن مشترك في التطبيق نفسه، بينما تمكّن الباحثون من بناء سلاسل استغلال مناسبة لكل نظام تشغيل.
#من اكتشاف الخلل إلى بناء الدودة بمساعدة AI
بحسب Calif، ساعد الذكاء الاصطناعي الفريق في اكتشاف الخلل والوصول إلى أول استغلال Remote Code Execution خلال نحو يومين، ثم استغرق بناء نموذج الدودة أسبوعًا إضافيًا تقريبًا.
لا يعني ذلك أن العملية تمت من دون تدخل بشري. الفريق أوضح أن الباحثين تولوا تحديد الأهداف المناسبة، اتخاذ القرارات الفنية، وضبط الاختبارات بطريقة آمنة، بينما ساهم الذكاء الاصطناعي في تسريع جزء كبير من أعمال التحليل والاستغلال.
هذه النقطة تتجاوز WeWorm نفسها. إذا أصبحت عملية الانتقال من اكتشاف خلل إلى بناء استغلال عملي أسرع بكثير، فإن الزمن المتاح بين ظهور الثغرة واستغلالها المحتمل يصبح أقصر، وهو ما يضغط على فرق إدارة الثغرات والاستجابة للحوادث وموردي البرمجيات في الوقت نفسه.
[!defender-note] في بيئة تتسارع فيها أبحاث الاستغلال باستخدام AI، لم يعد تقييم المخاطر قائمًا فقط على وجود Exploit علني. سرعة تحويل الثغرات غير المعروفة إلى استغلال عملي أصبحت عاملًا يجب أن يدخل في حسابات زمن التصحيح والاستجابة.
#الأثر من منظور الحوكمة والمخاطر والالتزام
تكشف حالة WeWorm عن عدة نقاط تتجاوز الجانب التقني المباشر.
#1. الاعتماد على تطبيقات الاتصالات كأصول عالية الحساسية
عندما يصبح تطبيق محادثة قناة للمراسلة والمكالمات والخدمات الرقمية الأخرى، فإن اختراق الحساب قد يؤثر على الهوية الرقمية للمستخدم، اتصالاته، ومصداقية الرسائل الصادرة باسمه.
#2. حدود التوعية الأمنية التقليدية
برامج التوعية تركز عادة على عدم فتح الروابط المشبوهة أو المرفقات غير الموثوقة. هجمات Zero-Click تقلل فعالية هذا النوع من الضوابط لأنها لا تعتمد أساسًا على خطأ المستخدم.
#3. مخاطر الثقة بين جهات الاتصال
أنظمة الحماية التي تمنح جهات الاتصال الموثوقة امتيازات إضافية تحتاج إلى تقييم دائم لسيناريو Compromised Trusted Contact، لأن هوية الطرف الموثوق قد تصبح بحد ذاتها وسيلة للوصول إلى مستخدمين آخرين.
#4. إدارة مخاطر الطرف الثالث
بالنسبة للجهات التي تسمح باستخدام تطبيقات المراسلة الخارجية في بيئات العمل، توضح الحالة ضرورة اعتبار تلك التطبيقات جزءًا من سلسلة المخاطر التقنية، حتى إن لم تكن مستضافة داخل البنية التحتية للمنظمة.
#5. تقليص نافذة التعرض
في هذا النوع من الثغرات، تصبح سرعة وصول التحديث أو التخفيف الأمني إلى المستخدمين عنصرًا أساسيًا في تقليل المخاطر، خصوصًا عندما يكون الاستغلال لا يتطلب تفاعلًا بشريًا.
#ماذا فعلت Tencent؟
أبلغ Calif شركة Tencent بالثغرة في يوليو 2026. وفي 21 أغسطس نشرت Tencent إصدار:
Android: WeChat 8.0.77
iOS: WeChat 8.0.76
وذكر الباحثون أن هذه الإصدارات خففت المشكلة. وفي 28 أغسطس أكد Calif أن الاستغلال الذي طوره لم يعد يعمل بعد تطبيق معالجة على مستوى الخادم لجميع المستخدمين.
لاحقًا، في 4 سبتمبر، أكدت Tencent للباحثين أن الثغرة كان يمكن استغلالها لتنفيذ أوامر عن بُعد.
#التسلسل الزمني للإفصاح
| التاريخ | الحدث |
|---|---|
| يوليو 2026 | اكتشاف الخلل بمساعدة AI |
| 23 يوليو | علم الفريق الهندسي بالثغرة |
| 24 يوليو | إرسال البلاغ إلى Tencent |
| 25–28 يوليو | حظر حسابات WeChat الخاصة بالباحثين |
| 29 يوليو | رفع الحظر عن الحسابات |
| 30 يوليو | اكتمال أول استغلال RCE على Android |
| 2 أغسطس | اكتمال استغلال RCE على iOS |
| 11 أغسطس | اكتمال نموذج الدودة عبر Android وiOS |
| 21 أغسطس | إصدار WeChat 8.0.77 لأندرويد و8.0.76 لـiOS لتخفيف المشكلة |
| 26 أغسطس | Tencent تبلغ الفريق بأنها تقيّم المشكلة |
| 28 أغسطس | تأكيد تعطيل الاستغلال على مستوى الخادم لجميع المستخدمين |
| 3 سبتمبر | مشاركة التحليل الفني والاستغلالات العاملة مع Tencent |
| 4 سبتمبر | Tencent تؤكد إمكانية استغلال الثغرة لتنفيذ أوامر عن بُعد |
#لماذا تعد WeWorm حالة مختلفة؟
الخطورة ليست في كل عنصر منفردًا، بل في اجتماع عدة عناصر داخل سلسلة واحدة:
Zero-Click
+ Remote Code Execution
+ Trusted Contact Requirement
+ Account Takeover
+ Worm-Like Propagation
+ Cross-Platform Reach
= High-Impact Attack Surface
الهجوم لا ينتظر أن يفتح المستخدم رابطًا، ويمكنه الاستفادة من الحساب المصاب للوصول إلى حسابات أخرى، ويعمل ضمن تطبيق يستخدم على نطاق واسع، كما أن نموذج الاستغلال أثبت قابليته للعمل على منصتين مختلفتين.
هذه الخصائص تجعل WeWorm مثالًا واضحًا على كيفية تحول ثغرة في مكوّن اتصالات داخل تطبيق محادثة إلى مشكلة تتعلق بالانتشار والثقة الرقمية، وليس فقط بتنفيذ شيفرة على جهاز منفرد.
#ما الذي لا نعرفه حتى الآن؟
رغم العرض العملي، لا تزال هناك أجزاء جوهرية غير منشورة:
- التفاصيل الدقيقة لخلل الذاكرة.
- بنية الاستغلال الخاصة بكل منصة.
- آلية الوصول من فساد الذاكرة إلى RCE.
- آليات تجاوز الحمايات الحديثة في iOS وAndroid.
- تفاصيل التخفيف الذي نفذته Tencent على مستوى الخادم.
ومن ثم فإن أي تحليل أعمق لهذه النقاط في الوقت الحالي سيكون افتراضًا غير مدعوم بالمعلومات المنشورة.
#الخلاصة
WeWorm يوضح كيف يمكن لسطح هجوم يبدو اعتياديًا، مثل مكالمة واردة في تطبيق مراسلة، أن يتحول إلى نقطة دخول لهجوم Zero-Click قابل للانتشار بين المستخدمين والمنصات.
الخلل المعلن يرتبط بفساد في الذاكرة داخل مكدس VoIP في WeChat، وتمكن الباحثون من تحويله إلى RCE ثم إلى نموذج دودة تنتقل من حساب إلى آخر اعتمادًا على علاقات الثقة بين جهات الاتصال. وفي المقابل، توضح سرعة اكتشاف الخلل وبناء الاستغلال بمساعدة AI كيف تتغير دورة حياة الثغرات من البحث إلى الاستغلال ثم المعالجة.
تم إبلاغ Tencent بالثغرة في يوليو 2026، وأصدرت الشركة تحديثات مخففة في أغسطس قبل أن يتم تعطيل الاستغلال على مستوى الخادم لجميع المستخدمين. وحتى نشر التفاصيل الفنية الكاملة، تبقى WeWorm دراسة مهمة في مخاطر Zero-Click Attack Surfaces داخل تطبيقات الاتصالات الحديثة، وفي أثر الذكاء الاصطناعي على سرعة اكتشاف الثغرات وتحويلها إلى استغلالات عملية.





