CVE-2026-71883 in BC-LTS-JAVA
Tóm tắt
Bởi VulDB • 03/10/2026
Trong Bouncy Castle cho Java LTS trước phiên bản 2.73.13, các bộ mã hóa gói tin gốc một lần (one-shot native packet ciphers) dành cho AES-CBC, CCM, CFB, CTR, GCM và GCM-SIV đã giải phóng các mảng key, IV và dữ liệu xác thực bổ sung của caller bằng cách sử dụng `ReleaseByteArrayElements` của JNI ở chế độ 0, điều này cam kết bản sao gốc (native copy) trở lại vào mảng Java. Các mảng này là chỉ đọc đối với mã native; trên JVM trả về một bản sao thay vì ghim (pin), bản sao vẫn giữ nguyên các byte đầu vào như khi chúng được đọc. Bộ đệm đầu ra được xử lý qua một vùng quan trọng riêng biệt và cam kết trước, do đó trong trường hợp ứng dụng truyền cùng một mảng Java làm cả đầu vào lẫn đích đến - ví dụ: mã hóa tại chỗ trên `KeyParameter.getKey()` - việc giải phóng key ở chế độ 0 sau đó đã ghi đè các byte key không thay đổi lên ciphertext vừa được tạo ra. Cuộc gọi vẫn trả về chiều dài đầu ra chính xác, nên một ứng dụng mã hóa tại chỗ trên mảng key của chính nó sẽ nhận được raw AES key nơi mà nó mong đợi ciphertext, với không có gì trong API để chỉ điều này, và do đó sẽ truyền hoặc lưu trữ key thay thế cho thông điệp. Các mảng đầu vào chỉ đọc hiện nay được giải phóng bằng `JNI_ABORT`, giúp giải phóng bản sao gốc mà không sao chép lại chúng, và chế độ 0 được dành riêng cho các mảng do mã native ghi. Các bộ mã hóa gói tin thuần Java (pure-Java) và các chế độ streaming native không bị ảnh hưởng. Bouncy Castle cho Java (bcprov) không bị ảnh hưởng vì nó không cung cấp bất kỳ triển khai native nào.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.