Lưu ý: Dữ liệu này chỉ có tính chất tham khảo, phục vụ nghiên cứu an ninh mạng.CyStack khuyến nghị người dùng không sử dụng các thông tin này nhằm các mục đích bất hợp pháp
Lỗ hổng CVE-2026-123158 là lỗ hổng Unexpected Status Code or Return Value ảnh hưởng tới OpenSSH (phiên bản bị ảnh hưởng: < 10.6p2). Lỗ hổng này được xếp hạng ở mức Cao, với điểm CVSS 8.1. Lỗ hổng này đã có mã hoặc bằng chứng khai thác công khai, nhưng điều đó chưa xác nhận việc khai thác trong thực tế.
sshd trong OpenSSH trước 10.6p2 trên Linux, khi sử dụng musl libc mà không có PAM, thiếu một workaround cho lỗi bỏ qua xác thực mật khẩu (liên quan đến việc diễn giải sai liệu một chuỗi có được dùng làm password hash hay không). Với một số cấu hình tài khoản, mọi mật khẩu dài từ 256 đến 1024 ký tự đều thành công. Một ví dụ về nền tảng sử dụng musl libc mà không có PAM là Alpine Linux.
10.6p2 được ghi nhận là bị ảnh hưởng.*, ít nhất một tài khoản khác có hash $5$ hoặc $6$, và PasswordAuthentication đang bật. Hệ thống dùng glibc, hệ thống không phải Linux, hoặc Linux dùng PAM cho password authentication không thuộc phạm vi được OpenSSH mô tả.3.16 đến 3.24 và edge bị ảnh hưởng trước package sửa lỗi. Các package sửa theo nhánh là edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11, 3.21 9.9_p2-r1, 3.20 9.7_p1-r6, 3.19 9.6_p1-r3, 3.18 9.3_p2-r4, 3.17 9.1_p1-r7, và 3.16 9.0_p1-r6.openssh-server-pam với UsePAM yes, hệ thống có PasswordAuthentication no, tài khoản bị khóa bằng !, hoặc hệ thống không có hash dạng $ không thỏa điều kiện ảnh hưởng được advisory nêu.Lỗi nằm trong đường xử lý xác thực mật khẩu của sshd khi OpenSSH chạy trên Linux dùng musl libc và tắt PAM. Khi không dùng PAM, sshd gọi crypt() để băm mật khẩu do người dùng gửi rồi so sánh kết quả với trường mật khẩu được lưu. Với tài khoản có trường mật khẩu quá ngắn để chứa salt, sshd có thể sử dụng salt của tài khoản khác. Trong musl, crypt() trả về chuỗi * như một dấu hiệu lỗi khi mật khẩu vượt quá giới hạn độ dài; chuỗi này cũng chính là giá trị thường dùng cho tài khoản không có mật khẩu trong /etc/shadow, nên phép so sánh có thể thành công. Điều kiện khai thác còn phụ thuộc vào cấu hình tài khoản: cần một tài khoản có trường mật khẩu *, ít nhất một tài khoản khác có hash bắt đầu bằng $5$ hoặc $6$, và xác thực mật khẩu phải được bật. Bản sửa trong đường dẫn xác thực của sshd bổ sung kiểm tra độ dài tối thiểu của chuỗi được xem là password hash, đồng thời xử lý bộ nhớ và giá trị mật khẩu an toàn hơn. OpenSSH mô tả nguyên nhân gốc nằm ngoài sshd, nhưng cung cấp workaround trong sshd để ngăn đường khai thác này.
Lỗ hổng có thể bị khai thác qua mạng khi dịch vụ SSH nhận kết nối từ kẻ tấn công và cho phép password authentication. Kẻ tấn công không cần có quyền trước hoặc tương tác của người dùng, nhưng phải biết tên một tài khoản phù hợp và máy chủ phải thỏa các điều kiện về musl, PAM, PasswordAuthentication và các trường mật khẩu. Mật khẩu gửi trong yêu cầu xác thực nằm trong khoảng độ dài gây lỗi, từ đó có thể vượt qua việc kiểm tra mật khẩu của tài khoản không có mật khẩu. Độ phức tạp khai thác được ghi nhận là cao vì các điều kiện môi trường và cấu hình tài khoản phải đồng thời phù hợp. Bản ghi đánh dấu đã có public exploit; các nguồn được cung cấp cũng bao gồm mã tái hiện và môi trường lab công khai. Tình trạng khai thác thực tế trong môi trường sản xuất không được xác lập bởi bằng chứng hiện có.
doas hoặc có đường nâng quyền khác. Đây là khả năng phụ thuộc cấu hình, không phải kết quả bắt buộc trên mọi hệ thống.Nếu điều kiện khai thác tồn tại, người ngoài có thể đăng nhập SSH mà không biết mật khẩu của tài khoản mục tiêu. Hậu quả có thể gồm truy cập trái phép vào dữ liệu, sửa đổi hệ thống, chạy lệnh dưới quyền tài khoản bị chiếm và duy trì quyền truy cập thông qua khóa SSH hoặc tài khoản mới. Trong các image hoặc máy chủ có tài khoản được phép dùng doas, quyền đăng nhập ban đầu có thể dẫn đến nâng quyền, tùy cấu hình cụ thể. Tài khoản root chỉ thuộc đường ảnh hưởng nếu chính sách PermitRootLogin cho phép đăng nhập phù hợp; một tài khoản khác có khả năng nâng quyền cũng có thể tạo ra tác động tương tự. Container không chạy sshd, hệ thống tắt password authentication và cấu hình dùng PAM cho password authentication nằm ngoài các điều kiện ảnh hưởng được mô tả.
10.6p2 hoặc triển khai package sửa lỗi đúng với nhánh Alpine đang sử dụng: edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11, 3.21 9.9_p2-r1, 3.20 9.7_p1-r6, 3.19 9.6_p1-r3, 3.18 9.3_p2-r4, 3.17 9.1_p1-r7, hoặc 3.16 9.0_p1-r6.sshd sau khi cập nhật. Chỉ nâng cấp package không thay thế tiến trình daemon đang chạy.PasswordAuthentication no, kiểm tra cấu hình rồi restart sshd. Biện pháp này là workaround được Alpine xác nhận để đóng đường khai thác.doas, user mới, file mới và khóa trong authorized_keys. Nếu không thể loại trừ một lần đăng nhập trái phép, xử lý máy như đã bị xâm nhập.sshd, xác định phiên bản OpenSSH, libc đang dùng là musl hay glibc, bản dựng có PAM hay không, và giá trị hiệu lực của UsePAM.PasswordAuthentication; các hệ thống đặt tùy chọn này thành no không thuộc điều kiện khai thác được mô tả./etc/shadow và nguồn tài khoản tương ứng để tìm tài khoản có trường mật khẩu *, đồng thời xác định liệu có tài khoản cục bộ nào có hash bắt đầu bằng $5$ hoặc $6$ hay không. Trường ! biểu thị tài khoản bị khóa và cần được phân biệt với trường *.openssh với nhánh Alpine đang triển khai, và xác nhận tiến trình sshd đã được restart sau khi cập nhật package./var/log/messages để tìm các dòng sshd có nội dung Accepted password for đối với tài khoản vốn không có mật khẩu, chẳng hạn tài khoản key-only hoặc tài khoản alpine.doas, user mới tạo, file mới xuất hiện và authorized_keys. Việc không thấy log hoặc dấu hiệu này không chứng minh hệ thống an toàn.Giải pháp CyStack VulnScan liên tục phát hiện tài sản, xác minh lỗ hổng và giúp đội ngũ bảo mật ưu tiên khắc phục cho toàn bộ doanh nghiệp.
vi
