CVE-2026-63182 in LightSAML
Tóm tắt
Bởi VulDB • 30/10/2026
LightSAML triển khai các lớp mô hình dữ liệu SAML 2.0, quá trình tuần tự hóa và giải mã hóa XML, bảo mật XML, hỗ trợ chứng chỉ và các liên kết thông báo (message bindings). Trước phiên bản 4.7.1 và 5.0.1, LightSAML và xmlseclibs không thống nhất về việc xác định assertion nào được bao phủ bởi chữ ký SAML đầu vào. `Response::deserialize` sử dụng hàm `manyElementsFromXml` để chỉ thu thập các phần tử con trực tiếp `saml:Assertion` của `samlp:Response`, trong khi `AssertionSignatureValidatorAction` xác thực `ds:Signature` của chúng bằng cách sử dụng thông tin định danh IdP đáng tin cậy được giải quyết qua kênh ngoài (out-of-band) dựa trên Issuer, thay vì một khóa từ tài liệu.
Hàm `XMLSecurityDSig::validateReference()` loại bỏ chữ ký enveloped khỏi DOM dùng chung, nhưng `processRefNode()` phân giải `Reference URI="#id"` trong toàn bộ tài liệu thông qua XPath có dạng `//*[@Id]` và lấy phần tử đầu tiên (`item(0)`), phần này không nhất thiết phải là assertion chứa các tuyên bố mà LightSAML tiêu thụ. Một kẻ tấn công đã nắm bắt được một assertion thực sự được ký, chẳng hạn như phản hồi đăng nhập trước đó, có thể đặt các byte của nó (đã loại bỏ chữ ký) sớm hơn trong `samlp:Extensions` và trình bày một assertion con trực tiếp giả mạo với cùng ID và sao chép chữ ký thật. Khi đó, quá trình xác thực sẽ bao phủ các byte thật bị ẩn đi, trong khi LightSAML hiển thị ra ngoài các phần tử `Subject/NameID`, `Conditions` và `Attributes` do kẻ tấn công kiểm soát nhưng không được ký, cho phép bỏ qua cơ chế xác thực hoặc leo thang đặc quyền ngay cả khi việc xác thực chữ ký là bắt buộc. Hành vi này đã được xác nhận trong các phiên bản 5.0.0 và 4.6.1. Vấn đề này đã được sửa chữa trong các phiên bản 4.7.1 và 5.0.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.