ثغرة GitLab CVE-2026-110264: حدّث بأمان

أصدر GitLab في 21 أكتوبر 2026 تحديثًا حرجًا يعالج CVE-2026-110264، وهي ثغرة بتقييم CVSS 10.0 قد تسمح لمهاجم غير مسجل بتنفيذ كود على خادم GitLab ذاتي الإدارة عبر Integer Overflow أثناء ترجمة Regular Expression مصممة. إذا كنت تشغّل إصدار GitLab CE أوEE متأثرًا، انتقل فورًا إلى Patch مصححة في الفرع المدعوم: 18.11.13 أو19.0.10 أو19.1.9 أو19.2.9 أو19.3.6 أو19.4.3 أو19.5.1. اجرد كل عقد Web وSidekiq وGitaly وGeo، واحفظ الأدلة، وخذ Backup كاملة قابلة للاستعادة، واتبع Required Upgrade Stops، ثم تحقق من Migrations وكل Replica.

نشر GitLab قاعدتي كشف لمحاولات الاستغلال: “Onigmo native worker crash” و“Org mode render error burst”. التطابق إشارة للتحقيق وليس إثباتًا للاختراق. نطاقات الإصدارات والإصلاحات ودرجة الخطورة وأسماء أدوات الكشف حقائق من المورد؛ أما خطة التحديث وحفظ الأدلة والتحقق فهي تحليل هندسي.

القرار أولًا

يسجل GitLab كل إصدارات CE وEE من 7.0 قبل 18.11.13 كمتأثرة، إضافة إلى فترات 19.x الموضحة. ويقول المورد إن GitLab.com مصحح، وإن إصدارات داخلية محددة في GitLab Dedicated تتضمن الإصلاح. يركز هذا الدليل لذلك على Self-managed GitLab.

ماذا تغير الثغرة الحرجة؟

تقع CVE-2026-110264 في مسار ترجمة Regular Expression. تحت شروط محددة قد تسبب صيغة مصممة Integer Overflow ينتهي بتنفيذ كود اعتباطي على الخادم دون Authentication. اجتماع Network Reachability وعدم الحاجة إلى حساب وتنفيذ كود Server-side يفسر تقييم CVSS الأقصى.

لا تحول الوصف العام إلى Exploit Test على Production. يكفي دليل الإصدار والنشر لتحديد وجوب التصحيح. إرسال مدخلات مصممة قد يعطل الخدمة أويفسدها، ولا يثبت نظافة Fleet.

ويعالج الإصدار نفسه ثغرتين High ينبغي إدراجهما في سجل التغيير:

• CVE-2026-15723 قد تسمح لمستخدم مسجل بالاستيلاء على حساب مدعوم بـLDAP عندما يكون OmniAuth SAML وLDAP auto-linking مفعّلين. تتأثر الإصدارات من 10.1 قبل 19.3.6، و19.4 قبل 19.4.3، و19.5 قبل 19.5.1.
• CVE-2026-112212 قد تسمح لمهاجم غير مسجل بتسميم Shared Cache لوثيقة اكتشاف OAuth/OIDC وتحويل تدفقات محددة إلى خادم يسيطر عليه. تتأثر الإصدارات من 18.3 قبل 19.3.6، و19.4 قبل 19.4.3، و19.5 قبل 19.5.1.

تعتمد الثغرتان على الإعداد والتدفق. أما RCE فهي سبب تصحيح كل Instance ذاتية الإدارة المتأثرة، لاالمنشآت التي تستخدم SAML أوLDAP أوOIDC فقط.

المحاولة والضعف والاختراق حالات مختلفة

استخدم أربع حالات للأدلة في اتصالات الحادث:

يسمي GitLab قاعدتيه Threat Detections لمحاولات الاستغلال. قد يحدث Native-worker Crash لأسباب غير خبيثة، وقد تكون Render-error Burst ضوضاء. وفي الاتجاه الآخر لا يثبت الصمت عدم وجود محاولة إذا لم تُحتفظ Logs المطلوبة. اربط التطابق مع توقيت Requests وApplication/System Logs وProcess Ancestry، والمستخدمين أوTokens الجديدة، وDeploy Keys وWebhooks وRunner Registrations وCI/CD Variables وتغييرات Repository وOutbound Connections وAudit Events.

عند تطابق إشارة، التقط Snapshot للخدمة والسجلات وفق السياسة قبل Restart. سجّل إصدار GitLab المنفذ وPackage Revision أوImage Digest. أدر Credentials وفق نطاق التعرض الفعلي: Instance Secrets وRunner Tokens وDeploy Keys وAccess Tokens وCloud Credentials المتاحة للJobs وأسرار Integrations. لا تنفذ Rotation عشوائية قبل حفظ الأدلة إذا كان ذلك سيمحو Attribution مفيدة.

اجرد نشر GitLab كاملًا

إصدار Web UI على عقدة واحدة ليس Fleet Inventory. سجّل:

• نوع النشر Package أوSource أوHelm والإصدار الدقيق؛
• كل عقد Rails Web وSidekiq وخدمات Gitaly وPraefect، وGeo Primary/Secondary، ومديري Runners وToolbox Pods؛
• Topology لـPostgreSQL وRedis وObject Storage؛
• المصادقة الخارجية، بما فيها SAML وLDAP وOIDC؛
• Image Digests أوPackage Revisions الحالية ومالكي الصيانة والتعافي؛
• Database وBackground Migrations المعلقة؛
• موقع Backup ومفاتيح التشفير وآخر Restore Test ناجح.

في Containers وKubernetes استعلم Digests للأحمال العاملة والموقوفة. Mutable Tags ليست دليلًا. وفي Packages ثبّت إصدار GitLab الدقيق أثناء التغيير الطارئ حتى لا يختار Repository فرعًا غير مقصود.

ابنِ مسار تحديث آمنًا

1. اختر Patch المصححة في Minor المدعوم الحالي عندما تكون أقصر انتقال آمن. لا تعتبر الجدول إذنًا لتجاوز Required Upgrade Stops من إصدار قديم.
2. استخدم وثائق Upgrade Path. تشمل محطات GitLab 18 الإلزامية 18.2 و18.5 و18.8 و18.11، وتشمل GitLab 19 حاليًا 19.2 و19.5. انتظر اكتمال Background Migrations عند كل محطة.
3. صدّر الجرد الكامل واحفظ Security Logs قبل Maintenance Window.
4. أنشئ Backup كاملة واحمِ منفصلًا العناصر التي لا تضمها Application Archive عادة، مثل External Object Storage وإعدادات /etc/gitlab وTLS/SSH Keys وSystem Files وExternal Hooks.
5. أثبت Restore Runbook. يتطلب GitLab الاستعادة داخل إصدار Application نفسه الذي أنشأ Backup؛ إرجاع Database عشوائيًا إلى Binary أقدم ليس Rollback Plan آمنة.
6. أوقف CI/CD الجديدة وفعّل Maintenance Controls الموثقة. أبقِ PostgreSQL وRedis وGitaly متاحة أثناء Linux Package Upgrade.
7. طبّق Patch الدقيقة واترك Database Migrations تكتمل. يذكر GitLab أن هذا التحديث يحتوي Migrations؛ يتوقف Single-node Deployment لأن Migrations تنتهي قبل بدء GitLab. على Multi-node استخدام Zero-downtime Procedure الموثقة فقط عندما يدعمها التصميم والإصدار الحالي.
8. حدّث جميع العقد بالترتيب المدعوم، ثم Runners وAuxiliary Images التي يجب أن تتطابق مع الإصدار.
9. نفّذ Health وFunctional Checks قبل إعادة فتح Writes.

Emergency Patch ليست وقت جمع OS Migration وDatabase Major Upgrade وإعادة تصميم Architecture في تغيير واحد. افصل مخاطر التغييرات غير المرتبطة إلاإذا فرض مسار مدعوم Dependency Change.

Backup وRollback جزء من التصحيح

قد تضم Application Backup قاعدة البيانات والإعدادات وRepositories وLFS Objects وArtifacts وJob Data وUploads وWikis وSecure Files وPages وTerraform State وSnippets. لكنها لا تجعل كل External Dependency قابلة للاستعادة تلقائيًا. تحتاج External Object Storage وإعدادات /etc/gitlab والشهادات والمفاتيح وHooks وSystem-level Files تغطية صريحة.

خزّن Backup خارج Instance، وتحقق من Checksums وAccess Controls، وسجل إصدار GitLab الذي أنشأها. يجب أن يختبر Restore بدء التطبيق والمصادقة وRepository Read/Write وLFS وArtifacts وRegistry وRepresentative Pipelines. وتطلب وثائق GitLab أيضًا Installation عاملة بالإصدار نفسه الذي أنشأ Backup؛ خطط للسعة بدل اكتشاف الشرط أثناء Rollback.

تحقق من Fleet لا من Package Transaction فقط

بعد التحديث أثبت ما يلي:

• كل عقد GitLab Web وSidekiq تعرض Patch المصححة المختارة؛
• Gitaly وPraefect وGeo وToolbox متوافقة وسليمة؛
• Database وBackground Migrations مكتملة وليست مجدولة فقط؛
• Readiness Endpoints وService Dependencies سليمة؛
• Local Login وكل SSO Path مهيأة تعمل بحسابات اختبار؛
• Clone وFetch وPush وMerge Request وProtected-branch Enforcement تعمل؛
• Controlled CI Pipeline واحدة تحصل على Artifacts وCache وRegistry؛
• Webhooks وMail وPackage Registry وObject Storage تعمل؛
• لايمكن لأي Old Package أوImage Digest أوAutoscaling Template أوRollback Artifact إعادة إصدار متأثر.

استخدم Operations Telemetry محمية لتسجيل Version وDigest عبر Replicas؛ لا تنشر Public Version Endpoint تفصيلية. احتفظ بأدلة قبل وبعد التغيير مع Incident أوChange Ticket.

إذا تعذر بدء التصحيح فورًا

يوصي تنبيه GitLab بتحديث المنشآت المتأثرة بأسرع وقت، ولا يقدم Configuration-only Workaround للـRCE الحرجة. لذلك يجب أن تقلل الضوابط المؤقتة التعرض أثناء تجهيز Patch، لا أن تسمى إصلاحًا:

• أزل Public Reachability أوقيد الوصول إلى Network Boundary محكومة؛
• فعّل Maintenance Mode وأوقف Integrations أوWrites الخطرة عندما يسمح التشغيل؛
• زد Retention والتنبيه لقاعدتي GitLab ولـProcess Anomalies المترابطة؛
• امنع إنشاء Runners أوTokens خارج الإدارة المعتمدة؛
• جهز Replacement Instance موثوقة إذا أصبحت Integrity موضع شك.

لا تزيل WAF Rule أوAuthentication Requirement أوتعطيل SAML مسار Regular-expression Compiler المتأثر. أعد فتح الوصول الطبيعي فقط بعد التحقق من Fixed Fleet وحالة Migrations.

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

• عامل GitLab كـProduction Control Plane لأنه يحمل Source وCI Credentials وسلطة Deployment.
• احتفظ بجرد Version وImmutable Digest لكل عقدة.
• اختبر Restore على كل Release Train مدعومة.
• افصل بين لغة Vulnerability وAttempt وCompromise في التقارير.
• اشترك في Critical Patch Notices واعتمد Emergency Windows مسبقًا.
• احتفظ بـApplication وAudit وProcess وNetwork Telemetry تكفي للمراجعة.

Anti-patterns

• فحص UI Footer واحدة وافتراض أن كل العقد مصححة.
• قفز Major Releases دون Required Stops أوMigrations مكتملة.
• وصف Detection Hit بأنه اختراق مؤكد، أووصف الصمت بأنه أمان.
• أخذ Automatic Package Backup فقط وتجاهل Object Storage و/etc/gitlab.
• إعادة استخدام Mutable Container Tag مع بقاء Pods أوAutoscaling Templates قديمة.
• Downgrade لقاعدة البيانات بدل Restore من Backup مختبرة ومطابقة للإصدار.
• تشغيل Public Exploit Code ضد Production كخطوة «تحقق».

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

CVE-2026-110264 هي RCE من دون مصادقة في منصة تتحكم غالبًا في Source Code وBuild Secrets وDeployment Paths. صحح كل Self-managed GitLab متأثرة إلى الإصدار الثابت في فرعها المدعوم مع احترام Required Upgrade Stops وإرشادات Migrations. احفظ الأدلة وحقق في قاعدتي GitLab دون مبالغة في وصفهما. لا يكتمل التغيير حتى يتم التحقق من كل Node وMigration وAuthentication Path وRecovery Artifact.

تابع عبر محور Cloud وDevOps وKubernetes، ودليل تحديث NGINX الأمني لأكتوبر 2026، ودليل إصدار Node.js الأمني لأكتوبر 2026، ودليل تحديث Apache Tomcat لأكتوبر 2026.

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

• GitLab — Critical Patch Release 19.5.1 والفروع المصححة
• GitLab — تخطيط Upgrade Path
• GitLab — تحديث Linux package instances
• GitLab — Backup لـGitLab
• GitLab — Restore لـGitLab
• Wikimedia Commons — Code Review photo-1
• Creative Commons Attribution-ShareAlike 3.0

إعداد: Noor Yasser

إعداد: Noor Yasser