Zero-day Citrix NetScaler CVE-2026-88771: log bị đầu độc thành root shell

Giả sử bạn là người quản trị hạ tầng của một công ty vừa phải. Cái NetScaler Gateway đặt ở rìa mạng từ mấy năm trước, nhân viên VPN vào làm việc từ xa qua nó mỗi sáng. Chẳng ai đụng tới nó trừ lúc cập nhật firmware, vì nó chạy ổn, mà đụng vào thì sợ cả công ty mất VPN.

Sáng thứ Bảy 26/9/2026, trên Reddit có người báo: nhà cung cấp IT và đội bảo mật đang nhắn riêng cho khách hàng, khuyên tắt hẳn các NetScaler đi. Cơ quan chức năng, CERT các nước gọi điện cho một số tổ chức. Chưa có CVE nào để tra, chưa có bản vá nào để cài. Chỉ có tin đồn rằng cái hộp ở rìa mạng của bạn đang bị người lạ vào bằng cửa trước, mà không cần mật khẩu.

Hôm sau, Citrix công bố advisory. Tin đồn là thật.

# chuyện gì đã xảy ra

Mình dựng lại dòng thời gian từ các nguồn gốc mà mình đọc được. Chỗ nào chỉ có một nguồn thì có ghi chú.

Một chi tiết đáng chú ý: Citrix nói họ tìm ra lỗi khi điều tra sự cố của chính khách hàng, và đã nộp thông báo theo Cyber Resilience Act của EU (theo BleepingComputer). Nghĩa là lần này vendor không phải người phát hiện đầu tiên, khách hàng bị đánh trước.

Về điểm số: các nguồn thứ cấp đều ghi 9.5 theo CVSS v4.0 cho cả hai lỗi, và watchTowr cũng ghi 9.5 cho CVE-2026-88772. Mình không mở được trang CTX697096 của Citrix (trang chỉ trả "Loading..." khi tải tự động), nên con số 9.5 mình tin ở mức "nhiều nguồn khớp nhau", bạn nên tự đối chiếu trên bulletin. Có nơi đưa số khác (một hãng Trung Quốc ghi 9.8 theo CVSS 3.1, một nguồn nhắc NVD ghi 8.1 cho 88772), đó là hệ chấm điểm hoặc thời điểm khác nhau chứ chưa chắc là mâu thuẫn.

# lỗi nằm ở đâu: một script Perl chạy bằng root

Phần hay nhất của vụ này là nó không nằm trong đoạn code xử lý mạng phức tạp nào. Nó nằm trong một script Perl bảo trì.

Theo watchTowr, gốc rễ của CVE-2026-88771 là file ns_monuploadd_err.pl. Script này xử lý thông tin crash của nsppe (packet engine của NetScaler), chạy định kỳ bằng quyền root. Công việc của nó nghe rất vô hại: quét log tìm dòng do tiến trình giám sát (Pitboss) ghi khi PPE bị chết hoặc lỡ nhịp heartbeat, lấy ra tên engine nằm sau chữ NSPPE, rồi dùng tên đó đi tìm file core dump tương ứng bằng find.

Chỗ hỏng: cả hai bước đều dựng lệnh shell bằng backtick, và tên core file lấy thẳng từ nội dung log mà không kiểm tra gì. Mình viết lại mô hình lỗi này dưới dạng đoạn minh hoạ đơn giản hoá. Đây không phải code gốc của Citrix, chỉ để thấy dạng lỗi:

# MINH HOẠ đơn giản hoá, KHÔNG phải code gốc của NetScaler
# Bước 1: lấy dòng log cuối cùng khớp mẫu của Pitboss
my $line = `grep "pitboss.*PPE.*died" /var/log/ns.log | tail -1`;
 
# Bước 2: rút "tên core file" từ phần text sau NSPPE
my ($name) = $line =~ /NSPPE(.*)/;
 
# Bước 3: nhét thẳng vào lệnh shell tiếp theo
my $found = `find /var/core -name "$name*"`;

Vấn đề là ở bước 3. Chuỗi $name đi qua shell, nên ký tự điều khiển của shell trong đó (dấu chấm phẩy, ký tự thay thế lệnh...) được hiểu là lệnh chứ không phải tên file. Giống đi chợ đưa tờ giấy ghi "mua 1 cân cà chua", mà ai đó viết thêm dòng "rồi mở két sắt" bên dưới, còn người đi chợ thì đọc hết và làm theo.

Còn một chỗ vướng: kẻ tấn công không đăng nhập thì làm sao đưa chữ của họ vào log? Hoá ra dễ hơn mình tưởng, vì log của thiết bị ghi lại rất nhiều thứ do người ngoài kiểm soát: tên user của lần đăng nhập thất bại, tham số request, header User-Agent. watchTowr xác nhận rằng các dữ liệu này đều có thể bị ghi vào log.

CERT-EU mô tả chuỗi tấn công thực tế bị quan sát trong tự nhiên khá cụ thể:

1. Kẻ tấn công gửi request có User-Agent chứa lệnh mã hoá base64, được NetScaler ghi vào HTTP log sau một dấu mốc INDEX:.
2. Rồi gửi request đăng nhập với username giả dạng dòng log của Pitboss ("PPE missed too many heartbeats"), chèn thêm đoạn lệnh: grep lấy payload sau INDEX từ HTTP log, giải mã base64, chuyển cho sh.
3. Khi script chạy, nó lấy dòng khớp cuối cùng (tail -1) và đưa vào shell. Vì vậy kẻ tấn công liên tục spam log để dòng của chúng luôn là dòng mới nhất.
4. Hậu khai thác: bật php_engine trong /etc/httpd.conf và thả một web shell PHP ở đường dẫn có thể truy cập từ Internet để giữ chỗ.

Một điểm khiến lỗi này khó chịu: có độ trễ. Script chạy theo lịch, nên giữa lúc bị "đầu độc" log và lúc lệnh thực thi có thể trôi qua tới 24 giờ (watchTowr nói có thể ép chạy sớm hơn). Nghĩa là log của bạn có thể đã chứa mồi từ hôm qua, và bản vá hôm nay chưa chắc đã dọn nó.

Bản vá thì đúng kiểu sách giáo khoa. Phiên bản mới đọc log trực tiếp bằng Perl, dùng regex chặt chỉ chấp nhận tên PPE dạng NSPPE-00 cộng PID là số, gọi find bằng danh sách tham số (không qua shell), tìm tên file chính xác thay vì tiền tố có wildcard, và kiểm tra lại đường dẫn trả về bằng tập ký tự hạn chế. Tức là: dữ liệu là dữ liệu, lệnh là lệnh, đừng để hai thứ gặp nhau trong một chuỗi.

# còn CVE-2026-88772 và 88779

CVE-2026-88772 là lỗi hoàn toàn khác loại: tràn bộ nhớ trong phần ghép lại bản tin handshake DTLS của nsppe. Theo watchTowr, sau khi ghép, một hàm sao chép lần lượt các buffer vào một vùng đệm cố định 0x8c00 byte (35.840 byte) mà không kiểm tra còn chỗ không. Bookkeeping của quá trình ghép có thể bị lừa để coi bản tin là "đủ" trong khi dữ liệu thực tế lớn hơn vùng đệm nhiều, thế là ghi tràn. Điều kiện: DTLS đang bật (mặc định trên VPN virtual server, trừ khi admin đặt -dtls OFF), kẻ tấn công với tới được cổng UDP của DTLS (phòng lab của watchTowr dùng 9462/UDP). Cookie exchange của DTLS chỉ chứng minh client nhận được gói tại IP của nó, không phải xác thực. Kết quả có thể là RCE hoặc DoS. Mandiant gắn lỗi này với chiến dịch từ đầu tháng 9.

CVE-2026-88779 nằm trong cấu hình SAML (Service Provider hoặc Identity Provider). Theo alert của CISA, nó có thể gây DoS, và trên thiết bị chưa vá, kẻ tấn công có thể dùng nó để ép thiết bị khởi động lại, hỗ trợ việc thực thi đoạn code đã cài qua CVE-2026-88771. Lỗi này vào KEV ngày 4/10. Mình chỉ có CISA làm nguồn cho mô tả này, chưa mở được bulletin riêng CTX697174 của Citrix.

Thành ra bức tranh lớn là: một đường vào bằng log injection (88771), một đường vào bằng bộ nhớ (88772), và một lỗi phụ trợ để chạy lại lúc cần (88779). Vá một lỗi mà bỏ qua phần còn lại thì vô nghĩa, tất cả đều nằm trong cùng một bản cập nhật.

# ai bị ảnh hưởng, vá lên bản nào

CVE-2026-88771 ảnh hưởng mọi triển khai NetScaler ADC và Gateway do khách hàng tự quản lý, kể cả cấu hình mặc định, không cần bật tính năng đặc biệt nào. Bản vá theo advisory (qua BleepingComputer và watchTowr trích lại):

Khi so bản vá, watchTowr dùng 14.1-73.30 (dính) và 14.1-73.37 (đã vá). Secure Private Access chạy hybrid với NetScaler instance cũng phải nâng cấp. Dịch vụ Citrix quản lý trên cloud thì Cloud Software Group tự lo, nhưng appliance của bạn thì bạn tự lo.

Mình không tìm thấy danh sách đầy đủ các bản bị ảnh hưởng ở các nguồn đọc được, nên quy tắc đơn giản nhất là: thấp hơn bản "cần ít nhất" ở bảng trên thì coi như dính. Các nhánh cũ hơn đã hết hỗ trợ (end-of-life) thì không có bản vá, chỉ có đường nâng cấp lên nhánh còn hỗ trợ.

# kiểm tra thiết bị của mình

Mọi lệnh dưới đây chỉ đọc, không sửa gì. Nhưng nhớ nguyên tắc của CISA: nếu nghi ngờ bị xâm nhập, giữ lại bằng chứng pháp y trước khi cập nhật, vì nâng cấp có thể làm mất dấu vết. Chụp snapshot hoặc xuất log ra ngoài trước. Cũng đừng reboot theo phản xạ.

Kiểm tra phiên bản, ở CLI NetScaler:

show ns version

So kết quả với bảng ở trên. Nếu có DTLS cần xem, kiểm tra virtual server VPN:

show vpn vserver

Tìm dòng nói về DTLS trong kết quả (tên trường có thể khác giữa các bản, mình không xác nhận được chính xác trên mọi build).

Vào shell của appliance để tìm dấu hiệu trong log. Lệnh dưới đây đếm các dòng log "Pitboss" đáng ngờ, dòng nào chứa ký tự lạ của shell thì đáng xem kỹ:

shell
grep -E "pitboss.*PPE.*(missed|died)" /var/log/ns.log* /var/log/messages 2>/dev/null | head -50
grep -n "php_engine" /etc/httpd.conf

Dòng log Pitboss thật chỉ có tên engine và số, rất ngắn gọn. Nếu thấy dòng chứa ${IFS}, grep INDEX:, dấu ;, |, base64 hay chuỗi kỳ lạ thì đó là dấu hiệu đã bị đầu độc log. Còn php_engine bật trong httpd.conf mà bạn không hề cấu hình thì đó là dấu hiệu rất mạnh của web shell.

# dấu hiệu đã bị xâm nhập (IoC)

Từ các nguồn đã đọc:

• Request POST /nf/auth/doAuthentication.do có body chứa chuỗi "pitboss PPE unexpectedly died NSPPE" (Help Net Security, dựa trên IoC của Arctic Wolf).
• User-Agent chứa chuỗi base64 kèm dấu mốc INDEX:; request tới đường dẫn kết thúc bằng /logon/LogonPoint/tmindex.html (CERT-EU).
• Log xác thực chứa "pitboss", "PPE NSPPE missed too many heartbeats" lẫn cú pháp shell (CERT-EU).
• php_engine bật bất thường trong /etc/httpd.conf, file PHP lạ trên appliance (CERT-EU).
• Tra cứu DNS tới tên miền kết thúc bằng instances.httpworkbench.com, và traffic ra IP 138.199.200.90 (Hetzner), theo Help Net Security dẫn lại. Hai chi tiết này mình chỉ có một nguồn thứ cấp, nên hãy đối chiếu thêm với bộ IoC của Arctic Wolf trước khi chặn theo.
• Kevin Beaumont cho biết mỗi nạn nhân có một web shell riêng, không quét từ xa để tìm ra được. Tức là "scan từ ngoài không thấy gì" không có nghĩa là sạch.

Công cụ Citrix phát hành để phát hiện cũng được chính Citrix cảnh báo là có thể bỏ sót máy đã bị xâm nhập thật. watchTowr có công cụ "detection artefact generator" trên GitHub, nhưng nó phục vụ xác định mức độ phơi nhiễm hơn là kết luận sạch.

Nếu thấy dấu hiệu, hướng dẫn của CISA là: khôi phục từ bản sao lưu sạch có từ trước thời điểm nghi ngờ, rồi xoay toàn bộ secret trên thiết bị: mật khẩu tài khoản cục bộ, key-encryption key, chứng chỉ SSL. Citrix có tài liệu riêng cho trường hợp này (CTX694799). Và chuyển log NetScaler về SIEM, vì log local quay vòng rất nhanh, đúng thứ bạn cần nhất khi điều tra.

# biện pháp tạm thời

Điểm yếu của vụ này: với 88771, mình không tìm thấy mitigation nào của Citrix ngoài việc nâng cấp. Bài của BleepingComputer cũng nói không có workaround cụ thể. Nếu chưa vá được ngay thì những thứ khả dĩ là giảm phơi nhiễm ra Internet (ACL, chặn nguồn không cần thiết), tắt DTLS bằng -dtls OFF nếu bạn không dùng (chỉ giải quyết 88772, không đụng 88771), và săn log theo IoC ở trên. Đây là suy luận của mình từ cơ chế lỗi, chưa phải khuyến nghị chính thức của vendor.

# vì sao NetScaler cứ dính hoài

Lỗi này không đứng một mình. Dòng thời gian của NetScaler mấy năm qua đọc như một bộ phim dài tập: CVE-2019-19781 (path traversal, 2019), CitrixBleed CVE-2023-4966 (rò session token từ bộ nhớ, 2023), CitrixBleed 2 CVE-2025-5777 (2025), cộng với một loạt lỗi khác. Chính watchTowr cũng có các bài về những lỗ hổng NetScaler từ đầu năm 2026 mà mình chưa kịp đọc kỹ. Chuyện này không phải xui.

Theo mình, có ba lý do.

Thứ nhất, vị trí. NetScaler nằm ở rìa mạng, nghe cổng công khai, và từ đó nhìn thấy được mạng nội bộ. Kẻ tấn công chiếm được nó là có sẵn chỗ đứng với đặc quyền cao, session của người dùng, cả thông tin xác thực đi qua. Hiệu quả cao nhất cho công sức bỏ ra, nên nó bị săn kỹ nhất.

Thứ hai, độ phức tạp. Một appliance NetScaler gói trong mình packet engine viết bằng C, web UI, bộ xử lý SAML, VPN, DTLS, rồi cả đống script Perl, shell, PHP bảo trì. Bề mặt tấn công khổng lồ, và code bảo trì thì ít được rà soát gắt gao như code mạng. Vụ này là ví dụ đẹp: lỗi nằm ở một script giám sát tiện ích, không phải ở bộ xử lý giao thức mà ai cũng nhìn chằm chằm.

Thứ ba, bạn không thấy bên trong. Appliance là hộp đen, bạn không cài EDR lên đó được, log thì quay vòng nhanh. Kẻ tấn công vào xong, bạn mù. Đó là lý do web shell riêng cho từng nạn nhân là chuyện rất đáng ngại.

Vài quan điểm riêng. Cái làm mình bận tâm là lớp lỗi: log injection dẫn tới command injection là chuyện chúng ta đã biết từ thời Log4Shell, thế mà vẫn xuất hiện trong thiết bị bảo mật của năm 2026. Nguyên tắc "log là dữ liệu không đáng tin, đừng bao giờ nội suy nó vào lệnh" lẽ ra phải là phản xạ, mà code chạy bằng root còn dính. Đó cũng là bài học cho code của chính mình: cron job, script dọn dẹp, tool nội bộ hay đọc log rồi chạy lệnh tiếp thường chạy bằng quyền cao nhất và ít được review nhất.

Một bài học khác là về cái giá của "chạy ổn thì đừng đụng". Với những hộp như thế này, lịch vá nên tính bằng ngày chứ không bằng quý, vì khoảng cách từ công bố tới khai thác hàng loạt lần này chỉ là vài ngày (PoC ra là có người spray ngay trong vài phút). Đổi lại bạn phải chấp nhận downtime cho cửa sổ nâng cấp, và phải có thiết bị dự phòng (HA pair) để nâng cấp không làm sập VPN. Chi phí đó thật, nhưng rẻ hơn nhiều so với dựng lại mạng sau khi bị xâm nhập.

Và nếu có thể, đừng để quản trị và dịch vụ trên cùng một mặt phẳng công khai. Giữ giao diện quản lý trong mạng riêng, chuyển log ra ngoài, giám sát DNS đi ra từ appliance (appliance mà đi tra tên miền lạ là chuyện không bình thường).

# nên làm gì ngay

1. Kiểm tra phiên bản bằng show ns version, đối chiếu với bảng bản vá.
2. Nếu có thể bị tác động trước bản vá: thu thập bằng chứng, săn IoC trong log và httpd.conf, rồi mới vá.
3. Vá lên bản đã sửa (14.1-73.37, 13.1-64.23 trở lên hoặc bản FIPS tương ứng).
4. Nếu thấy dấu hiệu bị xâm nhập: khôi phục từ backup sạch, xoay mọi secret, chuyển log về SIEM.
5. Sau đó đọc bài watchTowr gốc để hiểu kỹ cơ chế, và theo dõi CVE-2026-88779 cùng CVE-2026-107406 trong alert của CISA vì danh sách này còn được cập nhật.

# tham khảo

• CISA: Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway
• Citrix: bulletin CTX697096 (không mở tự động được, mình đối chiếu qua các nguồn trích dẫn)
• Citrix: hướng dẫn khi nghi ngờ thiết bị bị xâm nhập, CTX694799
• watchTowr Labs: Oh Look, The Foot Gun Went Off Again (CVE-2026-88771)
• watchTowr Labs: Here We Go Again (CVE-2026-88772)
• CERT-EU: Taking execute logging a bit too literally (CVE-2026-88771)
• BleepingComputer: Citrix admins warned to shut down NetScalers over 2 exploited zero-days
• Help Net Security: NetScaler zero-day exploitation escalates into mass attacks
• Arctic Wolf: IoC cho CVE-2026-88771
• CISA KEV Catalog

Chỉ là những ghi chép cá nhân với hy vọng mang lại chút giá trị. Nếu thấy hữu ích, đừng ngại chia sẻ cho bạn bè & đồng nghiệp nhé!

Happy coding 😎 👍🏻 🚀 🔥.