Lỗ hổng HollowByte trong OpenSSL cho phép kẻ tấn công gửi 11 byte yêu cầu TLS để khiến máy chủ cấp phát tới 131 KB bộ nhớ cho mỗi kết nối, và bộ nhớ này không được giải phóng trên hệ thống glibc cho đến khi tiến trình khởi động lại. Okta Red Team, người phát hiện và đặt tên cho lỗ hổng, đã công bố chi tiết vào ngày 16/7/2026.

Lỗ hổng hoạt động như thế nào?

Lỗ hổng nằm ở cách OpenSSL xử lý tiêu đề tin nhắn bắt tay TLS. Mỗi tin nhắn bắt tay TLS có tiêu đề 4 byte, trong đó 3 byte khai báo độ dài phần thân. Các phiên bản OpenSSL cũ mở rộng bộ đệm nhận theo kích thước khai báo ngay khi tiêu đề đến, trước khi bất kỳ byte nào của phần thân xuất hiện và trước khi các kiểm tra bắt tay diễn ra. Đối với ClientHello đến, giới hạn là 131 KB. Sau đó, luồng worker chặn lại, chờ phần thân không bao giờ đến. Không có xác thực, không có phiên, không có trao đổi khóa.

Tác động của glibc và bộ nhớ không được giải phóng

Khi kẻ tấn công đóng kết nối, OpenSSL giải phóng bộ đệm, nhưng glibc giữ các khối nhỏ và vừa để tái sử dụng thay vì trả lại cho kernel. Cuộc tấn công thay đổi kích thước khai báo trên mỗi kết nối, đủ để ngăn bộ cấp phát tái sử dụng bộ nhớ đã giải phóng. Heap bị phân mảnh, kích thước thường trú (resident set size) tăng lên và không giảm ngay cả khi kẻ tấn công đã rời đi. Trong thử nghiệm của Okta với NGINX, một máy chủ 1 GB bị OOM-kill với 547 MB bộ nhớ bị đóng băng trong các mảnh. Trên máy chủ 16 GB, HollowByte khóa 25% bộ nhớ hệ thống mà không bao giờ vượt qua giới hạn kết nối, khiến Okta Red Team nhận định "các biện pháp giới hạn kết nối tiêu chuẩn không thể ngăn chặn nó".

OpenSSL không coi đây là lỗ hổng bảo mật

OpenSSL đã phát hành bản vá HollowByte vào tháng 6 mà không có CVE, không có cảnh báo và không có mục nhập changelog chỉ ra nó. Các bản phát hành đã vá bao gồm OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 và 3.0.21, tất cả đều ngày 9/6/2026. Mọi bản phát hành trước đó trên các nhánh này đều bị ảnh hưởng. Pull request từ Matt Caswell, người viết bản vá, nói rõ: nhóm bảo mật chọn "xử lý đây như một bản sửa lỗi hoặc tăng cường (bug or hardening) thông thường". Chính sách bảo mật của OpenSSL định nghĩa bốn mức độ nghiêm trọng, từ Critical đến Low, và "bug or hardening" không nằm trong số đó. Ngay cả vấn đề Low cũng nhận được CVE, ghi chú changelog và mục trên trang lỗ hổng. HollowByte không có cả ba. The Hacker News không tìm thấy đề cập nào về bản vá trong ghi chú phát hành hoặc trong tất cả 23 mục của changelog OpenSSL 4.0.1.

So sánh với các lỗ hổng khác

Vào tháng 1, OpenSSL đã gán CVE-2025-66199, mức Low, cho một lỗ hổng nén chứng chỉ TLS 1.3, trong đó kích thước do đối tác cung cấp làm tăng bộ đệm heap trước khi xác thực, trị giá khoảng 22 MiB mỗi kết nối. Lỗ hổng đó cần bốn điều kiện: nén chứng chỉ được biên dịch, thuật toán nén khả dụng, phần mở rộng được thương lượng và trên máy chủ, chứng chỉ máy khách được yêu cầu. HollowByte không cần điều kiện nào. Cùng bản phát hành ngày 9/6 cũng gán CVE-2026-34183, mức Moderate, cho tăng trưởng bộ nhớ không giới hạn trong trình xử lý QUIC PATH_CHALLENGE. Cả hai đều là DoS cạn kiệt bộ nhớ và đều có số CVE.

Cách khắc phục

Người dùng tự xây dựng OpenSSL nên nâng cấp lên các bản phát hành đã vá và khởi động lại bất kỳ tiến trình nào đang tải phiên bản cũ. Đối với người dùng downstream như Red Hat, nơi mặc định là backport thay vì nâng cấp phiên bản, cần kiểm tra changelog gói hoặc hỏi người bảo trì xem họ có rebase lên bản phát hành ngày 9/6 hay đã áp dụng bản vá (pull request 30792 cho master và 4.0, 30793 cho 3.6, 3.5 và 3.4, và 30794 cho 3.0).

DTLS vẫn chưa được vá

Bản vá chỉ bao gồm TLS. DTLS bị bỏ qua vì việc sửa lỗi đúng cách sẽ phức tạp hơn nhiều, và dự án quyết định không làm điều đó vào lúc này. The Hacker News so sánh mã nguồn OpenSSL tại các tag 3.6.2 và 3.6.3 và thấy tệp bắt tay DTLS giống hệt nhau qua bản vá. Trong 4.0.1, phiên bản mới nhất, đường dẫn đó vẫn định cỡ bộ đệm từ độ dài do đối tác khai báo. OpenSSL chưa phân loại đường dẫn đó hoặc cam kết sửa nó.

Theo The Hacker News

Ảnh: Christina Morillo / Pexels