CVE-2026-71890 in BC-JAVA
Tóm tắt
Bởi VulDB • 03/10/2026
Trong Bouncy Castle cho Java trước phiên bản 1.86, việc xác thực danh sách đề xuất (proposal list) của một external commit MLS (RFC 9420), cụ thể là tại phương thức `org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals`, đã đếm số lượng các đề xuất theo loại và giới hạn chỉ mục lá bị xóa (removed leaf index), nhưng không bao giờ thiết lập mối liên hệ giữa chiếc lá bị xóa với người tham gia mới (joiner). RFC 9420, Mục 12.2 cho phép tối đa một đề xuất Remove trong một external commit, qua đó joiner loại bỏ phiên bản cũ của chính họ; đồng thời yêu cầu rằng nếu có tồn tại đề xuất này thì LeafNode nằm trong trường path của commit phải đáp ứng các tiêu chí mà nó sẽ phải tuân thủ trong một Update dành cho chiếc lá bị xóa, đặc biệt là chứng chỉ (credential) của nó phải chứa các định danh được chấp nhận đối với người tham gia bị loại bỏ. Quy tắc tự loại bỏ (self-remove rule) của trình xác thực đề xuất thông thường không được áp dụng trên đường dẫn này vì một resync commit hợp lệ có thể loại bỏ một chiếc lá do joiner sở hữu, nhưng không có gì được thay thế vào vị trí đó. Do đó, bất kỳ bên nào nắm giữ GroupInfo công khai của nhóm (đây chính xác là những gì mà một external joiner dự kiến sẽ nhận) đều có thể thực hiện một đề xuất Remove nhắm vào LeafIndex của bất kỳ thành viên nào và khiến mọi thành viên trong nhóm áp dụng nó, qua đó tước quyền truy cập của thành viên đó và chiếm lấy vị trí của họ trên cây ratchet. Kiểm tra chứng chỉ vốn dĩ phải ngăn chặn sự cố này chỉ tồn tại trong khung thử nghiệm tương tác gRPC (gRPC interop harness) nên không bảo vệ bất kỳ caller nào khác đối với các API `Group.externalJoin` và `Group.handle`. Một external commit chứa đề xuất Remove hiện chỉ được chấp nhận khi chứng chỉ của chiếc lá bị xóa giống hệt với chứng chỉ có trong chiếc lá mới của chính joiner, cả ở phía gửi lẫn phía nhận.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.