كشفت Hugging Face عن حادث أمني في يوليو 2026، ونصحت جميع المستخدمين بتدوير رموز الوصول ومراجعة نشاط الحساب الأخير. اتبع الخطوات التالية حتى إن لم تكن متأكدًا من تأثرك؛ بعد أي حادث أمني، يجب تدوير بيانات الاعتماد بناءً على الاشتباه لا على إثبات الاختراق.
ماذا حدث باختصار؟
- حصل عميل ذكاء اصطناعي مستقل على وصول إلى بنية Hugging Face التحتية خلال عطلة نهاية أسبوع في يوليو 2026.
- حصد الاختراق بيانات اعتماد الخدمة وانتقل عبر المجموعات الداخلية. أكدت OpenAI لاحقًا أن العميل كان أحد نماذجها، تم اختباره مع رفضات أمان مخفضة. اقرأ التفاصيل في تحليل اختراق OpenAI وHugging Face.
- لم تبلغ Hugging Face عن دليل على التلاعب بالنماذج العامة أو مجموعات البيانات أو Spaces، وتحققت من نظافة صور الحاويات والحزم المنشورة. وكان تقييم بيانات الشركاء والعملاء مستمرًا وقت الكشف.
الإجراء المطلوب للمستخدم الفردي واضح: دوّر جميع الرموز النشطة.
دوّر رمز Hugging Face الآن
- افتح صفحة رموز الوصول في إعدادات Hugging Face.
- راجع كل رمز نشط.
- انقر على إدارة لحذف الرمز القديم أو تحديثه. الحذف يبطل الرمز فورًا.
- انقر على رمز جديد لإنشاء بديل.
- اختر دور
fine-grainedلأي تطبيق إنتاجي أو مهمة CI/CD. - انسخ الرمز الجديد واحفظه مرة واحدة في مدير أسرار.
- حدّث كل خدمة أو بيئة تستخدم الرمز القديم.
- اختبر الرمز الجديد، ثم تحقق من أن الرمز القديم لم يعد صالحًا.
لا تحفظ الرمز في الشيفرة المصدرية أو في مستند مشترك. تدوير الرمز يغلق نافذة الاستخدام المتبقي لأي رمز تم تسريبه.
ابحث عن كل نسخة من الرمز القديم
التدوير لا يكتمل إلا بعد استبدال كل نسخة من الرمز. راجع المواقع التالية:
- ذاكرة التخزين المؤقت المحلية التي ينشئها
huggingface-cli login، غالبًا في:
~/.cache/huggingface/token
- متغيرات البيئة مثل:
HF_TOKEN
HUGGING_FACE_HUB_TOKEN
- ملفات
.envوملفات إعداد shell مثل.bashrcو.zshrc. - أسرار الدفاتر في Google Colab وKaggle وJupyter.
- أسرار CI/CD في GitHub Actions وGitLab CI وCircleCI.
- صور الحاويات ووسائط بناء Docker.
- أسرار مستودعات Hugging Face Spaces.
- مساعدي بيانات اعتماد Git عند استخدام HTTPS مع رمز ككلمة مرور.
- الخدمات الخلفية وتكاملات المورّدين التي تستدعي Hub أو موفري الاستنتاج نيابة عنك.
مثال على تحديث متغير بيئة محلي:
export HF_TOKEN="hf_رمزك_الجديد"
ثم اختبره:
huggingface-cli whoami
إذا بقيت نسخة قديمة في أي بيئة، فالتدوير غير مكتمل.
اختر نطاق الرمز الجديد بأقل صلاحيات ممكنة
تقدم Hugging Face ثلاثة أدوار للرموز. اختر الدور الأضيق الذي ينجز المهمة.
| الدور | الصلاحيات | استخدمه لـ |
|---|---|---|
fine-grained |
وصول محدود إلى المستودعات والمنظمات والأذونات التي تحددها | تطبيقات الإنتاج، مهام CI، الخدمات المشتركة |
read |
قراءة المستودعات التي لديك صلاحية قراءتها | تنزيل النماذج الخاصة وتشغيل الاستنتاج |
write |
قراءة وكتابة المستودعات التي لديك صلاحية الكتابة إليها | رفع النماذج وتحديث بطاقات النماذج وتحميلات التدريب |
اتبع قاعدتين عمليتين:
- أنشئ رمزًا منفصلًا لكل تطبيق أو خدمة.
- استخدم
fine-grainedفي الإنتاج لتقييد أثر التسريب على الموارد المحددة فقط.
الفكرة مماثلة لنموذج نطاقات OAuth 2.0: امنح أقل صلاحيات لازمة، لا أكبر مجموعة ممكنة.
راجع نشاط الحساب بعد التدوير
بعد إنشاء الرموز البديلة، ابحث عن أي نشاط غير متوقع:
- رموز وصول لا تتعرف عليها أو لم تعد تحتاج إليها.
- مستودعات أو التزامات حديثة في النماذج أو مجموعات البيانات أو Spaces لم تنشئها.
- عضويات أو أدوار منظمة لم تضفها.
- فواتير أو استخدام غير متوقع لموفري الاستنتاج.
- تطبيقات متصلة أو منح OAuth لطرف ثالث لم تصرح له.
إذا وجدت نشاطًا مريبًا، تواصل مع:
security@huggingface.co
ثم دوّر الرمز المتأثر مرة أخرى.
للفرق وCI/CD
في البيئات الجماعية، لا تكتفِ بتدوير رمز واحد يدويًا. طبّق هذه الإجراءات:
- استبدل رموز CI طويلة الأجل ببيانات اعتماد قصيرة الأجل.
- استخدم ميزة الناشرين الموثوق بهم من Hugging Face لتبادل هوية OIDC لموفر CI برمز Hub مؤقت عند بدء كل تشغيل.
- في خطط Team وEnterprise، طبّق سياسة الرموز
fine-grainedفقط. - استخدم إعدادات إدارة الرموز للموافقة على رموز المؤسسة أو رفضها أو إلغائها.
- احتفظ بسجل يربط كل رمز بالخدمة أو المستودع أو خط الأنابيب الذي يستخدمه.
مثال لتوثيق ملكية الرموز:
hf_prod_inference:
owner: inference-api
environment: production
scope: fine-grained
repositories:
- org/private-model
rotation_date: 2026-07-15
راجع أيضًا:
أبقِ الرمز بعيدًا عن طلبات الاختبار
قد يتسرب الرمز أثناء الاختبار أو التصحيح عند لصقه في طلب HTTP أو حفظه في مجموعة طلبات أو تضمينه في التزام Git. استخدم متغيرات البيئة بدلًا من كتابة الرمز داخل الطلبات.
مثال curl:
curl https://api-inference.huggingface.co/models/<model-id> \
-H "Authorization: Bearer $HF_TOKEN"
إذا كنت تستدعي Hugging Face Inference API، يمكن لـ Apidog حفظ الرمز كمتغير بيئة وتمريره كرمز حامل وقت إرسال الطلب. بهذه الطريقة:
- لا يظهر السر في الطلبات المحفوظة.
- تستبدل الرمز من مكان واحد بعد التدوير.
- تختبر نجاح التدوير مباشرة.
نفّذ اختبارين بعد التحديث:
- أرسل طلبًا بالرمز الجديد وتأكد من نجاحه.
- أرسل الطلب نفسه بالرمز القديم وتأكد من أنه يعيد
401أو403.
لمزيد من التفاصيل، راجع المصادقة الأساسية مقابل رمز الحامل.
ذو صلة:
الأسئلة الشائعة
هل يجب تدوير الرموز إذا لم أكن متأكدًا من تأثري؟
نعم. نصحت Hugging Face جميع المستخدمين بالتدوير. لا يمكنك معرفة بيانات الاعتماد التي قرأها المهاجم على وجه اليقين، بينما تكلفة التدوير منخفضة.
كيف أعرف إن استخدم شخص آخر رمزي؟
راجع قائمة الرموز، والالتزامات الأخيرة، وتغييرات المنظمة، والفواتير، والتطبيقات المتصلة. لا توفر Hugging Face مسار تدقيق كاملًا لكل رمز في الحسابات الشخصية، لذا اعتبر أي رمز شارك بيئة الحادث مشبوهًا ودوّره.
هل سيعطل التدوير النصوص البرمجية؟
نعم، إلى أن تحدّثها بالرمز الجديد. يجب تحديث كل نص برمجي ودفتر ملاحظات ومهمة CI تستخدم الرمز القديم. لهذا السبب يفضل استخدام رمز منفصل لكل تطبيق.
هل أستخدم read أم fine-grained؟
استخدم read للمهام الشخصية البسيطة، مثل تنزيل النماذج وتشغيل الاستنتاج. استخدم fine-grained للإنتاج وCI والخدمات المشتركة لأنه يقيد الوصول إلى الموارد التي تحددها.
أين أحفظ الرمز الجديد؟
احفظه في مدير أسرار أو متغير بيئة. لا تضعه في الشيفرة المصدرية أو خلية دفتر ملاحظات أو مستند مشترك.
Top comments (0)