Arch Linux AUR تتعافى من هجوم بثلاث موجات استهدف أكثر من 1500 حزمة

أزمة غير مسبوقة في مستودع AUR

في 11 يونيو 2026، انكشف هجوم واسع النطاق استهدف مستودع AUR (Arch User Repository) وهو المصدر غير الرسمي لحزم توزيعة Arch Linux والذي يعتمد عليه آلاف المستخدمين يومياً [citation:1][citation:9]. المهاجمون تمكنوا من الاستيلاء على مئات الحزم المهملة (orphaned packages) وحقنها بأكواد ضارة، ثم نشروها كتحديثات “شرعية” [citation:5][citation:9].

ما بدأ كهجوم استهدف حوالي 400 حزمة تحول إلى كارثة أمنية كبرى شهدت ثلاث موجات متتالية من الهجمات، قبل أن يتمكن فريق Arch Linux من احتواء الوضع بالكامل وتأكيد عودة الأمور إلى نصابها [citation:7][citation:8].

🔗 المصدر الرسمي: archlinux.org/news/active-aur-malicious-packages-incident/ 🔗 قائمة الحزم المتضررة: github.com/c78-contrib/cleanup-aur-blacklist

تفاصيل الهجوم: كيف تم الاختراق؟

الموجة الأولى: الهجوم الأساسي عبر NPM

في البداية، استغل المهاجمون آلية “تبني الحزم” في AUR. الحزم المهملة (orphaned packages) هي حزم تخلى عنها مطوروها الأصليون. أي مستخدم يمكنه تبنيها والمطالبة بصلاحية التحديث [citation:5]. استولى المهاجمون على مئات الحزم المهملة، وفي غضون ساعات، قاموا بتعديل ملفات PKGBUILD الخاصة بهم [citation:1][citation:5].

التعديلات كانت ماكرة. تم إضافة سطر واحد في نص التثبيت لاستدعاء npm (مدير حزم JavaScript)، وتثبيت حزمة ضارة باسم atomic-lockfile [citation:1][citation:5]. هذه الحزمة كانت تحتوي على ملف خبيث باسم deps [citation:1][citation:9].

عند قيام أي مستخدم بتثبيت أو تحديث هذه الحزمة المخترقة باستخدام مساعد AUR (مثل yay أو paru)، كان الكود الخبيث يُنفذ على جهازه [citation:1][citation:3].

الموجة الثانية: هجوم أكثر تعقيداً بالتعتيم (Obfuscation)

بعد أن أعلن فريق Arch Linux عن السيطرة على الهجوم الأول وإزالة الحزم المخترقة، ظن الجميع أن الأزمة قد انتهت. لكن في اليوم التالي، رصد المطور a821 موجة جديدة من الحزم المخترقة [citation:8]. هذه المرة، استخدم المهاجمون تقنيات تعتيم متقدمة (code obfuscation) لإخفاء الأكواد الضارة وجعل اكتشافها أكثر صعوبة [citation:7][citation:8].

طالت الموجة الثانية حزم متعددة، منها أدوات Node.js، إضافات Firefox، ومكونات سطح المكتب (Plasma 6 applets) [citation:7][citation:8].

الموجة الثالثة: استغلال Bun والذكاء الاصطناعي

لم تتوقف الأمور عند هذا الحد. بمساعدة باحث مستقل استخدم نموذج ذكاء اصطناعي (Gemma E2B) محلياً، تم اكتشاف موجة ثالثة من الهجمات [citation:7][citation:8]. هذه المرة، استغل المهاجمون bun (بديل سريع لـ Node.js) لتنفيذ الأوامر الخبيثة. الأكواد كانت أكثر تمويهاً وتم إخفاء الأنشطة الضارة في تدفق أوامر bun [citation:8].

البرمجية الخبيثة: ماذا كانت تفعل؟

الملف الخبيث deps لم يكن مجرد برمجية بسيطة لسرقة كلمات المرور، بل كان أداة هجوم متكاملة [citation:9].

سرقة شهادات المطورين (Credential Stealer)

استهدف البرنامج بيئات عمل المطورين بدقة عالية. البيانات التي حاول سرقتها شملت [citation:1][citation:3][citation:9]:

بيانات المتصفحات (ملفات تعريف الارتباط) من Chrome و Firefox و Brave.
رموز الوصول لمنصات مثل GitHub، GitLab، npm.
مفاتيح SSH الخاصة.
بيانات من تطبيقات التواصل: Slack، Discord، Microsoft Teams، Telegram.
بيانات Docker و Podman.
ملفات السجل الطرفي (Bash/Zsh history) التي قد تحتوي على كلمات مرور أدخلها المستخدم.

الهدف كان واضحاً: السيطرة على حسابات المطورين للوصول إلى المشاريع مفتوحة المصدر والبنية التحتية السحابية الخاصة بهم.

جذر خفي (Rootkit) باستخدام eBPF

الجزء الأخطر في هذه البرمجية هو قدرتها على تثبيت جذر خفي (Rootkit) باستخدام تقنية eBPF (Extended Berkeley Packet Filter) [citation:1][citation:9]. إذا تم تشغيل البرمجية بصلاحيات الجذر (root)، فإنها تستطيع التخفي في نواة النظام وإخفاء وجودها، مما يجعل اكتشافها وإزالتها بالطرق التقليدية صعبة جداً [citation:9].

رد فعل الفريق والمجتمع

بمجرد اكتشاف الهجوم، تحرك فريق Arch Linux بسرعة. قاموا بتعطيل إنشاء الحسابات الجديدة مؤقتاً، وإيقاف القدرة على رفع التحديثات، وشرعوا في حملة لحذف الحزم المخترقة وإغلاق حسابات المهاجمين [citation:6].

في 15 يونيو، أكد الفريق أنه تم إزالة جميع الحزم المخترقة والكود الخبيث، وأن الخطر قد زال [citation:7]. وتم نشر قائمة شاملة بالحزم المتضررة ليتمكن المستخدمون من مراجعة أنظمتهم [citation:1][citation:4].

كما طور المجتمع أدوات مساعدة، مثل سكريبت cleanup-aur.sh، الذي يقوم بفحص النظام بحثاً عن الحزم المصابة ويساعد في إزالتها [citation:4].

التذكير: طبيعة مستودع AUR

هذه الحادثة أعادت التذكير بطبيعة مستودع AUR الخطيرة. AUR ليس مستودعاً رسمياً. الحزم الموجودة فيه لا تخضع لمراجعة أمنية أو تدقيق من فريق Arch Linux [citation:5][citation:6].

عند تثبيت حزمة من AUR، فأنت في الواقع تقوم بتنزيل ملف PKGBUILD (نص بناء) يقوم بتحميل الكود المصدري وتجميعه على جهازك. أي شخص لديه حساب يمكنه رفع هذه النصوص. لذلك، تقع مسؤولية الأمان بالكامل على عاتق المستخدم [citation:5][citation:6].

كيف تحمي نفسك؟

أكد المطورون مجدداً على القاعدة الذهبية للتعامل مع AUR: تحقق بنفسك. لا تقم أبداً بتثبيت أي حزمة أو تحديث من AUR دون مراجعة ملف PKGBUILD أولاً [citation:5][citation:6].

يُنصح مستخدمو Arch Linux الذين قاموا بتثبيت أي حزمة من AUR خلال الأيام الماضية بالقيام بالخطوات التالية:

مراجعة قائمة الحزم المتضررة المنشورة من قبل المجتمع للتأكد من عدم تثبيت أي منها.
استخدام سكريبتات الفحص الآلي المتاحة مثل cleanup-aur.sh [citation:4].
إذا تبين أن النظام مخترق، يجب افتراض أن جميع الشهادات (API tokens، مفاتيح SSH) قد تم اختراقها، ويجب تدويرها فوراً (تغييرها جميعاً) [citation:1].
في الحالات المتقدمة التي يُشتبه فيها بتثبيت الجذر الخفي (rootkit)، يُوصى بإعادة تثبيت النظام بالكامل من الصفر لضمان التخلص من أي باب خلفي [citation:1].

خلاصة

حادثة اختراق AUR كانت بمثابة جرس إنذار لمجتمع Arch Linux ولجميع مستخدمي توزيعات لينكس بشكل عام، تذكرنا بأن “الثقة” في البرمجيات يجب أن تكون محدودة ومصحوبة بالتدقيق. فريق Arch Linux نجح في احتواء الموقف، لكن الدرس الأهم هو أن المستخدم النهائي هو خط الدفاع الأخير والأهم عند التعامل مع برمجيات المجتمع.