ثغرة CVE-2026-119084 في Amazon Redshift JDBC Driver: تحميل غير آمن للأصناف، والتصحيح في الإصدار 2.3.0

ماذا حدث

نشرت AWS في 3 نوفمبر 2026 النشرة الأمنية 2026-168-AWS بشأن الثغرة CVE-2026-119084 (المعروفة أيضًا بالمعرّف GHSA-qrph-v96m-w2mv) في Amazon Redshift JDBC Driver. وتفيد نشرة AWS بأن برنامج التشغيل قد يحمّل أصنافًا عشوائية وينفّذها في ظروف معينة، وذلك عند معالجته معاملات عنوان اتصال JDBC أو حقول ملف تعريف بيانات اعتماد AWS (credentials profile).

• المتأثر: إصدارات Amazon Redshift JDBC Driver السابقة للإصدار 2.3.0.
• الإصدار المُصحِّح: 2.3.0. وتوصي AWS بالانتقال إلى أحدث إصدار، وهي توزعه عبر وثائق Redshift و Maven Central. ويوصف إصدار v2.3.0 على GitHub بأنه إصدار برنامج التشغيل 2.3.0.
• الأثر وفق AWS: من يستطيع التأثير في عنوان الاتصال أو ملف تعريف بيانات الاعتماد قد يتمكن من تنفيذ تعليمات برمجية ضمن سياق التطبيق.
• الشرط المسبق: يضيف وصفا NVD و OSV أن تنفيذ التعليمات البرمجية يتطلب وجود صنف مناسب في مسار أصناف التطبيق (classpath).
• نوع الضعف: يصنّفها سجل CVE ضمن CWE-470، أي الانعكاس غير الآمن (unsafe reflection).
• الخطورة: تصنّف AWS النشرة بأنها «Important (requires attention)». ويعرض NVD درجة CVSS أساسية قدرها 9.2، بينما لا يزال تحليله الخاص قيد الانتظار. ويتضمن سجل CVE أيضًا درجة CVSS v3.1 قدرها 8.1 (High، مع تعقيد هجوم High) إلى جانب درجة v4.0 البالغة 9.2 (Critical، مع متطلبات هجوم Present).
• النسخ المتفرعة: تنص AWS صراحةً على وجوب تصحيح الشيفرة المتفرعة أو المشتقة أيضًا.

لماذا يهم

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

1. يجب أن يتمكن المهاجم من التأثير في عنوان الاتصال أو ملف تعريف بيانات الاعتماد. في تقييمنا، لا يمكن بلوغ هذا المسار من مدخلات غير موثوقة حين يكون كلٌّ من سلسلة الاتصال وملف تعريف بيانات الاعتماد إعدادًا ثابتًا يحدده المشغّل. وعلى الفرق التحقق من ثبات المدخلين كليهما، لا عنوان الاتصال وحده.
2. يجب وجود صنف مناسب في classpath. يحتاج الانعكاس غير الآمن إلى صنف صالح لإنشاء نسخة منه. ومن المرجح أن تطبيقات Java ذات أشجار الاعتماديات الكبيرة تجعل تحقق هذا الشرط أسهل. ولا تحدد الأدلة الأصناف التي تستوفيه.

ترتفع درجة التعرض بشدة في البرمجيات التي تتيح لطرف غير المشغّل تشكيل الاتصال. وتشمل هذه الفئة:

• أدوات BI والتقارير التي يضيف فيها المستخدمون مصادر بياناتهم الخاصة
• منصات ETL وتكامل البيانات
• منتجات SaaS التي تتصل بعنقود Redshift الخاص بالعميل
• الميزات الداخلية من نوع «bring your own warehouse»
• الخدمات التي تركّب عناوين JDBC من سجلات المستأجرين أو من مخزن إعدادات مشترك

في هذه الأنظمة، يكون المُدخل الذي يتحكم فيه المهاجم هو ميزة المنتج نفسها.

أما الفئة الثانية فسهلة الإغفال: كل ما يضمّن برنامج التشغيل داخله. فعملاء SQL المكتبية وأدوات البيانات وأجهزة الموردين كثيرًا ما تحزم برامج تشغيل JDBC أو تُظلّلها (shading) داخل حزمها الخاصة. ولا تمس ترقية Maven أو Gradle في مستودعاتك هذه النسخ. ولهذا تكتسب تعليمات AWS بشأن الشيفرة المتفرعة أو المشتقة أهميتها.

التقييم الهندسي

تقييمنا: هذا تصحيح عالي الأولوية لأقلية من عمليات النشر، وترقية اعتمادية روتينية لما سواها.

يُضمِّن متجها CVSS في سجل CVE شرطًا مسبقًا: إذ يصنّف v3.1 تعقيد الهجوم بأنه High، ويحدد v4.0 متطلبات الهجوم بأنها Present. ومع ذلك يقيّم كلاهما الثغرة بأنها قابلة للوصول عبر الشبكة دون الحاجة إلى أي صلاحيات. ومن ثم فإن الشرط المسبق هو ما يحدد درجة التعرض الفعلية: من يستطيع التأثير في مدخلات الاتصال، وما الموجود في classpath.

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

أما حين يقدّم المستأجرون أو المستخدمون تفاصيل الاتصال، فتعامل مع الأمر بوصفه عاجلًا. ومنصات البيانات متعددة المستأجرين هي الحالة الأوضح، إذ قد يعني تنفيذ التعليمات البرمجية في سياق التطبيق هناك الوصولَ إلى بيانات اعتماد المستأجرين الآخرين وبياناتهم. وهذا مهم للمؤسسات في المملكة المتحدة والاتحاد الأوروبي والخليج الخاضعة لقواعد حماية البيانات والقواعد القطاعية في الرعاية الصحية والقطاع الحكومي.

لا يوفر شرط classpath طمأنينة تُذكر. فليس من السهل على الفرق تقدير مدى تحققه في عملية نشر نموذجية تعتمد على Spring أو Hadoop أو أدوات BI، كما أن الأدلة لا توضح شكل «الصنف المناسب». خطط على افتراض أن الشرط قابل للتحقق.

يصعب تقدير مخاطر الترقية. فصفحة الإصدار المتاحة لا تتضمن سجل تغييرات، ولذلك فإن نطاق التغيير مقارنةً بالإصدارات الأقدم غير معروف. وبالنظر إلى تصنيف CWE-470، يُرجَّح أن التصحيح يقيّد طريقة اختيار الأصناف من مدخلات الاتصال، لكن الأدلة لا تصف التغيير. وعلى الفرق التي تمرر أصناف إضافات (plugins) أو مزوّدين (providers) مخصصة عبر خصائص الاتصال أن تُجري اختبارات انحدار للمصادقة وإعداد الاتصال قبل التعميم الواسع.

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

هل يعنيك هذا؟

• تشغّل أي إصدار من Amazon Redshift JDBC Driver أقدم من 2.3.0، مباشرةً أو بصورة غير مباشرة (transitively).
• يستطيع المستخدمون أو المستأجرون أو العملاء إدخال تفاصيل اتصال Redshift أو تعديلها (المضيف، العنوان، الخصائص) في منتجك أو أدواتك الداخلية.
• تبني شيفرتك عناوين JDBC بدمج قيم من الطلبات أو سجلات المستأجرين أو مفاتيح تفعيل الميزات (feature flags) أو مخزن إعدادات مشترك.
• يمكن لأشخاص أو أنظمة غير مالك الخدمة تعديل ملفات تعريف بيانات الاعتماد التي يستخدمها برنامج التشغيل.
• تشحن أو تشغّل أدوات BI أو ETL أو دفاتر ملاحظات (notebooks) أو عملاء SQL تحزم برنامج تشغيل Redshift.
• تصون نسخة متفرعة (fork) أو نسخة مُظلّلة (shaded) أو شيفرة مصدرية مضمّنة (vendored) لبرنامج التشغيل.

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

ما الذي ينبغي فعله

1. ابدأ بالجرد. ابحث عن كل نسخة من برنامج التشغيل، لا عن الاعتماديات المعلنة فحسب:
   • mvn dependency:tree | grep -i redshift
   • gradle dependencies | grep -i redshift
   • find / -iname "*redshift*.jar" 2>/dev/null
   • للحزم الشاملة (fat) أو المُظلّلة: unzip -l your-app.jar | grep -i redshift
   • افحص صور الحاويات وقوائم مكونات البرمجيات (SBOM) بحثًا عن الحزمة نفسها.
2. رقِّ إلى 2.3.0 أو أحدث فورًا حيث يؤثر المستأجرون أو المستخدمون في تفاصيل الاتصال. أما الخدمات ذات الإعدادات الثابتة التي يملكها المشغّل، فأجرِ الترقية في دورة الإصدار الاعتيادية التالية، على أن تُقاس بالأيام لا بالأسابيع.
3. صحّح النسخ المتفرعة والمضمّنة. تنص AWS على أن الشيفرة المشتقة يجب أن تتضمن التصحيح. إن كنت تصون نسخة متفرعة، فأعد تأسيسها (rebase) على 2.3.0.
4. تابع الموردين. بالنسبة إلى أدوات BI و ETL و SQL من أطراف ثالثة التي تحزم برنامج التشغيل، اسأل عن إصدار برنامج التشغيل الذي تشحنه ومتى ستضمّن 2.3.0. وإلى ذلك الحين، قيّد من يستطيع إنشاء مصادر بيانات Redshift أو تعديلها في تلك الأدوات.
5. إذا تعذّرت الترقية فورًا، فاتبع الحل البديل المؤقت الذي تقدمه AWS:
   • راجع طريقة بناء عناوين الاتصال وملفات تعريف بيانات الاعتماد.
   • لا تبنِها من مدخلات غير موثوقة، أو تحقق من القيم الخارجية مقابل قائمة سماح بالمعاملات والقيم المتوقعة.
6. اختبر قبل التعميم الواسع. غطِّ مصادقة IAM والمصادقة الموحّدة (federated)، وأي أصناف مزوّدين مخصصة تُضبط عبر خصائص الاتصال، وسلوك تجميع الاتصالات (connection pooling).
7. ليست من توجيهات المورّد: شدّد صلاحيات الكتابة على مخازن الإعدادات والأسرار التي تحتفظ بسلاسل اتصال Redshift وملفات تعريف بيانات الاعتماد، وفعّل التنبيهات عند تغييرها. وحيث يقدّم المستخدمون تفاصيل الاتصال، اقبل حقولًا منظمة (المضيف، المنفذ، قاعدة البيانات) بدلًا من عناوين JDBC خام، وابنِ العنوان على جانب الخادم.

ما لا نعرفه بعد

• نقاط التفعيل: ما معاملات عنوان الاتصال وحقول ملف تعريف بيانات الاعتماد التي تؤدي إلى تحميل الأصناف. لا تسردها النشرة.
• آلية عمل التصحيح: لا تصف النشرة ولا صفحة الإصدار تغيير الشيفرة.
• توفر الأصناف القابلة للاستغلال (gadgets): ما الأصناف التي تُعدّ «مناسبة»، ومدى شيوعها في classpath التطبيقات وأدوات BI و ETL النموذجية.
• ملفات بيانات الاعتماد المشتركة: ما إذا كانت الإشارة إلى ملفات تعريف بيانات الاعتماد تعني تعرضًا عبر ملفات إعدادات AWS أو ملفات بيانات الاعتماد المشتركة. الأدلة لا توضح ذلك.
• حالة الاستغلال: لا يذكر أيٌّ من المصادر المتاحة ما إذا كانت الثغرة قد استُغلت.
• توقيت الإصدار: تُظهر صفحة الإصدار على GitHub تاريخ 15 أكتوبر دون ذكر السنة، أي قبل نشرة 3 نوفمبر. وليس واضحًا ما إذا كانت النسخة المُصحِّحة متاحة للعموم قبل النشرة الأمنية.
• المنتجات اللاحقة في السلسلة: ما المنتجات الشائعة التي تحزم برنامج التشغيل أو تُظلّله، ومتى ستشحن 2.3.0.
• التقييم النهائي: لا يزال تحليل NVD قيد الانتظار.

سيتابع المكتب تقييم NVD، وأي توسيع لنشرة GitHub الأمنية، وتصريحات الموردين الذين تضمّن أدواتهم برنامج التشغيل.

المصادر

• aws.amazon.com
• aws.amazon.com
• github.com
• github.com
• OSV
• NVD