دليل معالجة ثغرة Docker Desktop CVE-2026-114409

أصدرت Docker نسخة Docker Desktop 4.97.0 في 26 أكتوبر 2026 مع إصلاح CVE-2026-114409. قبل 4.97.0 كان نقص Redaction في IPC payloads قد يكتب مفاتيح API وOAuth access tokens لخدمات خارجية كنص صريح داخل سجلات Docker Desktop المحلية وحزم التشخيص. أي جهة تستطيع قراءة هذه الملفات قد تستخرج بيانات الاعتماد. وتوضح Docker أن OAuth tokens المقصودة ليست رموز حساب Docker.

الاستجابة الصحيحة أكبر من «ثبّت التحديث». تعالج 4.97.0 مسار التسجيل وتنظف Host logs وCrash dumps الموجودة، لكنها لا تستطيع سحب Diagnostic bundle رُفعت إلى نظام دعم أو نُسخت إلى Shared drive أو أُرفقت بتذكرة أو احتفظت بها أداة Endpoint أوBackup. اعتبر التحديث احتواءً أوليًا، ثم اعثر على كل نسخة، وحدد Providers والهويات المحتملة، وألغِ أو دوّر بيانات الاعتماد، وتحقق من الجهاز والأنظمة التابعة.

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

ماذا يغير CVE-2026-114409؟

تقول نشرة Docker إن الإصدارات السابقة لـ4.97.0 متأثرة. عالجت نسختا 4.94.0 و4.95.0 مسارات التسجيل المعروفة، لكن بيانات الاعتماد المكتوبة سابقًا قد تبقى في السجلات المحلية. تكمل Docker Desktop 4.97.0 الإصلاح وتضيف تنظيف Host logs وCrash dumps الموجودة.

يمر مسار الكشف بأربع مراحل:

يرسل Integration خارجي API key أوOAuth access token عبر IPC payload؛
يسجل Docker Desktop الـpayload دون Redaction كافية؛
يبقى الملف على الجهاز أو يدخل Diagnostic bundle؛
يستطيع إنسان أوService account أوSupport platform أوBackup agent أومهاجم يملك Read access استخراج السر.

لا يشترط أن يظهر السر في Application log لحاوية. الخلل يخص سجلات Docker Desktop المحلية والتشخيصات. لذلك فإن فحص stdout وstderr للحاويات فقط لا يكفي.

قرر الاستجابة بالدليل لا برقم الإصدار وحده

الحالة المرصودة	الحد الأدنى من الإجراء	السبب
4.97.0 أوأحدث، بلا تثبيت أقدم أوسجلات منقولة	تحقق من الإصدار والتنظيف وراقب	الإصلاح الحالي موجود، لكن تاريخ الأصل مهم
أقدم من 4.97.0، بلا Diagnostics مشتركة	حدّث، واجرد الملفات المحلية، ودوّر أي Credential مكتشفة	ربما قرأ مستخدم محلي السجلات
رُفعت Diagnostic bundle أوأرفقت بتذكرة	حدّث، وحدد المستلمين والاحتفاظ، وألغِ أو دوّر الأسرار، واحذف أونظف النسخ	خرج الملف من حدود الجهاز
جُمعت السجلات في EDR أوSIEM أوBackup أوFile sync	حدّث وابحث في كل مخزن تابع، وقيّد الوصول ودوّر الأسرار	التجميع المركزي يوسع القراء وفترة الاحتفاظ
ظهر استخدام للرمز من مصدر مجهول	ألغِ أولًا، واحتوِ الهوية، واحفظ الدليل وابدأ Incident Response	هذا دليل إساءة استخدام لا احتمال كشف فقط

لا تعتبر الجهاز آمنًا لمجرد أن نسخته الحالية 4.97.0. تحتاج تاريخ التثبيت ووجود الملفات القديمة وحركة Diagnostic bundles.

ابنِ جردًا للتعرض

أنشئ سجلًا لكل جهاز وArtifact. الهدف ربط نسخة Docker Desktop المتأثرة بمزود السر ووجهات الملف والإجراءات المنفذة.

{
  "device_id": "dev-mac-042",
  "docker_desktop_version_before": "4.96.1",
  "docker_desktop_version_now": "4.97.0",
  "diagnostics_generated": true,
  "artifact_destinations": ["support-ticket-1842", "endpoint-backup"],
  "credential_providers": ["source-control", "cloud-api"],
  "exposed_secret_values_stored": false,
  "rotation_status": "in_progress",
  "owner": "platform-security",
  "evidence_ref": "IR-2026-311"
}

لا تنسخ قيمة السر إلى هذا السجل. خزّن Provider أوCredential ID أوFingerprint أحادي الاتجاه فقط عندما يكون ذلك آمنًا ومعتمدًا. يجب ألا تتحول Incident tracker إلى Secret repository جديدة.

اجرد على الأقل:

تاريخ نسخ Docker Desktop ووقت التحديث؛
هل أُنشئت Diagnostics أو رُفعت أو نُسخت يدويًا؛
Local logs وCrash dumps وDiagnostic archives قبل المعالجة؛
Support tickets وEmail attachments وChat uploads؛
Shared folders وCloud drives وBackup snapshots وEDR collections وSIEM ingestion؛
الأشخاص وService accounts القادرون على قراءة كل وجهة؛
Providers التي ربما مرت مفاتيحها أوOAuth tokens الخاصة بها عبر Docker Desktop؛
Audit events من تلك الخدمات خلال نافذة التعرض.

إذا كان نظام الدعم أوالتخزين يفرض Immutable retention، فسجل القيد. حذف المرفق الظاهر لا يعني إزالة Replicas أوBackups أوLegal-hold copies.

في CVE-2026-114409 يوقف التحديث مسار التسجيل المعروف، بينما يعالج تدوير الأسرار النسخ التي ربما خرجت من الجهاز. اضغط لعرض أكبر

حدّث Fleet بأمان

استخدم قناة النشر المدارة المعتادة لتثبيت Docker Desktop 4.97.0 أوأحدث. نفذ Pilot على أجهزة Windows وmacOS ممثلة، خصوصًا الفرق التي تستخدم Proxies أوExtensions أوKubernetes أوData roots بديلة أوEnterprise settings. تحقق من النسخة المثبتة عبر Inventory موثوقة، لا من نجاح Package-manager job فقط.

يجب أن تثبت بوابات النشر:

يبدأ Docker Desktop ويبلغ 4.97.0 أوأحدث؛
تعمل الحاويات وCompose projects المطلوبة؛
يعمل Corporate sign-in والتكامل المطلوب؛
لا ينشئ الجهاز مادة تسجيل جديدة متأثرة ضمن المسار المختبر؛
اختفت أوتنظفت Host logs وCrash dumps التي يغطيها تنظيف Docker؛
تُتبع النسخ الخارجية منفصلة لأن Installer لا يستطيع تنظيفها.

لا تشغل Recursive secret scan تطبع Matches داخل CI logs. استخدم مسار Endpoint أوDLP معتمدًا يبلغ عن File IDs وأنواع الأسرار ويخفي القيم، وقيّد الوصول إلى النتائج.

ألغِ ودوّر حسب Provider

عندما يكون Credential قد ظهر في Artifact متأثرة، فضّل Revocation ثم Replacement على تعديل الملف المحلي فقط. قد ترتبط OAuth access tokens بـRefresh tokens أوSessions أوDelegated grants يحكمها Provider. اتبع نموذج الإلغاء لدى المزود وتأكد أن الرمز القديم يفشل.

لكل Credential:

حدد Provider والمالك وScope وWorkloads؛
قرر هل الإلغاء الفوري سيوقف Production؛
أنشئ بديلًا بأقل Scope وExpiry ممكنين؛
انشره عبر Secret manager المعتمدة؛
تحقق من الـworkload التابعة؛
ألغِ الرمز القديم وأنهِ Sessions المرتبطة عند توفر ذلك؛
راجع Audit logs لاستخدام من أجهزة أوIP ranges أوLocations أوأوقات غير متوقعة؛
سجل الدليل دون تسجيل السر.

إذا كان الرمز يحمي Write access أوإدارة Infrastructure أوSource control أوCloud resources أوCustomer data، فاستخدم مستوى استجابة أسرع. حتى Read-only credentials مهمة، لأن الكود والسجلات والMetadata قد تحتوي أسرارًا إضافية ومعلومات تشغيلية.

عامل ملفات التشخيص كبيانات حساسة

يجب أن يكون لكل Diagnostic bundle مالك وCase reference وRetention deadline وقائمة مستلمين واضحة. ارفعها عبر قناة الدعم المعتمدة فقط. قبل المشاركة استخدم مسار التجميع الحالي للمنتج وSanitization معتمدة؛ لا تفك الأرشيف على جهاز غير موثوق.

للنسخ الموجودة:

احذف المرفق أونظفه في Ticket system حيث يمكن؛
اطلب من جهة الدعم تأكيد الحذف وفق سياسة الاحتفاظ؛
احذف النسخ من Shared drives وChat systems؛
أنهِ الروابط العامة أوواسعة النطاق؛
سجل Backups وImmutable replicas التي لا يمكن حذفها فورًا؛
قيّد الوصول حتى تنتهي فترة الاحتفاظ؛
دوّر Credentials الممثلة حتى عند تأكيد الحذف، لأن القراءات السابقة لا يمكن عكسها.

الحذف ليس دليلًا على أن السر لم يُقرأ. Rotation هي الضابط الذي يبطل Credential.

الكشف والتحقيق

ابدأ من Audit trail لدى Provider لا من نتيجة grep وحدها. ابحث عن استخدام الرمز من IP ranges أوأجهزة أوUser agents أوRepositories أوOrganizations أوCloud regions جديدة، وتغييرات OAuth grants غير المتوقعة، ومفاتيح أوجلسات جديدة، وPrivileged API operations، وتنزيلات كود، ونشاط خارج ساعات المستخدم المعتادة.

افصل بين ثلاث نتائج:

Vulnerable: كانت نسخة متأثرة مثبتة؛
Exposed: ظهر Credential في Log أوBundle أوخرج الملف من الجهاز؛
Compromised: يوجد دليل على استخدام أوتحكم غير مصرح.

لا تصف كل جهاز متأثر بأنه مخترق. وبالمقابل لا تغلق الحالة لعدم وجود Docker errors؛ إذ يمكن استخدام Credential صحيح عبر الخدمة الخارجية دون لمس Docker مجددًا.

إذا ظهر Misuse، فاحفظ أدلة Endpoint وIdentity provider وService audit قبل التنظيف الواسع. احتوِ الحساب، وألغِ الأسرار، وراجع Persistence والتغييرات اللاحقة، واتبع خطة Incident response.

أفضل الممارسات

فرض حد أدنى لنسخة Docker Desktop عبر Device management.
حفظ Credentials الخارجية في OS-backed أوEnterprise secret stores.
استخدام Tokens قصيرة العمر ومحدودة النطاق حيث يدعم Provider.
معاملة Diagnostic bundles كملفات قد تحمل أسرارًا افتراضيًا.
رفع Diagnostics إلى Cases مسماة بقراء محدودين وExpiry.
جرد النسخ في Ticketing وChat وDrives وBackups وEDR وSIEM.
تدوير الأسرار بعد الكشف المحتمل؛ الحذف وحده غير كافٍ.
إثبات فشل Credentials القديمة ونجاح Workloads بالبدائل.
مراقبة Provider audit logs أثناء Rotation وبعدها.
إبقاء Evidence خالية من القيم السرية.

Anti-patterns

التحديث إلى 4.97.0 ثم إغلاق الحادث.
فحص Container logs فقط وتجاهل سجلات Docker Desktop.
نشر Diagnostic archive في Public issue أوقناة واسعة.
نسخ Token values المكتشفة إلى Spreadsheet أوTicket.
حذف Bundle مع إبقاء Credential صالحة.
تدوير Access token دون فحص Refresh grants أوSessions.
افتراض أن Docker account tokens هي المتأثرة رغم توضيح Docker.
وصف الثغرة كاختراق مؤكد دون دليل.
تشغيل Scanner تطبع Matches في نظام Logs آخر.
نسيان Backups وImmutable retention.

القيود

تحدد نشرة Docker الإصدارات والسبب وأنواع البيانات وسلوك التنظيف المحلي، لكنها لا تسرد كل Provider خارجي أوLog location أوEnterprise collection agent أوRetention path. ولا تقول إن استغلالًا حدث في بيئة بعينها. لذلك تعتمد خطوات التحقيق والإلغاء الدقيقة على نظام التشغيل وDevice management ومسار الدعم ومزود الرمز ومتطلبات الاحتفاظ القانونية.

الالتزام بالنسخة ضروري لكنه غير كافٍ. الضابط الدائم هو Artifact lifecycle تفترض أن Diagnostics قد تحمل بيانات حساسة، وتقلل Scope وعمر Tokens، وتسجل حركة Bundles، وتستطيع إلغاء الوصول بسرعة.

الخلاصة التنفيذية

CVE-2026-114409 مشكلة كشف بيانات اعتماد ذات أثر طويل. ثبّت Docker Desktop 4.97.0 أوأحدث لإيقاف مسار التسجيل المعروف وتنظيف Host artifacts التي يغطيها الإصلاح. ثم اعثر على Diagnostic bundles والسجلات المنسوخة، واربطها بالـProviders والقراء، وألغِ أو دوّر Credentials، وراجع Audit trails، وأثبت أن الرموز القديمة والملفات غير الآمنة لم تعد قابلة للاستخدام. اجعل Update وRotation وVerification وEvidence أربع بوابات مستقلة.

تابع عبر محور Cloud وDevOps وKubernetes، وخدمات هندسة البرمجيات والذكاء الاصطناعي والسحابة، ودليل تقوية Docker Runtime، ودليل BuildKit الآمن، واستجابة تحديث Node.js الأمني.

المراجع الأساسية

إعداد: Noor Yasser

المراجع الرسمية

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

إعداد: Noor Yasser

نور ياسر

مهندس برمجيات ومنتجات، أعمل على أنظمة SaaS والتكاملات وتطبيقات الذكاء الاصطناعي.

خبرة الكاتب ومسيرته ←

من القرار إلى التنفيذ

تعمل على تحدٍ تقني مشابه؟

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

احجز لقاءً لمدة ٣٠ دقيقة الخدمة المرتبطةهندسة الأنظمة الخلفية وتكاملات APIمشروع من الأعمالمنصة اللوجستيات

ثغرة Docker Desktop CVE-2026-114409: دوّر الأسرار بعد التحديث