تحديث Flutter 3.47.8 الأمني: لماذا لا يكفي تحديث SDK دون إعادة بناء التطبيق؟

أصدر فريق Dart وFlutter إصلاحًا أمنيًا عالي الخطورة بعد اكتشاف شهادات وسيطة صادرة عن eMudhra بمفاتيح ضعيفة يمكن اشتقاقها. في السيناريو المتأثر، يستطيع مهاجم موجود على مسار الشبكة إنشاء شهادة TLS مزورة واعتراض اتصال HTTPS لتطبيق مبني بإصدار قديم من الـSDK.

أول إصدارات مستقرة تتضمن الإصلاح هي Dart 3.13.7 وFlutter 3.47.8؛ والإصدارات الأحدث مثل Flutter 3.47.9 تتضمنه أيضًا. لكن تنفيذ flutter upgrade على جهاز المطور لا يصلح التطبيقات الموجودة بالفعل على أجهزة المستخدمين؛ يجب إعادة بناء النسخ المتأثرة ثم نشرها. هذا المقال يوضح من يتأثر، وكيف تفحص مشروعاتك، وخطة تحديث واختبار وإطلاق عملية لمطور مستقل أو فريق منتج.

ما الذي حدث بالضبط؟

وفق التنبيه الأمني الرسمي، كُشف في أكتوبر 2026 عن ثماني شهادات وسيطة تابعة لـeMudhra أُنشئت بمفاتيح ذات عشوائية ضعيفة. قد يسمح ذلك باشتقاق المفاتيح الخاصة وإنشاء شهادات تبدو صالحة لأي نطاق. إذا تحكم المهاجم في مسار الشبكة — مثل شبكة غير موثوقة أو بنية مخترقة — فقد يحاول اعتراض TLS.

يتحدد التأثر بحسب مسار الاتصال: الاتصالات التي تستخدم dart:io، مباشرة أو عبر Dio وhttp بإعداداتهما الافتراضية على المنصات المتأثرة، تدخل ضمن نطاق التنبيه. أما الاتصالات عبر SDKs أصلية أو adapters مختلفة، فتحتاج مراجعة منفصلة.

حدّث الإصلاح BoringSSL داخل Dart لحظر الشهادات الوسيطة المخترقة صراحة. وعلى Android 14 فأحدث، أصبح dart:io يستخدم مخزن الجذور القابل للتحديث في Conscrypt APEX، ما يساعده على احترام عمليات الإلغاء المستقبلية التي تصل عبر تحديثات نظام Google Play.

ما المنصات والإصدارات المتأثرة؟

التنبيه يحدد النطاق التالي لاتصالات dart:io:

إصدارات beta المصححة هي Flutter 3.50.0-0.2.pre وDart 3.14.0-315.3.beta. إذا كان إنتاجك على stable، لا تنتقل إلى beta فقط للحصول على الإصلاح؛ استخدم stable المصحح.

لماذا لا يكفي تحديث جهاز المطور؟

تطبيق Flutter يحتوي runtime وأجزاء مترجمة وقت البناء. النسخة التي حمّلها المستخدم من المتجر لا تتغير عندما تحدّث Flutter محليًا. لذلك الإصلاح الكامل يتطلب:

1. تحديد التطبيقات والبنيات المتأثرة.
2. تثبيت SDK مصحح في التطوير وCI.
3. إعادة البناء، لا مجرد إعادة تشغيل الاختبارات على ملف APK قديم.
4. اختبار النسخة الجديدة.
5. نشرها على المتاجر أو قنوات التوزيع الداخلية.

إذا كنت تدير تطبيق عميل بعد التسليم، راجع عقد الصيانة ومسؤولية التحديثات الأمنية. التنبيه يحتاج قرار إصدار، وليس commit تقنيًا فقط.

خطة استجابة عملية

1. أنشئ قائمة بالمشروعات والبنيات

ابدأ بالمشروعات التي تشحن Android أو Windows أو Linux. سجّل لكل مشروع:

• إصدار Flutter المثبت في CI أو FVM.
• آخر رقم بناء منشور.
• قنوات الإنتاج والاختبار الداخلي.
• ما إذا كانت هناك حاويات Dart/Linux ثابتة.
• مالك قرار الإصدار وبيانات المتجر المطلوبة.

لا تعتمد على flutter --version في جهازك الحالي لإثبات إصدار النسخة المنشورة. ابحث في سجلات CI، وملف FVM، وصورة Docker، وبيانات build القديمة إن توفرت.

2. ثبّت الإصدار المصحح

للقناة المستقرة:

bashflutter channel stable
flutter upgrade
flutter --version
dart --version

تحقق أن Flutter لا يقل عن 3.47.8 وأن Dart لا يقل عن 3.13.7. إذا كان المشروع يثبّت إصدارًا محددًا عبر FVM أو CI، حدّث المصدر المثبت نفسه؛ تحديث جهاز واحد لا يغيّر runner أو صورة Docker.

3. اجعل التغيير صغيرًا

لا تجمع الإصلاح الأمني مع ترقية كبيرة للحزم أو إعادة هيكلة. الهدف أن تعرف إن كان أي خلل ناتجًا عن تحديث SDK. سجّل قبل الترقية:

bashflutter doctor -v
flutter pub deps --style=compact
git status --short

بعدها نفّذ flutter pub get وراجع التغييرات في lockfiles. لا تحذف lockfile تلقائيًا لتجاوز تعارض؛ افهم سبب التغيير أولًا.

4. اختبر ما يثبت السلوك الفعلي

ابدأ ببوابات المشروع:

bashdart format --output=none --set-exit-if-changed .
flutter analyze
flutter test
flutter build appbundle --release

ثم اختبر نسخة release على جهاز Android حقيقي. مرّ على تسجيل الدخول، وتجديد token، ورفع الملفات، والإشعارات، والمدفوعات، وأي اتصال بخادم مخصص. لا يكفي نجاح اتصال واحد؛ الهدف كشف regressions بسبب تغيير SDK أو الاعتماديات المصاحبة.

بالنسبة إلى Windows أو Linux، ابنِ الحزمة على بيئة مماثلة للإنتاج. ولحاوية Dart، حدّث صورة الأساس وca-certificates بجانب Dart المصحح، ثم أعد بناء الصورة دون الاعتماد على cache قديمة.

5. نفّذ إطلاقًا مرحليًا

في Google Play، ابدأ بقناة اختبار داخلية ثم rollout محدود إذا كانت سياساتك تسمح. راقب Crashlytics، وأخطاء الشبكة، ونسب تسجيل الدخول، ومراجعات المستخدمين. جهّز قرارًا واضحًا للتوسيع أو الإيقاف.

لا تستخدم rollback إلى نسخة ضعيفة كخطة أساسية. إذا ظهر regression، أصلح النسخة المصححة أو قلّل النطاق مع الحفاظ على SDK الآمن.

هل certificate pinning يغني عن التحديث؟

لا. قد يقلل pinning بعض سيناريوهات الاعتراض إذا صُمم وأُدير جيدًا، لكنه لا يلغي الحاجة إلى تحديث runtime. كما أن pinning الخاطئ قد يوقف التطبيق عند تدوير شهادة الخادم. اعتبره قرارًا معماريًا مستقلًا يحتاج خطة مفاتيح احتياطية وتدويرًا ومراقبة، وليس بديلًا سريعًا للإصلاح الرسمي.

وبالمثل، استخدام HTTPS لا يعني أن كل طبقة سليمة إلى الأبد؛ قوة HTTPS تعتمد أيضًا على سلسلة الثقة والـruntime ونظام التشغيل.

Clean Architecture لا تعزل هذا النوع من المخاطر

قد تكون طبقة الشبكة مفصولة جيدًا خلف Repository، لكن التحقق من TLS يحدث أسفلها. فائدة المعمارية هنا هي سهولة اختبار حالات الفشل ومراقبة الواجهات، لا منع ثغرة في runtime.

يمكن لـBLoC أن يعرض حالة خطأ واضحة ويمنع فقد البيانات عند انقطاع الاتصال، لكنه لا يثبت هوية الخادم. الأمان هنا مسؤولية مشتركة بين SDK وإعدادات المنصة والبنية الخلفية وعملية الإصدار.

تحليل: ما الدرس الأطول عمرًا؟

التحليل الهندسي هو أن أصول البناء جزء من سطح أمان المنتج. الاحتفاظ بقائمة إصدارات SDK وصور CI ليس عمل DevOps زائدًا؛ هو ما يجيب بسرعة عن سؤال «أي نسخة منشورة تحتاج إعادة بناء؟».

للمطور المستقل، أفضل إجراء وقائي هو جعل الإصدار قابلًا للإعادة: SDK مثبت، CI موثق، مفاتيح النشر محفوظة بطريقة آمنة، واختبارات دخان للرحلات الأساسية. عند ظهور تنبيه مشابه، يتحول العمل من بحث مرتبك إلى مسار إصدار معروف.

الخلاصة

إذا كان لديك تطبيق Android أو Windows أو Linux يتصل عبر dart:io (مباشرة أو عبر Dio أو http بالإعدادات الافتراضية) ومبني بإصدار Flutter أقدم من 3.47.8، حدّث بيئة البناء إلى 3.47.8 أو أحدث، وأعد بناء التطبيق، واختبره، ثم أعد نشره. وراجع الاتصالات التي تمر عبر SDKs أصلية مثل Firebase بشكل منفصل. لا تدّع أن الخطر اختفى لمجرد تحديث جهاز المطور.

المصادر

• Dart/Flutter security advisory GHSA-frr6-h895-5pxp — نُشر 23 أكتوبر 2026
• Flutter changelog — 3.47.8 أول إصدار stable يتضمن الإصلاح، ويظهر فيه 3.47.9 أيضًا؛ تم التحقق 9 نوفمبر 2026
• Flutter 3.47.8 release tracker — اكتمل 26 أكتوبر 2026