ما الذي تفعله هاتان الثغرتان
تستهدف CVE-2026-6471 (CVSS 7.2) آلية فك الترميز المنطقي المُدرجة في PostgreSQL 9.4. يمكن لحساب يحمل صفة REPLICATION تحديد إضافة إخراج عشوائية عند إنشاء فتحة تكرار منطقية. قبل الإصلاح، كان PostgreSQL يحمّل الملف المطلوب عبر dlopen دون التحقق من مصدره، مما يتيح تنفيذ تعليمات برمجية بصلاحيات حساب النظام postgres. لا يحتاج المهاجم إلى وصول شبكي مباشر إلى خادمك: يكفي وجود نظير تكرار مخترق أو أداة CDC أو مستخدم داخلي يحمل صفة REPLICATION. يضيف الإصلاح معامل output_plugin_libraries يحدد المكتبات المسموح بها — يعتمد افتراضياً على pgoutput وtest_decoding فقط.
تُعدّ CVE-2026-14669 (CVSS 8.8) تجاوزاً لمخزن مؤقت في الكومة داخل الدالة to_char(timestamptz). تبني الدالة مخزناً مؤقتاً للعمل من سلسلة التنسيق، غير أن مسارات معالجة المناطق الزمنية POSIX تنسخ الاختصار الذي يوفره المستخدم في هذا المخزن دون فحص الطول. يمكن لأي مستخدم مصادَق اعتيادي تشغيل الثغرة بتمرير اختصار منطقة زمنية مفرط الطول، مما يؤدي إلى الكتابة فوق هياكل الكومة المجاورة وتحويل مسار التنفيذ لتنفيذ تعليمات برمجية اعتباطية بصلاحيات مستخدم النظام postgres.
مقارنة بين الثغرتين
| المعيار | CVE-2026-6471 | CVE-2026-14669 |
|---|---|---|
| درجة CVSS | 7.2 (مرتفع) | 8.8 (مرتفع) |
| المكوّن | فك الترميز المنطقي | `to_char(timestamptz)` |
| ناقل الهجوم | شبكة | شبكة |
| الصلاحية الدنيا المطلوبة | صفة REPLICATION | مستخدم مصادَق |
| هل يلزم وصول عام؟ | لا | لا |
| نوع التأثير | تنفيذ تعليمات برمجية | تنفيذ تعليمات برمجية |
| تاريخ الإصلاح | 2026-08-13 | 2026-08-13 |
الإصدارات المتأثرة والإصدارات المُصحَّحة
تؤثر كلتا الثغرتين على جميع فروع PostgreSQL المدعومة. الإصدارات المُصحَّحة، الصادرة في 13 أغسطس 2026، هي: PostgreSQL 18.6 و17.11 و16.15 و15.19 و14.24. أي نسخة تعمل على إصدار أقدم من هذه الأرقام تكون معرَّضة للخطر. لم تعد PostgreSQL 13 وما قبلها تتلقى تصحيحات لأنها بلغت نهاية عمرها الافتراضي. التطبيقات التي تضم PostgreSQL — كـ Supabase وNocoDB وGitea وTwenty CRM وPlanka — تتأثر إن لم تحدّث صورتها الأساسية بعد.
قبل التصحيح: مراجعة أدوار التكرار
قبل تطبيق التصحيح، من المفيد معرفة عدد الحسابات التي تحمل صفة REPLICATION على نسخك. تعرض الاستعلام التالي جميع الأدوار المعنية:
SELECT rolname, rolreplication, rolsuper FROM pg_roles WHERE rolreplication = true OR rolsuper = true ORDER BY rolsuper DESC, rolname;
إن وجدت حسابات بصفة REPLICATION لا تخدم تكراراً فعلياً، اسحب الصفة منها: ALTER ROLE اسم_الدور NOREPLICATION;. هذا إجراء تخفيف مؤقت ريثما يُطبَّق التصحيح، وممارسة جيدة دائمة.
التصحيح عبر apt على Debian وUbuntu
التحقق من الإصدار الحالي
اتصل بنسختك وتحقق من الإصدار الحالي: psql -U postgres -c 'SELECT version();'. دوّن الفرع (14 أو 15 أو 16 أو 17 أو 18) لتثبيت الحزمة الصحيحة.
التأكد من تهيئة مستودع PGDG
تُضمّن مستودعات Debian وUbuntu القياسية في الغالب إصدارات قديمة. للحصول على أحدث التصحيحات، استخدم المستودع الرسمي لـ PostgreSQL. إن لم يكن مهيأً: sudo apt install -y postgresql-common && sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh.
تحديث الحزم
التحديث الثانوي (17.10 → 17.11 مثلاً) لا يستلزم pg_upgradecluster ويحتفظ ببياناتك كما هي. نفّذ: sudo apt update && sudo apt install postgresql-17 (استبدل 17 بفرعك). بالنسبة للفروع الأخرى: sudo apt install postgresql-16 أو postgresql-15 أو postgresql-14.
إعادة تشغيل الخدمة
يجب إعادة تشغيل الخدمة لتحميل الثنائي الجديد: sudo systemctl restart postgresql. ثم تحقق من أن الخدمة انطلقت بشكل صحيح: sudo systemctl status postgresql.
التحقق من الإصدار بعد التصحيح
أعد الاتصال وتحقق من أن الإصدار المعروض يتوافق مع التصحيح: psql -U postgres -c 'SELECT version();'. يجب أن ترى 17.11 أو 16.15 أو 15.19 أو 14.24 أو 18.6 بحسب فرعك.
التصحيح عبر Docker
سحب الصورة المُصحَّحة
جرى تحديث الصور الرسمية postgres على Docker Hub بالإصدارات المُصحَّحة. اسحب الصورة المناسبة لفرعك: docker pull postgres:17.11 أو postgres:16.15 أو postgres:15.19 أو postgres:14.24. للصور Alpine: docker pull postgres:17.11-alpine.
إعادة تشغيل الحاوية
إن كنت تستخدم Docker Compose، حدّث وسم الصورة في ملف docker-compose.yml ثم نفّذ: docker compose pull && docker compose up -d. للحاويات المُشغَّلة مباشرة: docker stop postgres-container && docker rm postgres-container، ثم أعد التشغيل بالصورة الجديدة. تبقى بياناتك في المجلد المثبَّت — تأكد من تعريف المجلد قبل حذف الحاوية.
التحقق من الإصدار داخل الحاوية
اتصل بالحاوية وأكّد الإصدار: docker exec -it postgres-container psql -U postgres -c 'SELECT version();'. يجب أن تُظهر المخرجات الإصدار المُصحَّح.
إجراءات تخفيف مؤقتة إن تعذّر التصحيح فوراً
إن لم تتمكن من إعادة تشغيل النسخة فوراً، ثمة ثلاثة إجراءات تُقلل التعرض لـ CVE-2026-6471 دون تطبيق التصحيح:
أولاً، اسحب صفة REPLICATION من الحسابات التي لا تحتاجها (ALTER ROLE الاسم NOREPLICATION;). ثانياً، قيّد إدخالات التكرار في pg_hba.conf على عناوين IP للنظراء الشرعيين فقط — استبدل قاعدة host replication all 0.0.0.0/0 بإدخالات محددة لكل مضيف مصرَّح له. ثالثاً، إن كانت نسختك لا تستخدم التكرار المنطقي إطلاقاً، يمكنك ضبط wal_level = replica في postgresql.conf — هذا يعطّل فك الترميز المنطقي ويغلق ناقل هجوم CVE-2026-6471.
بالنسبة لـ CVE-2026-14669، لا يوجد حل بديل موثَّق على مستوى التطبيق: العلاج الوحيد هو تحديث الثنائي.
التحقق من التطبيقات التي تضم PostgreSQL
تضم كل من Supabase وNocoDB وGitea وTwenty CRM وPlanka قاعدة بيانات PostgreSQL في صورها Docker أو مخططات Helm الخاصة بها. لهذه التطبيقات، يعني تحديث PostgreSQL تحديث صورة التطبيق ذاتها. راجع ملاحظات إصدار كل تطبيق: منذ 13 أغسطس 2026، يجب أن تكون التوزيعات التي نشرت تحديثاً قد دمجت PostgreSQL 17.11 أو 16.15 أو ما يعادلهما. إن لم يتوفر تحديث لتطبيقك، يمكنك نشر حاوية PostgreSQL منفصلة بالإصدار المُصحَّح وتوجيه التطبيق إليها.
الأمر SELECT version(); في psql لا يكفي للتأكد من تفعيل التصحيح إن تعددت ثنائيات PostgreSQL على الخادم. تحقق من الثنائي الفعلي قيد التشغيل: يُدرج pg_lsclusters على Debian/Ubuntu جميع المجموعات مع إصداراتها. تأكد من أن المجموعة النشطة تستخدم الثنائي المحدَّث.
نشر PostgreSQL بصلاحيات root لتطبيق التصحيحات بنفسك
على الاستضافة المشتركة أو في بيئات PaaS، لا تملك صلاحية الوصول إلى ثنائي PostgreSQL: يتوقف التحديث على مزوّد الخدمة. على خادم VPS بصلاحيات root، تطبّق هذا التصحيح في أقل من عشر دقائق دون الاعتماد على أي طرف. أنت من يختار وقت إعادة التشغيل، وتحتفظ بالسيطرة على pg_hba.conf وتراجع أدوار التكرار بنفسك. هذا هو النموذج الذي ينطبق بطبيعة الحال على أي بنية مستضافة ذاتياً.
