ثغرة ClickHouse CVE-2026-116366: حدّث دون فقد السيطرة على العنقود

كشفت ClickHouse في 30 أكتوبر 2026 عن CVE-2026-116366، وهي ثغرة Critical قد تسمح لمستخدم غير مصادق يملك وصولًا شبكيًا بتنفيذ تعليمات برمجية عشوائية على ClickHouse Server عند تحقق ظروف معينة. نشرت الشركة إصدارات مصححة للخطوط المدعومة 26.3 LTS و26.8 LTS و26.9 stable و26.10 stable، وتقول إن الإصلاح طُبق على كل ClickHouse Cloud وBYOC.

النشرة العامة مقتضبة عمدًا؛ لا تحدد Parser أوProtocol Message أوListener التي تصل إلى المسار الضعيف، ولا تدعي المصادر الأولية التي تمت مراجعتها وجود استغلال نشط. لذلك لا تخترع Workaround مرتبطة بمنفذ بعينه ولا تختبر Exploit Strings عامة. قلل الوصول إلى كل ClickHouse Listener، وحدّث كل Server Process إلى إصدار مصحح، وأثبت خروج العمليات القديمة، ثم افصل مراجعة أدلة الاختراق عن مهمة التحديث.

يفصل هذا المقال بين حقائق المورد والتوصيات الهندسية. وصف الثغرة والإصدارات المصححة والفروع المدعومة وحالة Cloud/BYOC موثقة من ClickHouse. أما Cluster Rollout وVerification Queries وضوابط الاحتواء ونموذج الأدلة أدناه فهي توصيات تشغيلية مبنية على المصادر العامة كما تمت مراجعتها في 31 أكتوبر 2026.

الخلاصة أولًا

إذا كنت تشغّل ClickHouse Server فانتقل فورًا إلى أحد هذه الإصدارات:

لا تحتفظ بفرع 25.x غير مدعوم أوفرع 26.x غير مدعوم كهدف Rollback. تضع سياسة ClickHouse حاليًا 26.10 و26.9 و26.8 و26.3 ضمن الفروع المدعومة، وتصف 26.7 و26.6 و26.5 و26.4 و26.2 و26.1 والخطوط الأقدم بأنها غير مدعومة.

حتى تعمل النسخة المصححة في كل مكان، قلّص Network Reachability إلى أصغر مجموعة موثوقة من Clients وInter-node Peers. ولأن ClickHouse لم تكشف Listener أوTrigger Message بعينها، فتعامل مع HTTP وHTTPS وNative TCP وSecure Native TCP وInter-server Paths كمسارات ضمن النطاق عندما تكون مكشوفة في نشرك. هذا حد هندسي محافظ، وليس ادعاء من المورد بأن كل Protocol ضعيفة.

Inventory -> تقييد Listeners -> Fixed Artifacts متحقق منها
          -> Canary لكل Replica -> استبدال العمليات القديمة
          -> إثبات Version عبر العنقود -> Functional Checks
          -> Evidence Review -> إغلاق أوتصعيد Incident

ماذا تقول ClickHouse فعلًا؟

تقول Security Changelog الرسمية إن CVE-2026-116366 قد تسمح، في ظروف محددة، لمستخدم غير مصادق لديه وصول شبكي بتنفيذ كود على ClickHouse Server. وتسمي الإصدارات الأربعة المصححة أعلاه وتؤكد تطبيق الإصلاح على كل ClickHouse Cloud وBYOC.

تصف حزم ClickHouse الرسمية المشكلة بأنها Critical وتنشر DEB وRPM وTGZ للخطوط المصححة، وتوفر ملفات SHA-512 إلى جوار TGZ. ويعطي سجل CVE العام، الذي أسندته ClickHouse، درجة CVSS v4.0 مقدارها 9.5 ويصنف الضعف CWE-190: Integer Overflow or Wraparound.

هذه الحقائق تثبت الاستعجال، لكنها لا تثبت اختراق Host لديك. لا توثق المصادر الأولية العامة التي تمت مراجعتها Proof of Concept أواستغلالًا في البرية. افصل الحالات التالية:

1. وجود Build ضعيفة؛
2. وصول شبكة غير موثوقة إليها؛
3. رصد Request أوCrash مشبوهة؛
4. إثبات الوصول إلى Vulnerable Code Path؛
5. تأكيد Unauthorized Execution أوPersistence.

الدليل وحده ينقل الحادث بين هذه الحالات.

ابن جردًا يعكس العنقود العامل

ابدأ بالعملية التي تخدم Traffic فعلًا، لاImage Tag أوDeployment Manifest.

SELECT hostName() AS host, version() AS version;

SELECT
    hostName() AS host,
    version() AS version
FROM clusterAllReplicas('default', system.one)
ORDER BY host;

الاستعلام الثاني مثال؛ استبدل default باسم Cluster Definition الصحيحة. ولا تفترض أن Query ناجحة من Coordinator واحدة تصل إلى كل Shard وReplica وKeeper Node وStandby Host وDisaster-recovery Environment.

سجل لكل Instance:

• Hostname أوCloud Instance أوKubernetes Pod Identity؛
• إصدار ClickHouse الذي تعيده Live Process؛
• Package Build أوContainer Image Digest؛
• Process Start Time وParent Service Unit؛
• دور Shard وReplica وAvailability Zone؛
• Listeners وLoad Balancers وFirewall Rules وService Meshes؛
• Inter-server Credentials وCertificate Policy؛
• Package Repository وArtifact Checksum وSignature Evidence؛
• Configuration Revision وUser-policy Revision وDeployment Owner.

قارن Desired State وPackage أوImage State وLive Server Response. وجود Image جديدة في Registry لا يثبت Restart للـPod. وتحديث Package Database لا يثبت خروج PID القديمة. واستعلام SELECT version() واحد لا يثبت تغير كل Replica.

احتوِ الغموض دون كسر العنقود

تحجب النشرة تفاصيل Trigger، لذلك قلل Reachability دون الاعتماد على Payload متخيلة.

1. أزل Direct Internet Exposure من ClickHouse Listeners.
2. اسمح فقط بهويات Application وAdministration وInter-node المعروفة.
3. اطلب TLS في المسارات التي تعبر شبكات خارجية وتحقق من Client Identity حيث يتوفر ذلك.
4. امنع Listener Ports غير المستخدمة في Network Policy وSecurity Group وHost Firewall.
5. قلل Administrative Users ودوّر Credentials المكشوفة عند وجود دليل اختراق.
6. احفظ Logs وHost Telemetry قبل استبدال Nodes إذا كانت المراجعة الجنائية مطلوبة.

لا تعطل Native Protocol أوInter-server Traffic عشوائيًا على Cluster حي؛ قد توقف Replication أوDistributed Queries أوRecovery. طبّق Allowlist مراجعة تحافظ على Peers المطلوبة. العزل الشبكي يشتري وقتًا لكنه ليس إصلاحًا كاملًا لثغرة Server قبل المصادقة؛ التحديث إلزامي.

اختر Target مدعومًا لاVersion أعلى فقط

اربط Current Line بأقرب Fixed Build مدعومة. في 26.3 و26.8 LTS، ابق على خط LTS المقابل ما لم تكن Migration مخططة ومختبرة. وفي 26.9 أو26.10 stable، استخدم Build المصححة أوإصدارًا أحدث مدعومًا يتضمن الإصلاح.

إذا كان الأسطول على فرع غير مدعوم، انتقل إلى LTS أوstable مدعوم عبر مسار مختبر. لا تفترض أن 26.7 آمنة لأن رقمها أعلى من 26.3؛ الدعم الأمني يتبع Release Policy لاالترتيب العددي وحده.

قبل Deployment:

• نزّل من Official Repository أوControlled Mirror؛
• تحقق من Repository Metadata وPackage Signatures؛
• تحقق من ملف SHA-512 المجاور عند استخدام TGZ؛
• ثبّت Package Build أوContainer Digest دقيقة؛
• التقط Config وMetadata Backups وأدلة Rollback؛
• تأكد أن Rollback Target مصححة أيضًا؛
• اختبر Restore وFailover وفق Topology الحقيقية.

انشر Replica بعد أخرى

تحديث ClickHouse تغيير Distributed Systems. حافظ على Replicas سليمة كافية للقراءة والإدخال والدمج والنسخ أثناء استبدال Node.

قبل كل Node:

SELECT database, table, is_leader, queue_size, absolute_delay
FROM system.replicas
ORDER BY absolute_delay DESC, queue_size DESC;

SELECT database, table, mutation_id, command, is_done, latest_fail_reason
FROM system.mutations
WHERE NOT is_done;

استخدمها كنقاط بداية لاHealth Criteria عامة. راع Mutations طويلة متوقعة وAsynchronous Replication وMaintenance Operations الخاصة بالـTopology.

التسلسل المقترح:

1. أوقف أوقيد Maintenance Jobs التي قد تخفي الإشارات؛
2. اسحب Application Traffic من Replica واحدة حيث تسمح Topology؛
3. احفظ Diagnostics وConfiguration Evidence المطلوبة؛
4. ثبّت أوشغّل Fixed Immutable Artifact؛
5. أثبت Version وStart Time للعملية الجديدة؛
6. تحقق من Replica Queue وDelay وMerges وMutations وError Logs؛
7. شغّل Reads وInserts وDistributed Queries ممثلة؛
8. أعد Replica إلى الخدمة؛
9. راقب Stability Window محددة قبل الانتقال إلى التالية؛
10. كرر عبر كل Shard وReplica وStandby وRecovery Environment.

Keeper مكوّن منفصل، ولا ينبغي اعتباره مصححًا لمجرد تحديث ClickHouse Server. اجرده وحافظ عليه وفق Version وSupport Policy الخاصة به، لكن لا تدعِ أن CVE-2026-116366 تصيبه ما لم تنشر ClickHouse هذه الحقيقة.

تحقق من الإصلاح في ثلاث طبقات

### 1. Artifact proof

سجل Package Release أوContainer Digest الدقيقة وRepository Origin ونتيجة Checksum أوSignature. Mutable Tags مثل latest أوstable ليست دليل Audit.

### 2. Process proof

استعلم version() من كل Server حي وسجل Service Start Time. أكد عدم بقاء Process أوPod على Build قبل الإصلاح تستقبل Traffic. افحص Maintenance Hosts وAutoscaling Templates وDisaster-recovery Images أيضًا.

### 3. Behavior proof

شغّل Workflows طبيعية وآمنة عبر كل Interface مدعومة:

• Authenticated Read وInsert Paths؛
• Distributed Queries بين Shards؛
• Replication Catch-up وFailover؛
• Schema Changes التي تستخدمها Deployment Pipelines؛
• Backup وRestore Smoke Tests؛
• Monitoring وLogs وMaterialized Views وDictionaries؛
• Client-driver Connection وTLS وTimeout Behavior.

لا تختبر بإرسال Exploit عامة أومتخيلة إلى Production. عدم حدوث Crash لا يثبت الكثير، بينما قد تضر Malformed Request بخدمة مشتركة.

راجع الدليل دون تسمية كل Anomaly اختراقًا

بسبب محدودية تفاصيل Trigger العامة، ابدأ بأدلة Host وService الواسعة:

• ClickHouse Crashes أوCore Dumps أوRestarts غير متوقعة قبل التحديث؛
• Child Processes أوExecutable Mappings لا يفسرها Deployment؛
• Outbound Connections من Server إلى وجهات غريبة؛
• تغييرات في Binaries أوLibraries أوConfiguration Files أوService Units؛
• Users أوSSH Keys أوCron Jobs أوsystemd Units أوContainer Changes جديدة؛
• Requests من شبكات غير موثوقة تصل ClickHouse Listeners؛
• Authentication Failures تتبعها Server Faults أوRecovery غير مفسر؛
• فجوات Query Logs لا تتوافق مع Load أوRetention؛
• Cloud Audit Events تغير Security Groups أوImages أوIdentities؛
• Persistence أوCredential Use بعد إعادة بناء Host.

قد لا تسجل ClickHouse Logs مسار Memory Corruption قبل المصادقة. اربط Load Balancer وFirewall وEndpoint وKernel وContainer Runtime وCloud Control Plane. Scan أوCrash مجرد Investigation Lead؛ أما Unauthorized Execution أوPersistence أوData Access فتحتاج دليلًا أقوى.

إذا دل الدليل على Code Execution، اعزل Node واحفظ Forensic Material وفق السياسة، ودوّر Credentials التي أمكن الوصول إليها من Host، وأعد البناء من Fixed Artifact موثوقة، وراجع الأنظمة المجاورة وصعّد Incident Response. لا تعلن حل الحادث لأن Version تغيرت فقط.

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

• أبق ClickHouse خارج Public Networks وصرح للعملاء بوضوح.
• تتبع Live Versions لكل Shard وReplica، لاDeployment Manifests فقط.
• اتبع LTS أوstable المدعومة واشترك في Security Notifications.
• ثبّت Immutable Images أوExact Package Builds.
• تحقق من Repository Metadata وSHA-512 للـDirect Archives.
• احتفظ بـFixed Rollback Artifact مختبرة.
• حدّث Failure Domain واحدة في كل مرة وراقب Replication State.
• احتفظ بـHost وNetwork وControl-plane Telemetry مدة كافية للتحقيق.
• افصل اكتمال Patch عن Compromise Assessment.
• أعد فحص Vendor Advisory مع تطور التفاصيل.

Anti-patterns والقيود

• تخمين أن المنفذ 9000 وحده أوHTTP وحدها متأثرة.
• كشف Fixed Node بينما تبقى Replicas ضعيفة قابلة للوصول.
• Rollback إلى Image غير مدعومة أوضعيفة بعد Application Regression.
• اعتبار حالة ClickHouse Cloud المصححة دليلًا على أمان Self-managed Cluster.
• افتراض أن Version Label في CI تطابق Running Server.
• تشغيل Exploit Code ضد Production Database.
• تسمية Suspicious Request اختراقًا مؤكدًا.
• اعتبار Clean Log Search دليلًا على عدم وقوع استغلال.
• دمج Security Update عاجلة مع Major Architecture Migration غير مختبرة.

لا تكشف Public Disclosure تفاصيل كافية لبناء Path-specific Detection Signature. لذلك Network Containment وSupported Fixed Build وLive Process Proof وحفظ الأدلة أكثر موثوقية من Speculative Filtering.

Checklist تنفيذية

1. اجرد كل ClickHouse Server Process وNetwork Listener.
2. اربط كل Node بـSupported Fixed Release Line.
3. قلل الوصول إلى Clients وPeers المطلوبة فقط.
4. تحقق من Official Packages وChecksums وImmutable Image Digests.
5. احفظ الأدلة المطلوبة لمراجعة الحادث.
6. حدّث Replica أوFailure Domain واحدة في كل مرة.
7. أثبت Version واستبدال Process على كل Node.
8. تحقق من Replication وQueries وInserts وBackups وClient Connectivity.
9. راجع Host وNetwork وControl-plane Evidence للأثر غير المصرح.
10. احتفظ بـFixed Rollback Target فقط وراقب Vendor Updates.

اقرأ أيضًا: نشر تحديث Apache Traffic Server الأمني، ودليل استجابة Docker Desktop للأسرار، ودليل تحديث GitLab الحرج، ومركز Cloud وDevOps وKubernetes، وخدمات هندسة Backend وAPI.

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

• ClickHouse — Security changelog
• ClickHouse — الحزم الرسمية والإصدارات المصححة
• ClickHouse — الاستجابة للثغرات والفروع المدعومة
• CVE Program — CVE-2026-116366
• Wikimedia Commons — SPNN file server rack
• Creative Commons — Attribution 4.0 International

إعداد: Noor Yasser

إعداد: Noor Yasser