0xmrma/cve-2026-5061تحقق قالب Consul من المكان الذي يشير إليه الارتباط الرمزي (symlink) أثناء تقييم القالب، لكن جلب التبعية اللاحق قرأ المسار الأصلي. إعادة توجيه الارتباط بين هاتين العمليتين حوّلت مرجع ملف داخل الصندوق الرملي إلى كشف ملف خارج الصندوق الرملي.
تحقّق Consul Template من نقطة ارتباط رمزية (symlink) أثناء تقييم القالب، لكن جلب الاعتماد اللاحق قرأ المسار الأصلي. إعادة توجيه الرابط بين هاتين العمليتين حوّلت مرجع ملف داخل الصندوق الرملي إلى كشف ملف خارج الصندوق الرملي.
عثرت على هذه المشكلة أثناء مراجعة HashiCorp Consul Template، ومعي سؤال أمني محدد جدًا:
إذا كان sandbox_path يتحقق من رابط رمزي أثناء تقييم القالب، فهل تبقى قراءة الملف اللاحقة مرتبطة بنفس الهدف المُتحقَّق منه؟
في هذه الحالة، كانت الإجابة: لا.
محلّل القالب file حلّ المسار وطبّق الصندوق الرملي المُعدَّل أثناء تقييم القالب. ولكن بعد ذلك الفحص، أنشأ اعتماد ملف (dependency) باستخدام المسار الخام الأصلي.
تم جلب ذلك الاعتماد لاحقًا.
إذا أعاد المهاجم توجيه الرابط الرمزي في الفجوة بين التحقق وجلب الاعتماد، يمكن لـ Consul Template قراءة ملف خارج الصندوق الرملي. وإذا تمت استعادة الرابط قبل العرض التالي، نجح تحقق الصندوق الرملي مرة أخرى، وتم عرض المحتوى الخارجي المخزَّن مؤقتًا أيضًا.
أصبحت تلك المشكلة CVE-2026-5061.
نشرة HashiCorp: HCSEC-2026-12
نشرة IBM: النشرة الأمنية CVE-2026-5061
CVE: CVE-2026-5061
تم الإصلاح في: 0.42.0
photo0
رابط رمزي داخل الصندوق الرملي يتحكم فيه المهاجم -> تحقق الصندوق الرملي يحلّه إلى هدف آمن -> يخزّن الاعتماد المسار الخام الأصلي -> المهاجم يعيد توجيه الرابط خارج الصندوق الرملي -> جلب الاعتماد يقرأ ملفًا خارجيًا -> المهاجم يستعيد الرابط الآمن -> ينجح التحقق التالي -> يُعرض المحتوى الخارجي المخزَّن مؤقتًا
Consul Template هو أداة عرض قوالب لبيانات Consul وVault.
يمكنه العمل باستمرار، ومراقبة تغييرات الاعتمادات، وعرض البيانات في ملفات أو متغيرات بيئة لتستهلكها التطبيقات.
محلّل القالب file يقرأ ملفًا محليًا ويدرج محتوياته في المخرجات المعروضة.
نظرًا لأن قراءة الملفات المحلية قد تكشف أسرارًا يمكن للعملية قراءتها، يوفر Consul Template خيار sandbox_path كحدود لهذا المحلّل.
الخاصية الأمنية الموثّقة واضحة:
file يجب أن تقع داخل الصندوق الرملي المُعدَّلهذا يجعل sandbox_path حدودًا أمنية حقيقية.
السؤال المهم لم يكن ما إذا كان المسار يبدو واقعًا تحت الصندوق الرملي.
السؤال الحقيقي كان:
هل يبقى الملف الذي تتم قراءته هو نفس الملف الذي اجتاز تحقق الصندوق الرملي؟
في الإصدارات المعرضة للثغرة، لم يكن كذلك.
غالبًا ما تفشل الصناديق الرملية لنظام الملفات عند الفجوة بين التحقق من المسار والوصول إلى الملف.
النمط الشائع هو:
هذا الافتراض غير آمن عندما يمكن للمهاجم تعديل رابط رمزي أو أي تحويل ملفات مكافئ بين العمليتين.
جعل Consul Template هذا السطح مثيرًا للاهتمام بشكل خاص لأن تقييم القالب وجلب الاعتمادات كانا مرحلتين منفصلتين.
ذلك الانفصال خلق السؤال الأمني الصحيح:
هل جلب الاعتماد مرتبط بالهدف المُتحقَّق منه، أم أنه يحلّ المسار الذي يتحكم فيه المهاجم مرة أخرى؟
كانت تلك هي الحدود التي ركزت عليها.
كان السبب الجذري عبارة عن عدم تطابق بين وقت الفحص ووقت الاستخدام (TOCTOU) بين:
template/funcs.godependency/file.goفي النسخة المختبرة، كان fileFunc() يقوم بما يلي:
normalized := strings.TrimSpace(s)
err := pathInSandbox(sandboxPath, normalized)
if err != nil {
return "", err
}
d, err := dep.NewFileQuery(s)
محلّل التحقق حلّ الروابط الرمزية بشكل صحيح قبل فحص الاحتواء:
sandboxResolved, err := filepath.EvalSymlinks(filepath.Clean(sandbox))
targetResolved, err := filepath.EvalSymlinks(filepath.Clean(path))
rel, err := filepath.Rel(sandboxResolved, targetResolved)
if rel == ".." || strings.HasPrefix(rel, ".."+string(filepath.Separator)) {
return fmt.Errorf("'%s' is outside of sandbox", path)
}
إذًا فحص الصندوق الرملي نفسه فهم الهدف المُحلَّل.
لكن ذلك الهدف المُحلَّل تم تجاهله.
NewFileQuery() خزّن السلسلة الأصلية بدلًا من ذلك:
return &FileQuery{
stopCh: make(chan struct{}, 1),
path: s,
}, nil
ثم قرأ جلب الاعتماد اللاحق ذلك المسار مرة أخرى:
data, err := os.ReadFile(d.path)
هذه هي الثغرة بالكامل.
الرمز فحص حلًا واحدًا لنظام الملفات، ثم استخدم حلًا آخر لاحقًا.
لأن الرابط الرمزي قابل للتغيير.
لا يحتاج المهاجم إلى جعل هدف خارج الصندوق الرملي يجتاز pathInSandbox() مباشرة.
يحتاج فقط إلى تغيير ما يحلّ إليه المسار الخام المعتمد مسبقًا بعد التحقق وقبل أن يقوم Fetch() بالقراءة.
التسلسل هو:
pathInSandbox()FileQuery يسجّل مسار الرابط الخامos.ReadFile(d.path) يحلّ الرابط مرة أخرىتلك الخطوة الأخيرة مهمة.
استعادة الرابط الآمن لم تُزل السر الذي تم جلبه بالفعل من ذاكرة التخزين المؤقت للاعتمادات.
التمييز المهم هو تجاوز ضابط أمني صريح.
لم يكن هذا مجرد:
"الملف تغيّر بينما كان Consul Template يراقبه"
مراقبة الملفات للتغييرات سلوك متوقع.
المشكلة الحقيقية كانت:
مسار اجتاز قيد الصندوق الرملي الموثّق يمكن استخدامه لاحقًا لقراءة ملف خارج ذلك الصندوق الرملي
هذا فشل مباشر لحدود الثقة.
كان التطبيق قد اتخذ بالفعل قرارًا أمنيًا:
لكن الجلب اللاحق لم يكن مرتبطًا بالهدف الذي برّر ذلك القرار.
هذا هو ما حوّل قابلية تغيّر نظام الملفات العادية إلى ثغرة أمنية.
بنيت أداة إعادة إنتاج مستقلة حول التسلسل الدقيق لتقييم القالب وجلب الاعتماد.
الإعداد المتحكم به استخدم:
مسار إعادة الإنتاج كان:
file بحيث ينجح تحقق الصندوق الرملي ويُسجَّل المسار الخام كاعتماد.os.ReadFile(d.path) يقرأ عبر الرابط المعاد توجيهه.السلوك المرصود كان:
تلك المقارنة بالتجزئة كانت مهمة.
أثبتت أن القيمة المعروضة النهائية لم تكن محتوى آمنًا قديمًا، أو أثر اسم ملف، أو أثرًا جانبيًا لمسار خطأ.
كانت المحتوى الحرفي (byte-exact) للملف خارج الصندوق الرملي.
أقوى إثبات لمشكلة TOCTOU يجب أن يتحكم في الخط الزمني.
مجرد إظهار أن رابطًا رمزيًا يمكن أن يشير خارج الصندوق الرملي سيكون أضعف لأن pathInSandbox() كان يرفض بالفعل هدفًا خارجيًا عندما يرصده.
الادعاء الأمني اعتمد على إثبات كل هذه الحالات بالترتيب:
لهذا فصلت أداة إعادة الإنتاج بين تحقق القالب، وجلب الاعتماد، واستعادة الرابط، ثم العرض التالي بشكل صريح.
لم يعتمد إثبات المفهوم على توقيت عشوائي أو تخمين متكرر.
قاد دورة الحياة المعرضة للثغرة بشكل حتمي.