Lỗ hổng OpenSSH CVE-2026-123158: vượt xác thực trên Alpine Linux

Ngày 5/11/2026, OpenSSH 10.6p2 được phát hành. OpenSSH là phần mềm mà hầu hết máy chủ Linux dùng để đăng nhập từ xa. Bản này sửa lỗi cho phép đăng nhập vào một số hệ thống Linux mà không cần biết mật khẩu (CVE-2026-123158). Ngày 9/11, cơ quan CISA của Mỹ đã đưa lỗi này vào danh sách lỗ hổng đã bị khai thác (KEV).

Lỗi ảnh hưởng đến những hệ thống build OpenSSH theo một cách nhất định, tiêu biểu là Alpine Linux. Red Hat Enterprise Linux và Ubuntu cho biết họ không bị ảnh hưởng. Bài viết này hướng dẫn cách nhận biết máy chủ của bạn có bị ảnh hưởng không, cách cập nhật, cách xử lý khi chưa cập nhật được và cách kiểm tra log.

Lỗi này là gì, vì sao nguy hiểm?

Khi chạy không có PAM, sshd tự kiểm tra mật khẩu. Theo Alpine Linux, hàm băm mật khẩu của musl mà sshd dùng trả về ký tự "*" khi mật khẩu quá dài. Nhưng "*" cũng là giá trị hệ thống lưu cho những tài khoản không có mật khẩu. Vì vậy hai giá trị khớp nhau và đăng nhập thành công.

Alpine cho biết cuộc tấn công chỉ cần một kết nối, lần nào cũng thành công và không cần thử lại. Nhóm phát triển OpenSSH cho biết nguyên nhân gốc nằm ngoài OpenSSH, nhưng vì có thể bị khai thác qua sshd nên họ đã thêm bước kiểm tra trong sshd để chặn.

Máy chủ của bạn có bị ảnh hưởng không?

Theo Alpine Linux, hệ thống chỉ bị ảnh hưởng khi cả 4 điều kiện sau đều đúng:

• sshd chạy không có PAM (gói openssh-server của Alpine, hoặc openssh-server-pam với UsePAM no)
• Đăng nhập bằng mật khẩu đang bật (PasswordAuthentication yes, mặc định là bật)
• Có tài khoản mà trường mật khẩu là "*" (root trên Alpine từ khoảng bản 3.16, người dùng chỉ đăng nhập bằng key, v.v.)
• Trên cùng máy có ít nhất một tài khoản có mật khẩu thông thường (bắt đầu bằng $5$ hoặc $6$)

Lưu ý: các hệ thống và thiết bị khác build OpenSSH với musl và không có PAM cũng có thể bị ảnh hưởng. Với thiết bị chuyên dụng, hãy xem thông tin của nhà sản xuất.

Có thể kiểm tra trên máy chủ như sau (cần quyền quản trị):

cat /etc/os-release
sshd -T | grep -i -E 'usepam|passwordauthentication'
awk -F: '$2 == "*" {print $1}' /etc/shadow

Dòng 1 cho biết hệ điều hành, dòng 2 cho biết cấu hình PAM và đăng nhập bằng mật khẩu, dòng 3 liệt kê các tài khoản có trường mật khẩu là "*".

Gói sửa lỗi của Alpine Linux

Dưới đây là các gói openssh đã sửa lỗi mà Alpine Linux công bố. Phiên bản này hoặc mới hơn là đã sửa.

Lưu ý: các bản 3.16 đến 3.20 đã hết hỗ trợ cũng có gói sửa, nhưng những lỗi khác vẫn không được sửa, nên chúng tôi khuyên chuyển sang bản còn hỗ trợ. Nếu bạn tự build OpenSSH, hãy dùng 10.6p2 trở lên.

5 bước xử lý

1. Liệt kê máy chủ và container Alpine

   Kiểm tra máy ảo, container Docker và image cloud. Chỉ những máy đang chạy sshd mới bị ảnh hưởng. Container không chạy sshd thì không.

2. Cập nhật gói

   Chạy apk upgrade -U -a và xác nhận phiên bản khớp bảng trên. Với container, build lại image rồi thay thế.

3. Khởi động lại sshd

   Cập nhật gói không thay tiến trình sshd đang chạy. Chạy rc-service sshd restart.

4. Tắt đăng nhập bằng mật khẩu

   Sau khi chắc chắn đăng nhập bằng key hoạt động, đặt PasswordAuthentication no. Việc này giúp phòng các lỗi tương tự.

5. Kiểm tra log

   Làm theo phần "Cách tìm dấu hiệu bị tấn công" bên dưới.

Khi chưa cập nhật được

Alpine Linux và OpenSSH đưa ra cùng một cách tạm thời: tắt đăng nhập bằng mật khẩu. Thêm dòng sau vào cấu hình sshd rồi khởi động lại sshd:

PasswordAuthentication no

Giới hạn địa chỉ IP được phép kết nối SSH bằng firewall cũng là cách phổ biến để giảm rủi ro.

Cách tìm dấu hiệu bị tấn công

Alpine Linux khuyên kiểm tra:

• Log của sshd có dòng "Accepted password for" với tài khoản không có mật khẩu không
• Có lần dùng doas (công cụ chạy lệnh với quyền quản trị) nào lạ không
• Có người dùng, tệp hay SSH key (authorized_keys) nào mới mà bạn không thêm không

Alpine Linux khuyên rằng nếu máy mở ra Internet và bạn không thể loại trừ khả năng đã bị đăng nhập, hãy coi như máy đã bị xâm nhập. Khi đó nên cân nhắc dựng lại máy. Bài "Lỗ hổng nhân Linux" cũng hướng dẫn cách kiểm tra máy chủ Linux.

Những điểm dễ bỏ sót với container và cloud

Vì nhẹ nên Alpine rất phổ biến trong container Docker và máy ảo nhỏ trên cloud. Đôi khi sshd cài để phát triển vẫn còn chạy trên production.

• Có image container cũ không rõ nguồn gốc đang chạy trên production không?
• Có chạy sshd bên trong container không? (Thường là không cần.)
• Cổng SSH (ví dụ 22) có mở ra Internet không?

Nếu người phụ trách đã nghỉ, hoặc không liên lạc được với công ty đã làm hệ thống, hãy xem "tiếp nhận bảo trì hệ thống".

Để nguyên hay xử lý ngay?

Hãy để Digi Dinos hỗ trợ

Digi Dinos hỗ trợ doanh nghiệp về DX, bảo mật, vận hành và bảo trì hệ thống. Chúng tôi đạt chứng nhận ISO 27001, có dịch vụ vận hành máy chủ và cloud, giám sát 24/7 (NOC). Đội ngũ của chúng tôi làm việc với khách hàng bằng tiếng Nhật.

• Kiểm kê máy chủ và container: liệt kê hệ điều hành, phần mềm và phiên bản đang chạy.
• Cập nhật và rà soát cấu hình: rà soát cấu hình SSH, chuyển sang đăng nhập bằng key, có kế hoạch rõ ràng kể cả với hệ thống không thể dừng.
• Giám sát và tiếp nhận vận hành: tiếp nhận cả máy chủ trước đây do công ty khác quản lý.

Câu hỏi thường gặp