27 أبريل – ماذا حدث لتكوين علامات الميزات لدينا

في 27 أبريل 2026، كشف باحث أمني علنًا أن تكوين علامات الميزات من جانب العميل في ClickUp قد عرّض معلومات شخصية للخطر. وعلى وجه التحديد، تم تضمين 893 عنوان بريد إلكتروني لعملاء في قواعد استهداف علامات الميزات، إلى جانب علامة واحدة أشارت بشكل غير صحيح إلى رمز API لأحد العملاء، والذي استُخدم خلال عملية الاستجابة لحادث ما لفرض حدود على معدل حركة المرور من مساحة العمل تلك.

كان ينبغي أن نكتشف هذا الأمر في وقت أبكر. لكننا لم نفعل ذلك، ونحن مدينون لكم بتفسير واضح لما حدث، ولماذا حدث، وما الذي قمنا به حيال ذلك الآن، وكيف سنعمل على تحسين الأمور في المستقبل.

هل أنت متأثر بذلك؟

اقتصر التسرب على 893 عنوان بريد إلكتروني لعملاء تم استخدامها في قواعد استهداف علامات الميزات للتحكم في المستخدمين الذين يمكنهم رؤية ميزات معينة أثناء عمليات الطرح.

إذا تلقيت رسالة مباشرة قبل يوم 29 أبريل أو في ذلك اليوم (لا يزال الأمر مستمراً)، فهذا يعني أن عنوان بريدك الإلكتروني كان ضمن العناوين التي أُدرجت في إعدادات علامة الميزة. إذا لم تتلقَ أي رسالة منا، فهذا يعني أن بريدك الإلكتروني لم يكن مدرجاً في قائمة عناوين البريد الإلكتروني.

المشكلة الفنية

يستخدم ClickUp Split.io (الذي أصبح الآن جزءًا من Harness) لإدارة علامات الميزات. مثل معظم حزم SDK لعلامات الميزات على جانب المتصفح، يتطلب Split.io مفتاح SDK على جانب العميل مدمجًا في حزمة JavaScript الخاصة بالتطبيق. هذا المفتاح عام عن قصد، وهو الطريقة التي يستخدمها SDK لتقييم العلامات للمستخدم الحالي في المتصفح. هذا سلوك قياسي وموثق عبر Split.io وLaunchDarkly والمنصات المماثلة، ولا يمثل ثغرة أمنية.

المشكلة ليست في المفتاح نفسه، بل في ما يضعه مهندسونا داخل إعدادات العلامة.

إليكم ما حدث من الناحية الهندسية: تتيح منصات علامات الميزات للمهندسين استهداف مستخدمين محددين عند طرح الميزات. كانت فرق الهندسة في ClickUp تستخدم عناوين البريد الإلكتروني مباشرةً في قواعد استهداف العلامات. ومن الأمثلة على ذلك تمكين ميزة لمجموعة محددة من مختبري الإصدار التجريبي. تعرض نقطة نهاية splitChanges القابلة للاستعلام عنها علنًا في Split.io SDK المجموعة الكاملة من تعريفات العلامات، بما في ذلك قواعد الاستهداف هذه. وهذا يعني أن أي شخص لديه المفتاح من جانب العميل (والذي، مرة أخرى، موجود عمدًا في كود الواجهة الأمامية لدينا) يمكنه استرداد تعريفات العلامات تلك واستخراج عناوين البريد الإلكتروني المضمنة فيها.

تعامل المهندسون مع إعدادات علامات الميزات كأدوات داخلية، في حين أن بنية حزمة تطوير البرامج (SDK) تجعلها قابلة للاستعلام عنها بشكل عام بحكم تصميمها. وقد أدى ذلك إلى تراكم عناوين البريد الإلكتروني في مكان لم يكن ينبغي أن توجد فيه أبدًا. تتطلب تحديثات علامات الميزات مراجعة من قبل زميلين، على غرار ما يحدث مع الكود. ولم تكتشف خطوة المراجعة هذه المشكلة.

الاستثناء الوحيد – علم تم تهيئته لتقييد معدل استخدام عميل واحد

أشار مهندس مناوب كان يتعامل مع حالة إساءة استخدام واجهة برمجة التطبيقات (API) إلى رمز API خاص بأحد العملاء في إعدادات علامة تحديد السرعة (rate-limiting flag) بهدف تقييد حركة المرور، مما جعل هذا الرمز قابلاً للقراءة عبر نقطة نهاية SDK. ما كان يجب أن يحدث هذا أبداً: فبيانات الاعتماد لا ينبغي أن ترد في إعدادات العلامات. وقد قمنا بتعطيل الرمز على الفور، وحتى الآن، لا تظهر تحقيقاتنا في السجلات أي دلائل على وجود وصول ضار بخلاف التحقيق الذي أجراه الباحث نفسه. لم يكن من الممكن الوصول إلى أي رموز عملاء أخرى أو بيانات مساحة العمل، ونحن نعمل مباشرة مع هذا العميل.

ما تم الكشف عنه وما لم يتم الكشف عنه

الجدول الزمني

نحن ملتزمون بالشفافية التامة بشأن النقاط التي تعثرت فيها عملياتنا، بما في ذلك الإخفاقات التي ارتكبها مزود خدمة مكافآت اكتشاف الأخطاء التابع لجهة خارجية وأدوات الاتصال الداخلية الخاصة بنا.

أين فشلت خطواتنا

هناك ثلاثة أخطاء وقعت هنا، ونود أن نحدد كل منها بوضوح. وسنناقش التغييرات في القسم التالي.

1. لم يتم اتخاذ أي إجراءات متابعة ثانوية بشأن التقرير الأصلي. كان من الممكن أن يؤدي تقرير مكافأة اكتشاف الأخطاء الصادر في يناير 2025 إلى تكليف فريق الهندسة بمهمة ومراجعة البيانات الموجودة في إعدادات العلامات. لكن ذلك لم يحدث. ونحن نعمل حالياً على تحديث عملية الفرز لدينا لمنع تكرار حدوث ذلك في المستقبل.

2. أخطأت HackerOne في التعامل مع إغلاق التقرير باعتباره مكرراً. فقد وثّق تقرير أبريل 2026 تأثيراً جديداً بشكل جوهري مقارنةً بتقرير يناير 2025. ولم يكن ينبغي أن تغلقه HackerOne باعتباره مكرراً. وبعد مراجعة إضافية، حددنا حالتين أخريين تم فيهما إغلاق تقارير مماثلة – واحدة في 6 سبتمبر 2025، والأخرى في 1 يناير 2026. ونحن نعمل مع HackerOne لمعالجة الثغرات في عمليات الفرز الخاصة بهم. وسنقوم بإجراء مراجعة ثانوية لجميع تقارير HackerOne لضمان عدم اعتمادنا على عمليات الجهات الخارجية في المستقبل.

3. صنفت خدمة البريد الإلكتروني لدينا رسالة الباحث على أنها بريد مزعج. في يوم السبت، 25 أبريل، أرسل الباحث رسالة بريد إلكتروني إلى كل من الرئيس التنفيذي لشركتنا وإلى العنوان security@clickup.com، كما أرسل رسالة خاصة إلى حساب ClickUp على منصة X.

لم نرَ هذه الرسائل الإلكترونية إلا بعد نشر المنشور على منصة X. وقد تم العثور عليها في أعقاب تحقيق داخلي شمل مجلدات البريد العشوائي وتصفية الرسائل الخاصة على منصة X.

نحن نعمل على تحديث إجراءات تصفية البريد الإلكتروني ومراجعة الرسائل غير المرغوب فيها لضمان عدم حذف الرسائل الواردة ذات الصلة بالأمن دون إشعار.

لا شيء من هذا يبرر المشكلة الأساسية: لم يكن ينبغي أبدًا أن تتواجد بيانات العملاء في إعدادات علامات الميزات لدينا في المقام الأول.

ما قمنا به

فوري (تم إنجازه)

قصير الأجل (قيد التنفيذ)

طويلة الأجل

ملاحظة عن الباحث

بمجرد أن تواصلت ClickUp مع الباحث الذي كشف عن هذه المعلومات، والذي يستخدم الاسم المستعار impulsive / @weezerOSINT، تصرفت الشركة بمسؤولية وقدمت جميع المعلومات المطلوبة.

قام الباحث، الذي يستخدم الاسم المستعار impulsive / @weezerOSINT، بالإبلاغ عن المشكلة عبر القنوات الرسمية (HackerOne، ثم عبر بريد إلكتروني مباشر إلى security@clickup.com وإلى رئيسنا التنفيذي)، وتفاعل بشكل بناء عندما تواصلنا معه. لكن إجراءاتنا الداخلية لم تنجح في الكشف عن تقريره وطلبات التصعيد التي قدمها في الوقت المناسب.

بعد التعاون مع الباحث، تلقت ClickUp الرسالة التالية في 28 أبريل الساعة 1:47 بالتوقيت العالمي المنسق: «شكرًا [ClickUp]، أقدر حقًا السرعة التي تعاملتم بها مع هذا الأمر. هذا أمر لا أراه كثيرًا، وهو ما يُحدث فرقًا.»

تمنح ClickUp الباحث مكافأة مالية مقابل اكتشافه لهذا الخطأ. ونشجع الباحثين الآخرين على الانضمام إلى برنامج مكافآت اكتشاف الأخطاء لدينا، أو الإبلاغ عن الأخطاء بطريقة مسؤولة من خلال برنامج الإفصاح عن الثغرات الأمنية، أو مباشرة عبر البريد الإلكتروني على العنوان security@clickup.com.

ملخص

اقتصر نطاق البيانات التي تعرضت للاختراق في هذه الحادثة على 893 عنوان بريد إلكتروني – ولم يتأثر أي محتوى من مساحة العمل أو كلمات المرور أو بيانات الفوترة لأي عميل، باستثناء عميل واحد تمت الإشارة إليه أعلاه – ونحن نعمل معه مباشرة للتأكد من عدم الوصول إلى المفتاح بطريقة غير مشروعة.

نعتذر بشدة لعملائنا عن حدوث هذا الأمر، وسنبذل قصارى جهدنا لضمان عدم تكراره مرة أخرى.

سنقوم بتحديث هذا المنشور في حال ظهور أي معلومات جديدة. إذا كانت لديك أي أسئلة، يرجى التواصل معنا عبر البريد الإلكتروني security@clickup.com.