---
title: ".NET: تحديث أمني خارج النطاق، وثغرة Brotli بتقرا ذاكرة تطبيقك"
description: "يوم 25 تشرين الأول نزّلت مايكروسوفت تحديثات أمنية خارج النطاق لـ .NET 8 و9 و10: ثغرة تجاوز مخزن بآلية Brotli بتسمح لمهاجم بلا دخول يقرا ذاكرة العملية أو يخربها. حدّث الـ runtime وأعد نشر تطبيقك."
url: https://ihsanalapsi.dev/articles/dotnet-october-2026-oob-updates
lang: ar
date: 2026-10-26
updated: 2026-10-26
tags: ["تحديثات أمنية", "أدوات المطورين"]
author: Ihsan Alapsi (إحسان العبسي)
---
# .NET: تحديث أمني خارج النطاق، وثغرة Brotli بتقرا ذاكرة تطبيقك

إذا بتشغّل تطبيقات .NET، يوم 25 تشرين الأول 2026 نزل تحديث ما كان بالجدول. مايكروسوفت نزّلت تحديثات أمنية خارج النطاق لـ .NET 8 و9 و10، ومعهن .NET 11 Release Candidate 3، وبتوصي بالتحديث بأسرع وقت. السبب: ثغرة بآلية فك ضغط Brotli بتسمح لمهاجم بلا دخول يقرا ذاكرة العملية أو يخربها، ومعها إصلاح ثانٍ لملكية ملفات tarball على لينكس، وإعادة إصدار لإصلاحين ما اكتملوا بإصدار 13 تشرين الأول.

## شو نزل يوم 25 تشرين الأول؟

المنشور الرسمي على مدونة .NET، بتاريخ 25 تشرين الأول 2026 الساعة 18:45 بالتوقيت العالمي (21:45 بتوقيت +03)، بيعلن تحديثات خارج النطاق: .NET 8.0.33 و.NET 9.0.22 و.NET 10.0.14، ومعهن .NET 11 RC3. «خارج النطاق» يعني التحديث ما استنى موعد التصحيح الشهري، وهاد لحاله بيقلك إن الفريق شايف الخطر مستعجل.

التحديث بيعالج ثغرتين جديدتين وبيعيد إصدار ثغرتين قديمتين. الجديدتان: CVE-2026-111497 بآلية Brotli، وCVE-2026-114148 بملكية ملفات tarball على لينكس. والمعاد إصدارهما: CVE-2026-70197 بفساد ذاكرة SocketAsyncEventArgs وCVE-2026-102870 بمصحح Blazor WebAssembly، لأن إصدار 13 تشرين الأول ما عالج هالثغرتين بالكامل.

## كيف ثغرة Brotli بتأثر على تطبيقك؟

CVE-2026-111497 هي ثغرة تجاوز مخزن مؤقت باستعمال .NET لآلية فك ضغط Brotli. مهاجم بلا دخول بيقدر يقرا ذاكرة العملية أو يخربها، والنتيجة ممكن تكون كشف معلومات أو منع خدمة أو رفع امتيازات. الثغرة بتأثر على كل المنصات، بس بشرط واحد: تطبيقك لازم يعالج بيانات Brotli من الأساس.

الطرق التلاتة يلي بيذكرها المنشور: فك ضغط طلبات ASP.NET Core، وفك ضغط استجابات HttpClient التلقائي، وواجهات System.IO.Compression لBrotli. النقطة المهمة إن فك ضغط الطلبات والاستجابات التلقائي مش مفعّل افتراضياً، فكتير تطبيقات ما بتتأثر من هالطريقين. بس إذا كودك بيستعمل واجهات الضغط مباشرة، أو إذا فعّلت فك الضغط بنفسك، فإنت جوّا دائرة الخطر.

وهون في درس من إصدارات الـ runtime التانية بنفس الشهر: [تحديثات أمان Node.js لتشرين الأول 2026](/articles/nodejs-october-2026-security-releases) كانت بتسكّر ثغرات بالـ runtime نفسه، مش بكودك. ثغرة بالـ runtime يعني كل تطبيق بيستعمله وراثها، حتى لو كودك نضيف.

## وشو قصة ملكية ملفات tarball على لينكس؟

CVE-2026-114148 أضيق نطاقاً، بس أخطر على يلي بيبني من المصدر. بيانات ملكية غير آمنة بملفات tarball تبع .NET بتسمح لمهاجم محلي يعدّل ملفات وياخد امتيازات أعلى. على .NET 10 و11، الثغرة بتأثر على ملفات source-build بس. أما على .NET 8 و9، فبتأثر كمان على توزيعات ASP.NET Core يلي بتنجاب من ملفات tarball، حتى لو ما بتبني .NET من المصدر.

يعني إذا بتنزّل .NET من مدير حزم نظامك، غالباً ما بتعنيك هالثغرة. أما إذا بتوزّع أو بتبني من ملفات tarball، فلازم تاخد الملفات المحدّثة وتعيد البناء.

## ليش في إصلاحات معادة من 13 تشرين الأول؟

لأن الإصلاح الأول ما كان كامل. مايكروسوفت بتقول صراحة إن إصدار 13 تشرين الأول 2026 ما عالج ثغرة فساد ذاكرة SocketAsyncEventArgs وثغرة مصحح Blazor WebAssembly بالكامل، فتحديث اليوم بيعيد إصدارهما مع الإصلاح الكامل. الأولى بكل الإصدارات الأربعة، والتانية بـ .NET 10 و11 بس.

هاد التفصيل مهم لسبب عملي: إذا حدّثت يوم 13 تشرين الأول وارتحت، فإنت لسا مش محمي من هالثغرتين. التحديث الجديد مش تكرار، هو التكملة. وهاد نفس النمط يلي شفناه مع [ثغرتين بقلب PHP](/articles/php2shell-php-rce): الإصلاح الطارئ الأول ما بيعني إن القصة خلصت.

## شو تعمل هلق؟

الخطوة الصح بتعتمد على كيف ناشر تطبيقك، والتثبيت لحاله ما بيكفي لكل الحالات.

1. إذا تطبيقك framework-dependent، ثبّت الـ runtime المحدّث لنسخة .NET تبعك، وبعدها أعد تشغيل التطبيق.
2. إذا تطبيقك self-contained، أعد البناء والنشر بالـ runtime المحدّث. تثبيت runtime جديد على السيرفر ما بيحدّث تطبيق بيحمل الـ runtime جوّاه.
3. إذا تطبيقك بحاوية، أعد البناء والنشر بصور .NET المحدّثة.
4. إذا بتبني من المصدر، خد ملفات source-build المحدّثة وأعد بناء حزمك.
5. إذا على .NET 8 أو 9 وبتستعمل ملفات tarball تبع ASP.NET Core، حدّث من ملف الـ runtime tarball المجدّد.
6. تأكد بالأمر `dotnet --list-runtimes` إن النسخة المحدّثة هي يلي مركّبة، وافحص التطبيقات self-contained والحاويات لحالهن لأنهن بيحملوا runtime خاص فيهن.

## إمتى آخر مرة حدّثت الـ runtime؟

تحديث خارج النطاق بآخر الشهر، بعد إصدار شهري ما اكتمل، هو تذكير إن الـ runtime مش طبقة بتنساها بعد التثبيت. إذا عندك تطبيقات .NET بالإنتاج، حدّث اليوم وأعد النشر حسب نوع تطبيقك، وبعدها اسأل حالك: أي runtime تاني عندك، من Node.js لـ PHP، عم يستنى إصداره الجاي؟

إذا بدك حدا يفحص هالإعدادات قبل ما يلاقيها غيرك، [مُحَصَّن بيفحص منصتك وبيسلّمك خطة إصلاح واضحة](/muhassan).

## FAQ

**هل تطبيقي متأثر إذا ما فعّلت فك الضغط؟**

تطبيقك متأثر إذا بيعالج بيانات Brotli من واحد من تلاتة طرق: فك ضغط طلبات ASP.NET Core، أو فك ضغط استجابات HttpClient التلقائي، أو واجهات System.IO.Compression. فك ضغط الطلبات والاستجابات التلقائي مش مفعّل افتراضياً، بس الاستعمال المباشر لواجهات الضغط بيضل متأثر.

**هل .NET Framework متأثر؟**

لأ. المنشور الرسمي بيقول صراحة إن .NET Framework مش متأثر. التحديث لـ .NET 8 و9 و10 و.NET 11 RC3 بس.

**أنا على .NET 11 RC2، شو أعمل؟**

حدّث لـ .NET 11 RC3. المنشور بيقول إن مستخدمي RC2 لازم يحدّثوا لـ RC3 لحتى توصلهم هالإصلاحات.

**تطبيقي self-contained، هل تثبيت runtime جديد بيكفي؟**

لأ. التطبيق self-contained بيحمل الـ runtime جوّاه، فتثبيت runtime جديد على السيرفر ما بيحدّثه. لازم تعيد البناء والنشر بالـ runtime المحدّث، ونفس الشي للحاويات: إعادة بناء وإعادة نشر.