CVE-2026-63182 in LightSAML
الملخص
بحسب VulDB • 30/10/2026
تُنفّذ LightSAML نماذج بيانات SAML 2.0، والتسلسل/التفكيك (serialization/deserialization) لـ XML، وأمان XML، ودعم الشهادات، وروابط الرسائل. قبل الإصدارين 4.7.1 و5.0.1، كانت هناك خلافات بين LightSAML ومكتبة xmlseclibs بشأن هوية المطالبة (assertion) التي تغطيها التوقيع الرقمي القابل للاستلام في رسالة SAML. تستخدم الدالة `Response::deserialize` دالة `manyElementsFromXml` لجمع عناصر `saml:Assertion` المباشرة التابعة فقط لعنصر الجذر `samlp:Response`. ثم تقوم `AssertionSignatureValidatorAction` بالتحقق من توقيعها الرقمي (`ds:Signature`) باستخدام بيانات اعتماد IdP موثوقة يتم حلّها عبر قناة منفصلة (out-of-band) بناءً على المُصدر (Issuer)، وليس مفتاحاً موجوداً داخل المستند نفسه.
تقوم الدالة `XMLSecurityDSig::validateReference()` بإزالة التوقيع المغلف من DOM المشترك، لكن دالة `processRefNode()` تحلّ مرجع URI (`#id`) عبر نطاق كامل للمستند باستخدام تعبير XPath بصيغة `//*[@Id]` وتأخذ العنصر الأول `item(0)`، والذي قد لا يكون هو المطالبة (assertion) التي تستهلك LightSAML مطالبها. يمكن لمهاجم قام بالتقاط مطابقة موقعة أصلياً (مثل استجابة تسجيل دخول سابقة)، بإدراج بايتاتها المزالة التوقيع الرقمي منها في وقت سابق داخل عنصر `samlp:Extensions`، وتقديم مطالبة مباشرة مزيفة تابعة للعنصر الجذر تحمل نفس المعرف (`ID`) والتوقيع الأصلي المنسوخ. عندئذٍ يغطي التحقق البايتات الأصلية المخفية بينما تعرض LightSAML عناصر خاضعة لسيطرة المهاجم وغير موقعة رقمياً مثل `Subject/NameID` و`Conditions` و`Attributes`. هذا يمكّن من تجاوز المصادقة أو تصعيد الامتيازات حتى عندما يكون التحقق من التوقيع الرقمي مطلوباً. تم تأكيد السلوك في الإصدارين 5.0.0 و4.6.1. تمت معالجة هذه المشكلة في الإصدارين 4.7.1 و5.0.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.