قد تبدو عملية تحسين صورة داخل تطبيق ويب مهمة جانبية لا تستحق الكثير من القلق. وقد يبدو اختيار نظام تشغيل الخادم قرارًا تشغيليًا منفصلًا تمامًا عن أمن التطبيق.
لكن في تحديث أمني واحد لـ Next.js، اجتمع المساران في نقطتين مختلفتين تقودان إلى النتيجة نفسها: تنفيذ أوامر عن بُعد دون مصادقة.
في 25 أغسطس 2026 أصدرت Vercel تحديثات أمنية لمعالجة ثغرتين حرجتين في Next.js. الأولى مرتبطة بمعالجة صور AVIF وتعتمد على خلل عميق داخل مكتبة libheif، بينما الثانية تستهدف تطبيقات مستضافة على أنظمة ملفات Windows عبر مشكلة Path Traversal.
المشكلة هنا ليست مجرد وجود ثغرتين جديدتين في إطار عمل واسع الانتشار. الأهم هو أن كل واحدة منهما توضّح كيف يمكن لطبقة تبدو بعيدة عن منطق الأعمال، مثل مكتبة معالجة صور أو اختلاف سلوك مسارات الملفات بين أنظمة التشغيل، أن تتحول إلى نقطة دخول مباشرة إلى الخادم.
#ما الذي حدث؟
أصدرت Vercel نسختين مصححتين من Next.js:
Next.js 15.5.24
Next.js 16.3.3
وتعالج هذه الإصدارات ثغرتين حرجتين تسمحان في ظروف محددة بالوصول إلى Remote Code Execution - RCE دون الحاجة إلى حساب مستخدم أو جلسة مصادقة مسبقة.
| الثغرة | النوع | الشدة | البيئة المتأثرة | النتيجة المحتملة |
|---|---|---|---|---|
CVE-2026-75604 | Windows Path Traversal | CVSS 9.0 | خوادم Windows بتكوينات محددة | Unauthenticated RCE |
GHSA-2xp9-vwfh-vxw4 | AVIF / Heap Buffer Overflow | CVSS v4 9.5 | التطبيقات التي تفعل AVIF Optimization | Unauthenticated RCE |
تؤثر ثغرة Windows على الإصدارات:
Next.js >= 13.4 and < 15.5.24
Next.js >= 16.0 and < 16.3.3
أما ثغرة AVIF فتغطي نطاقًا أقدم بكثير:
Next.js >= 10.0.0 and < 15.5.24
Next.js 16.x < 16.3.3
#الثغرة الأولى: عندما يصبح Windows جزءًا من سطح الهجوم
الثغرة المسجلة بالمعرف:
CVE-2026-75604
حصلت على تقييم:
CVSS 9.0
وتؤثر على تطبيقات Next.js التي تعمل على خادم يستخدم نظام ملفات Windows، مع استخدام كل من:
Pages Router
App Router
وبدون:
Cache Components
وفق الإفصاح الأمني، يمكن لهذا المزيج أن يؤدي إلى Remote Code Execution دون مصادقة.
اللافت أن نفس التطبيق عند تشغيله على:
Linux
macOS
لا يتأثر بهذه الثغرة تحديدًا.
وهنا تظهر نقطة أمنية مهمة جدًا: قابلية الاستغلال ليست دائمًا خاصية في الكود وحده.
أحيانًا يكون الكود نفسه موجودًا في جميع البيئات، لكن الاختلاف في طريقة تعامل نظام التشغيل مع المسارات والفواصل وأسماء الملفات يجعل السلوك الأمني مختلفًا جذريًا.
في Windows، معالجة المسارات تعتمد على خصائص قد تختلف عن أنظمة Unix-like، مثل:
\
/
Drive Letters
Path Normalization
UNC Paths
وعندما لا يتم تطبيع المسار والتحقق منه بالشكل الصحيح، يمكن أن تتحول مشكلة Path Traversal من مجرد قراءة ملف غير مصرح به إلى تأثير أعمق يصل في بعض السيناريوهات إلى تنفيذ كود.
Vercel لم تنشر تفاصيل آلية الاستغلال الكاملة، وهو أمر مفهوم في ثغرة بهذه الحساسية، لكنها أكدت عدم وجود حل التفافي معروف للتطبيقات المتأثرة المستضافة على Windows.
أي أن المعالجة الأساسية هنا ليست تغيير إعداد صغير، بل الانتقال إلى نسخة مصححة.
#لماذا Path Traversal أخطر مما يبدو؟
غالبًا ما ترتبط ثغرات:
Path Traversal
بمحاولة الوصول إلى ملفات خارج المسار المسموح، مثل انتقال المهاجم من دليل التطبيق إلى ملفات أخرى في النظام.
الفكرة التقليدية تبدو كالتالي:
../../../../
لكن التأثير الفعلي يعتمد على المكان الذي يصل إليه المسار، وما الذي يفعله التطبيق بالملف الناتج، وما إذا كانت هناك طبقات أخرى تتعامل معه لاحقًا.
إذا دخل المسار إلى منطق يقوم بتحميل ملفات أو تنفيذ وحدات أو بناء موارد ديناميكية، فقد تتحول الثغرة من:
Arbitrary File Access
إلى:
Remote Code Execution
وهذا يفسر سبب تقييم ثغرة Windows بدرجة حرجة.
الثغرة الثانية: ملف AVIF واحد قد يصل إلى الذاكرة
الثغرة الثانية أكثر إثارة من الناحية التقنية، لأنها لا تبدأ داخل منطق التوجيه أو المصادقة في Next.js.
بل تبدأ من صورة.
يعتمد Next.js في تحسين الصور على مكتبة:
sharp
بينما تعتمد sharp بدورها على مكتبة:
libheif
لمعالجة صيغ مثل:
AVIF
HEIF
HEIC
الخلل الحقيقي موجود في libheif، وتم توثيقه تحت:
GHSA-g89c-p67h-r497
أما تأثر Next.js فتم توثيقه تحت:
GHSA-2xp9-vwfh-vxw4
والتقييم الأمني:
CVSS v4 9.5
#من صورة إلى Heap Buffer Overflow
عند استقبال صورة AVIF، لا يقوم Next.js بفهم بنية الصورة بالكامل بنفسه.
المسار التقريبي يكون:
Attacker-controlled AVIF
|
v
Next.js Image Optimization
|
v
sharp
|
v
libheif
|
v
Image decoding / scaling
المشكلة تظهر داخل عملية معالجة الصورة.
يمكن لملف AVIF مصمم بطريقة خاصة أن يحتوي على مراجع متداخلة من نوع:
identity-derivation (iden)
auxiliary item references (auxl)
هذا يؤدي إلى بناء صورة مفكوكة تحتوي على قناتين Alpha بعمقي بت مختلفين.
إحداهما:
8-bit Alpha
والثانية:
16-bit Alpha
المكتبة تقوم بحجز مساحة ذاكرة بناءً على القناة ذات حجم 8-bit، لكنها لاحقًا تكتب بيانات 16-bit في نفس المساحة.
والنتيجة:
Heap Buffer Overflow
أي أن الكتابة تتجاوز الحدود التي تم حجزها في الذاكرة.
وفق تفاصيل الإفصاح، يمكن أن يصل التجاوز إلى نحو:
16,384 bytes
خارج حدود التخصيص.
وهنا تتحول المشكلة من خطأ في معالجة صورة إلى Memory Corruption يمكن، عند السيطرة على ظروف الذاكرة بصورة كافية، أن يصبح أساسًا لتنفيذ أوامر عن بُعد.
#لماذا Memory Corruption بهذه الخطورة؟
عندما يحصل التطبيق على ذاكرة من الـHeap، يفترض أن يكتب داخل مساحة محددة فقط.
يمكن تبسيط الصورة كالتالي:
Allocated Buffer
+-------------------------+
| Valid Memory |
| Valid Memory |
| Valid Memory |
+-------------------------+
لكن في حالة Heap Buffer Overflow تصبح الكتابة:
Allocated Buffer
+-------------------------+
| Valid Memory |
| Valid Memory |
| Valid Memory |
+-------------------------+
| OVERWRITE |
| OVERWRITE |
| OVERWRITE |
+-------------------------+
أي أن بيانات يسيطر عليها المهاجم قد تبدأ بالكتابة في مواقع ذاكرة لم يكن من المفترض الوصول إليها.
هذه المنطقة المجاورة قد تحتوي على هياكل بيانات أو مؤشرات أو كائنات أخرى يعتمد عليها البرنامج.
لذلك فإن:
Out-of-Bounds Write
لا يُعامل عادة كعطل عادي في التطبيق.
إنه Primitive خطير قد يُستخدم لبناء سلسلة استغلال تؤدي إلى:
Process Crash
Memory Corruption
Arbitrary Code Execution
Remote Code Execution
بحسب طبيعة البرنامج وآليات الحماية الموجودة حوله.
#هل كل تطبيق Next.js معرض لثغرة AVIF؟
لا.
وهذه نقطة مهمة جدًا عند تقييم الخطر.
تحسين AVIF في Next.js لا يكون مفعلاً بالضرورة في كل تطبيق، وإنما يتطلب وجود الصيغة ضمن إعدادات الصور في:
next.config.js
على سبيل المثال:
const nextConfig = {
images: {
formats: ['image/avif', 'image/webp'],
},
}
module.exports = nextConfig
إذا لم يكن:
image/avif
مفعلاً ضمن إعدادات formats، فإن التطبيق لا يكون معرضًا لمسار الاستغلال الخاص بهذه الثغرة وفق الإفصاح المنشور.
وهذا يغيّر تقييم التعرض بشكل كبير.
فالسؤال الصحيح ليس فقط:
هل نستخدم Next.js؟
بل:
هل نستخدم نسخة متأثرة؟ وهل لدينا مسار Image Optimization يستقبل AVIF؟ وهل يمكن للمهاجم التحكم بالصورة التي تصل إلى هذا المسار؟
سلسلة الاعتماديات هي جزء من سطح الهجوم
هذه الثغرة مثال واضح على مخاطر:
Software Supply Chain
Transitive Dependencies
قد يراجع الفريق تطبيقه ويجد أنه لا يستدعي libheif بشكل مباشر.
لكن العلاقة الفعلية قد تكون:
Application
|
v
Next.js
|
v
sharp
|
v
libheif
الثغرة في الطبقة الرابعة، لكن الأثر يصل إلى الطبقة الأولى.
وهذا يعني أن تقييم أمان التطبيق اعتمادًا على المكتبات التي يضيفها المطور يدويًا فقط لم يعد كافيًا.
ينبغي النظر إلى كامل:
Dependency Graph
بما في ذلك الاعتماديات غير المباشرة.
لماذا عطلت Next.js دعم AVIF مؤقتًا؟
في النسخ المصححة، اتخذت Next.js خطوة دفاعية مباشرة: تعطيل تحسين AVIF مؤقتًا إلى أن ينتشر الإصلاح من libheif إلى سلسلة الاعتماديات المستخدمة فعليًا داخل الإطار.
الفكرة هنا مهمة من منظور هندسة الأمن.
عندما تكون الثغرة موجودة في اعتماد upstream، قد يكون أمام المشروع الأعلى في السلسلة خياران:
Wait for upstream dependency
أو:
Disable the vulnerable functionality
Vercel اختارت تعطيل الوظيفة المتأثرة مؤقتًا لمنع وصول مدخلات AVIF إلى المسار المعرض للخطر.
ما النسخ الآمنة؟
الإصدارات المصححة هي:
15.5.24
16.3.3
للترقية على خط 15.5:
npm install next@15.5.24
وللترقية على خط 16.3:
npm install next@16.3.3
ثم يمكن التحقق من النسخة المثبتة عبر:
npm list next
أو:
npx next --version
ويجب عدم افتراض أن تحديثات يوليو 2026 كافية، لأن هذه الثغرات جاءت ضمن إصدار أمني لاحق في أغسطس.
كيف تعرف إن كنت ضمن نطاق الخطر؟
يمكن تقسيم التقييم إلى مسارين.
#المسار الأول: Windows RCE
تحقق من نظام تشغيل الخادم:
Windows
ثم تحقق من إصدار Next.js:
npm list next
ثم راجع البنية المستخدمة داخل التطبيق لمعرفة ما إذا كان التطبيق يستخدم:
Pages Router
App Router
مع عدم استخدام:
Cache Components
إذا اجتمعت هذه الشروط مع نسخة متأثرة، فالتعرض مرتفع.
#المسار الثاني: AVIF RCE
ابدأ من ملف:
next.config.js
وابحث عن:
formats: ['image/avif']
أو أي صياغة مكافئة تتضمن:
image/avif
ثم راجع إصدار Next.js.
بعد ذلك اسأل السؤال الأهم:
هل يستطيع مصدر غير موثوق التحكم في الصورة التي تصل إلى Image Optimization؟
إذا كانت الإجابة نعم، فإن سطح الهجوم يصبح أكثر وضوحًا.
لماذا التطبيقات المستضافة على Vercel في وضع مختلف؟
بحسب Vercel، التطبيقات المستضافة مباشرة على منصتها محمية من الثغرتين ولا تحتاج إلى الترقية من أجل هاتين الثغرتين تحديدًا.
لكن هذه النقطة لا يجب تعميمها على:
Self-hosted Next.js
Docker
Windows Server
Kubernetes
VM deployments
On-premises hosting
فالاستضافة الذاتية تعني أن مسؤولية تحديث الإطار وسلسلة الاعتماديات والـRuntime والـOS تقع على الجهة المشغلة.
وهذا فرق جوهري من منظور:
Shared Responsibility Model
من منظور GRC: المسألة أكبر من تحديث npm
من ناحية تقنية، قد يبدو الحل واضحًا: تحديث Next.js.
لكن من منظور الحوكمة والمخاطر والالتزام، هذه الحادثة تكشف عدة أسئلة أكبر.
| المحور | السؤال الذي يجب أن تستطيع الجهة الإجابة عنه |
|---|---|
| Asset Management | أين توجد تطبيقات Next.js داخل البيئة؟ |
| Software Inventory | ما الإصدارات المستخدمة في كل تطبيق؟ |
| Dependency Management | ما الاعتماديات المباشرة وغير المباشرة؟ |
| Vulnerability Management | كم يستغرق الانتقال من الإفصاح إلى التصحيح؟ |
| Configuration Management | هل AVIF مفعّل؟ وعلى أي الأنظمة تعمل التطبيقات؟ |
| Third-Party Risk | ما أثر ثغرة في مكتبة مثل libheif على الخدمة؟ |
| Change Management | هل يمكن نشر تحديث أمني عاجل دون انتظار دورة إصدار طويلة؟ |
| Detection & Response | هل توجد رؤية كافية لاكتشاف استغلال محتمل؟ |
هذه الأسئلة تحدد ما إذا كانت المؤسسة تعرف فعلًا حجم تعرضها، أم أنها تكتشف وجود التقنية المتأثرة فقط بعد نشر الثغرة.
المشكلة التي تكشفها الثغرتان: Context هو الذي يحدد الخطر
في إدارة الثغرات، الاعتماد على درجة:
CVSS
وحدها لا يكفي.
خذ ثغرة AVIF كمثال.
قد تكون درجتها:
9.5
لكن تطبيقًا لا يستخدم AVIF Optimization قد لا يكون معرضًا لها.
وفي المقابل، تطبيق آخر يستقبل صورًا من مستخدمين خارجيين ويمررها مباشرة إلى Image Optimization قد يملك Exposure مرتفعًا جدًا.
لذلك فإن التقييم الفعلي يجب أن يجمع بين:
CVSS
+
Asset Criticality
+
Internet Exposure
+
Configuration
+
Reachability
+
Data Sensitivity
+
Exploitability
وهذه هي النقطة التي يلتقي عندها العمل التقني مع إدارة المخاطر.
ماذا تكشف هذه الحادثة عن إدارة الاعتماديات؟
هناك فرق بين معرفة أن التطبيق يستخدم:
Next.js
ومعرفة سلسلة المكونات التي يعتمد عليها Next.js فعليًا.
في المؤسسات الكبيرة، يمكن أن يكون وجود:
SBOM
أو:
Software Bill of Materials
عاملًا حاسمًا في تقليل زمن التقييم.
بدل البحث اليدوي داخل عشرات المستودعات لمعرفة ما إذا كانت libheif مستخدمة، يمكن ربط الثغرة بمكونات سلسلة التوريد البرمجية ثم تحديد التطبيقات المتأثرة.
وتصبح الأسئلة مثل:
Where is libheif used?
Which apps depend on sharp?
Which Next.js versions are deployed?
Which assets are internet-facing?
قابلة للإجابة بسرعة أكبر.
من المسؤول: فريق التطوير أم البنية التحتية أم الأمن؟
الثغرتان توضحان أن الإجابة ليست فريقًا واحدًا.
فريق التطوير مسؤول عن:
Framework Versions
Application Configuration
Dependency Updates
فريق البنية التحتية مسؤول عن:
Operating System
Hosting Model
Runtime
Deployment Environment
فريق الأمن مسؤول عن:
Exposure Assessment
Vulnerability Prioritization
Threat Monitoring
Incident Readiness
أما فرق GRC فتحتاج إلى التأكد من أن هذه المسؤوليات ليست ضمنية فقط، بل موثقة ومقاسة ويمكن إثبات تنفيذها.
لأن ثغرة Windows هنا لا يمكن فهمها من خلال الكود وحده، وثغرة AVIF لا يمكن تقييمها من خلال اسم الإطار وحده.
ماذا عن الاستغلال الفعلي؟
حتى 27 أغسطس 2026، لم يتم الإبلاغ علنًا عن استغلال فعلي للثغرتين ضمن هجمات واسعة وفق المعلومات المنشورة.
لكن الباحثين المرتبطين بثغرة libheif ذكروا أنهم تمكنوا من الوصول إلى RCE على عدة تطبيقات.
كما نُشر Proof of Concept يثبت حدوث الكتابة خارج حدود الذاكرة تحت بيئة اختبار مزودة بـ:
AddressSanitizer
ومع ذلك، فإن إثبات:
Heap Corruption
ليس بالضرورة مساويًا تلقائيًا لإثبات استغلال موثوق كامل في كل بيئة إنتاجية.
وهذا التفريق مهم عند قراءة التقارير الأمنية.
سباق جديد بين اكتشاف الثغرات وسرعة التصحيح
أطلقت Vercel في يوليو 2026 برنامجًا أمنيًا شهريًا لإصدارات Next.js، وفي أغسطس كان من المفترض إصدار الدفعة الأمنية في 26 أغسطس.
لكن وجود ثغرة حرجة إضافية في اعتماد upstream دفع الشركة إلى تقديم الإصدار إلى 25 أغسطس.
هذه ليست مجرد ملاحظة زمنية.
إنها تعكس واقعًا جديدًا في أمن البرمجيات: سرعة اكتشاف الثغرات تزداد، وسلسلة الاعتماديات تصبح أعمق، والأدوات المدعومة بالذكاء الاصطناعي بدأت ترفع حجم البحث الأمني واكتشاف الحالات الطرفية.
في المقابل، دورة التصحيح داخل المؤسسة ما زالت في كثير من الأحيان تعتمد على عمليات صُممت لعالم أبطأ.
الخلاصة
ثغرتا أغسطس في Next.js تبدوان مختلفتين تمامًا.
واحدة تبدأ من:
Windows Path Handling
والأخرى تبدأ من:
AVIF Image Parsing
لكن النتيجة المحتملة واحدة:
Unauthenticated Remote Code Execution
وهنا تكمن أهمية الحادثة.
أمن تطبيقات الويب لم يعد محصورًا في حماية صفحة تسجيل الدخول أو فحص مدخلات API فقط. نظام التشغيل، مكتبة الصور، الاعتماديات غير المباشرة، إعدادات الـFramework، وطريقة الاستضافة أصبحت كلها أجزاء مترابطة من سطح الهجوم نفسه.
قد يكون التطبيق آمنًا على مستوى الكود الذي كتبته أنت، لكنه ما زال يحمل المخاطر الموجودة في كل طبقة تحته.
وفي عالم الأطر الحديثة، أحيانًا لا يحتاج المهاجم إلى تجاوز تسجيل الدخول.
قد يحتاج فقط إلى مسار ملف غير متوقع... أو صورة مصممة بعناية.
