Ngày 05/11/2026, OpenSSH phát hành bản 10.6p2 để vá lỗ hổng SSHole (CVE-2026-123158, CVSS 8.1). Lỗ hổng cho phép kẻ tấn công đăng nhập SSH vào server Linux mà không cần mật khẩu, chỉ bằng cách gửi một chuỗi mật khẩu thật dài. Chưa đầy 9 giờ sau khi công bố, đã có ghi nhận khai thác thực tế. Bài viết này giúp bạn biết server của mình có bị ảnh hưởng không, cách kiểm tra và cách vá ngay.
Tóm tắt nhanh: SSHole là gì?
SSHole (CVE-2026-123158) là lỗ hổng vượt qua xác thực mật khẩu trong OpenSSH, phần mềm SSH mà hầu hết server Linux dùng để quản trị từ xa. Trên các hệ thống dùng thư viện musl (như Alpine Linux) và không dùng PAM, kẻ tấn công có thể đăng nhập vào những tài khoản vốn đã bị khoá mật khẩu.
| Mã lỗi | CVE-2026-123158 (tên gọi: SSHole / sshole) |
| Mức độ | CVSS v3.1: 8.1 (Cao) |
| Ảnh hưởng | OpenSSH trước 10.6p2, chạy trên musl libc, không dùng PAM, có bật đăng nhập bằng mật khẩu |
| Không ảnh hưởng | Debian, Ubuntu, Fedora (dùng glibc), server dùng PAM, server đã tắt đăng nhập bằng mật khẩu |
| Bản vá | OpenSSH 10.6p2 và các gói openssh mới của Alpine (ra cùng ngày 05/11/2026) |
| Người phát hiện | Özgün Kültekin (Wakefield) |
Lỗ hổng hoạt động như thế nào?
SSHole không phải lỗi tràn bộ nhớ hay lỗi mã hoá. Nó là một lỗi logic sinh ra khi ba hành vi "vô hại" gặp nhau:
- Alpine Linux (từ bản 3.16, năm 2022) đặt mật khẩu của root và một số tài khoản chỉ dùng khoá SSH là dấu
*trong file/etc/shadow. Dấu*nghĩa là "tài khoản này không có mật khẩu hợp lệ". - OpenSSH (từ năm 2016), để chống dò tên người dùng, vẫn băm mật khẩu nhập vào kể cả khi tài khoản không có mật khẩu, bằng thông số của một tài khoản khác.
- Hàm
crypt()của musl (từ năm 2012) từ chối băm mật khẩu dài hơn 256 byte và trả về đúng chuỗi*.
Kết quả: kẻ tấn công gửi một mật khẩu dài từ 257 đến 1.024 byte. musl trả về *, khớp với * trong /etc/shadow, và sshd cho rằng mật khẩu đúng.
Trong quá trình nghiên cứu, Kültekin đã thử khoảng 17.600 kiểu đăng nhập bất thường trên nhiều bản build sshd khác nhau. Chỉ bản build dùng musl và không có PAM là chấp nhận đăng nhập sai.
Server của bạn có bị ảnh hưởng không?
Server chỉ bị ảnh hưởng khi có đủ tất cả các điều kiện sau:
- SSH server chạy trên musl libc: Alpine Linux, OpenWrt, Buildroot, Yocto, và nhiều Docker image dựa trên Alpine có cài OpenSSH.
- Không dùng PAM để kiểm tra mật khẩu (mặc định của gói openssh-server trên Alpine, hoặc có dòng
UsePAM no). - Bật đăng nhập bằng mật khẩu (mặc định của OpenSSH).
- Có ít nhất một tài khoản có mật khẩu là
*(tài khoản chỉ dùng khoá SSH, tài khoản LDAP, root trên Alpine). - Có ít nhất một tài khoản khác có mật khẩu thật.
Đặc biệt nguy hiểm: trên image Alpine chính thức của AWS và Azure (tiny-cloud, các bản 3.18.11 đến 3.24.3), user mặc định alpine được chạy doas mà không cần mật khẩu. Kẻ tấn công vào được user này là có quyền root.
Những hệ thống không bị ảnh hưởng
- Server dùng glibc: Debian, Ubuntu, Fedora. Phần lớn VPS chạy website WordPress ở Việt Nam thuộc nhóm này.
- Server dùng PAM để xác thực mật khẩu.
- Server đã đặt
PasswordAuthentication no(chỉ đăng nhập bằng khoá SSH). - Tài khoản bị khoá bằng dấu
!thay vì*. - Container không cài OpenSSH server, Dropbear, và SSH của OpenBSD.
Nếu bạn dùng shared hosting thì việc này thuộc trách nhiệm của nhà cung cấp. Nếu bạn thuê VPS hoặc server riêng, bạn (hoặc đơn vị quản trị cho bạn) phải tự kiểm tra.
Cách kiểm tra server trong 2 phút
Đăng nhập vào server bằng quyền root rồi chạy lần lượt các lệnh sau.
1. Xem hệ điều hành và phiên bản OpenSSH:
cat /etc/os-release
ssh -V2. Xem sshd có dùng musl không (có dòng chứa "musl" là có):
ldd $(which sshd) | grep musl3. Xem cấu hình đăng nhập mật khẩu và PAM:
sshd -T | grep -Ei 'passwordauthentication|usepam'4. Liệt kê các tài khoản có mật khẩu là dấu *:
awk -F: '$2=="*"{print $1}' /etc/shadowNếu bước 2 có musl, bước 3 ra passwordauthentication yes và usepam no, bước 4 có tài khoản: server của bạn đang có nguy cơ. Hãy vá ngay.
Cách vá lỗ hổng SSHole
Bước 1: Cập nhật OpenSSH và khởi động lại sshd
Trên Alpine Linux:
apk upgrade -U -a
rc-service sshd restartLưu ý quan trọng: chỉ cài gói mới là chưa đủ. Tiến trình sshd đang chạy vẫn là bản cũ cho đến khi bạn khởi động lại dịch vụ.
Alpine đã vá cho mọi nhánh từ 3.16 đến edge, kể cả các bản đã hết hỗ trợ:
| Nhánh Alpine | Gói openssh đã vá |
|---|---|
| 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 |
| 3.16 | 9.0_p1-r6 |
Bước 2: Tắt đăng nhập bằng mật khẩu
Đây là cách phòng thủ mà chính Damien Miller, người duy trì OpenSSH, khuyến nghị nếu chưa vá được. Nó cũng là cấu hình nên dùng lâu dài. Trước khi làm, hãy chắc chắn bạn đã đăng nhập được bằng khoá SSH, nếu không bạn sẽ tự khoá mình ra ngoài.
Thêm dòng sau vào /etc/ssh/sshd_config rồi khởi động lại sshd:
PasswordAuthentication no
KbdInteractiveAuthentication noBước 3: Build lại Docker image và image cloud
Container dựa trên image cũ vẫn mang bản OpenSSH lỗi. Hãy build lại từ image gốc mới nhất (ví dụ docker build --pull --no-cache) rồi triển khai lại.
Bước 4: Thu hẹp cổng SSH
Dùng tường lửa chỉ cho phép IP của bạn (hoặc VPN) truy cập cổng SSH. Lỗ hổng không thể bị khai thác nếu kẻ tấn công không kết nối được tới cổng.
Lỗ hổng đã bị khai thác thực tế chưa?
Có ghi nhận. Theo công ty bảo mật Previdian, nỗ lực khai thác đầu tiên xuất hiện chưa đầy 9 giờ sau khi CVE được công bố. Họ xác nhận kẻ tấn công đã lấy được quyền root trên một honeypot chạy Alpine Linux thật. Kẻ tấn công gửi mật khẩu cực dài rồi chạy các lệnh dò thông tin như id, uname, hostname.
Tính đến ngày 06/11/2026, CISA (Mỹ) chưa đưa lỗ hổng vào danh sách KEV (lỗ hổng đã bị khai thác). Nhưng mã khai thác đã có trên GitHub, nên các đợt quét tự động sẽ tăng nhanh. Lưu ý: không chạy các script "kiểm tra" hay "khai thác" không rõ nguồn trên GitHub, vì chúng có thể chứa mã độc.
Kiểm tra server đã bị xâm nhập chưa
Nếu server từng đủ điều kiện bị ảnh hưởng, hãy tìm dấu vết trong log:
grep "Accepted password for" /var/log/messages- Có dòng đăng nhập bằng mật khẩu vào tài khoản không có mật khẩu (
alpine,root, user chỉ dùng khoá): coi như server đã bị xâm nhập. - Kiểm tra lịch sử dùng
doas, tài khoản mới tạo gần đây và các fileauthorized_keyslạ. - Nếu không loại trừ được khả năng bị xâm nhập, hãy xử lý như server đã bị hack: sao lưu, cài lại sạch và đổi toàn bộ khoá, mật khẩu.
Server bị chiếm quyền thường kéo theo website bị chèn mã độc, tự chuyển hướng sang trang lạ, bị Google cảnh báo và giảm thứ hạng. Nếu bạn đã thấy các dấu hiệu này, xem dịch vụ bảo mật và xử lý mã độc website của TitanWeb.
Bài học: lỗ hổng SSH sẽ còn xuất hiện
SSHole không phải lỗ hổng OpenSSH đầu tiên và cũng không phải cuối cùng. Chỉ riêng năm 2026, OpenSSH đã vá CVE-2026-35414 (tháng 4, cho phép đăng nhập root khi dùng chứng chỉ SSH, sửa trong bản 10.3). Năm 2024 có regreSSHion (CVE-2024-6387) ảnh hưởng hàng triệu server glibc.
Điểm chung của các vụ này: server được cập nhật kịp thời, chỉ đăng nhập bằng khoá SSH và có tường lửa giới hạn cổng SSH gần như không bị ảnh hưởng. Vấn đề là nhiều doanh nghiệp thuê VPS xong rồi để đó, không ai theo dõi tin bảo mật, không ai vá.
TitanWeb bảo vệ server và website của khách hàng thế nào?
Với các server do TitanWeb quản trị, SSHole không có cơ hội. Ngay từ khi bàn giao, mọi server đều đã được gia cố theo đúng các nguyên tắc ở trên:
- Chỉ đăng nhập bằng khoá SSH, tắt đăng nhập root bằng mật khẩu, loại bỏ tài khoản và khoá không xác định.
- Tường lửa chỉ mở cổng cần thiết, tự động chặn IP dò mật khẩu.
- Theo dõi tin bảo mật và vá kịp thời hệ điều hành, OpenSSH, web server, PHP và cơ sở dữ liệu. Khi lỗ hổng mới được công bố, chúng tôi rà soát toàn bộ server của khách hàng, không đợi khách hỏi.
- Rà soát định kỳ file lạ, cổng mở ngoài ý muốn và dịch vụ không cần thiết.
- Sao lưu hằng ngày ra ngoài server, có sự cố là khôi phục được ngay.
Bạn có thể chọn dịch vụ phù hợp:
- Hosting, VPS cho WordPress: thuê server đã có người lo bảo mật và vận hành, từ 100.000 ₫/tháng.
- Chăm sóc website: cập nhật, sao lưu, vá lỗ hổng, giám sát 24/7 và gửi báo cáo hằng tháng.
- Bảo mật và xử lý mã độc: website đã bị hack, chúng tôi dọn sạch, vá lỗ hổng gốc và gia cố để không bị hack lại.
Không chắc server của mình có bị ảnh hưởng? Gọi hoặc nhắn Zalo 0966.000.061, hoặc liên hệ TitanWeb để được kiểm tra.
Câu hỏi thường gặp
Website WordPress của tôi có bị ảnh hưởng bởi SSHole không?
SSHole nhắm vào server, không phải WordPress. Website chỉ bị ảnh hưởng khi server chạy website dùng Alpine (hoặc hệ thống musl khác), không dùng PAM và bật đăng nhập SSH bằng mật khẩu. Đa số website WordPress chạy trên Ubuntu hoặc Debian nên không bị ảnh hưởng trực tiếp.
Server Ubuntu, Debian, CentOS có cần làm gì không?
Không bị SSHole ảnh hưởng vì dùng glibc. Tuy vậy, máy chủ Ubuntu vẫn cần được cập nhật thường xuyên để phòng ngừa các nguy cơ khai thác từ xa ở tầng nhân, điển hình như lỗ hổng kernel CVE-2026-98432 mới được công bố.
Với shared hosting, nhà cung cấp chịu trách nhiệm vá server. Bạn nên hỏi họ đã kiểm tra lỗ hổng này chưa. Đây cũng là một trong những yếu tố cần lưu ý khi chọn hosting: nhà cung cấp có vá lỗi bảo mật nhanh không.
Đổi cổng SSH khác 22 có tránh được lỗ hổng không?
Không. Đổi cổng chỉ giảm bớt các đợt quét tự động. Cách đúng là vá OpenSSH, tắt đăng nhập bằng mật khẩu và giới hạn IP được kết nối tới cổng SSH.
Kết luận
SSHole chỉ ảnh hưởng một nhóm hệ thống cụ thể (musl, không PAM, bật mật khẩu), nhưng bị khai thác chỉ vài giờ sau khi công bố. Nếu bạn dùng Alpine hoặc Docker image có OpenSSH, hãy cập nhật, khởi động lại sshd và tắt đăng nhập bằng mật khẩu ngay hôm nay. Nếu bạn không có thời gian theo dõi những tin như thế này, hãy để TitanWeb chăm sóc website và server cho bạn.
Nguồn tham khảo: Help Net Security, OX Security, CIS (CVE-2026-35414).