Báo động 21/10: GitLab, Argo CD, PHP2Shell, Node.js và PwnEscape cùng lúc, vá gì trước?

Sáng thứ Tư, bạn vừa mở laptop với cốc cà phê còn nóng thì nhóm chat kỹ thuật đã báo liên tục: GitLab có lỗi điểm tuyệt đối, PHP phát hành bản vá khẩn, Node.js cũng vá một loạt lỗi, còn lỗi Argo CD từ đầu tháng vẫn chưa ai xử lý xong. Mỗi tin nhắn kèm một mã CVE dài ngoằng, và câu hỏi duy nhất trong đầu bạn là: vá cái nào trước?

Đó đúng là tình huống của nhiều đội vận hành trong ngày 21/10/2026. Bài này gom lại toàn bộ đợt cảnh báo đó theo hướng dẫn "sống sót trên production" của TechPipe: lỗi nằm ở đâu, phiên bản nào an toàn, cách kiểm tra bằng lệnh, cách giảm rủi ro tạm thời, và quan trọng nhất là vì sao cài bản vá xong chưa chắc đã an toàn.

Vì sao đợt cảnh báo này đáng sợ hơn thường lệ?

Một lỗi bảo mật đơn lẻ thì đội nào cũng quen. Điều khiến đợt này nguy hiểm là các thành phần bị lỗi nằm dọc toàn bộ dây chuyền đưa phần mềm lên production:

• GitLab giữ mã nguồn và chạy CI/CD, tức nơi phần mềm được xây.
• Argo CD đọc Git rồi đẩy cấu hình xuống Kubernetes, tức nơi phần mềm được triển khai.
• PHP và Node.js là runtime, tức nơi ứng dụng thực sự chạy.
• Nhân Linux (lỗi PwnEscape) là nền móng bên dưới tất cả, kể cả máy chủ ảo hoá.

Hãy hình dung một nhà máy bị báo hỏng cùng lúc ở kho nguyên liệu, băng chuyền, máy đóng gói và cả nền nhà xưởng. Sửa riêng một chỗ thì dây chuyền vẫn hở ở chỗ khác.

TechPipe xếp mức ưu tiên như sau:

Thứ tự gợi ý: làm GitLab và PHP đang mở ra Internet trước, sau đó tới Argo CD có người đóng góp không tin cậy hoặc phân quyền đọc ứng dụng quá rộng, rồi mới tới các dịch vụ Node.js đang lộ ra ngoài.

GitLab: một biểu thức chính quy đủ để chiếm máy chủ?

Lỗi CVE-2026-110264 đạt điểm tối đa CVSS 10.0. Gốc rễ là một lỗi integer overflow (tràn số nguyên) trong bộ biên dịch regular expression (biểu thức chính quy) mà GitLab CE và EE sử dụng. Kẻ tấn công gửi một regex được chế tác đặc biệt là có thể thực thi mã tuỳ ý, không cần đăng nhập.

Tràn số nguyên giống như đồng hồ công-tơ-mét xe máy chạy quá 99.999 km thì quay về 00.000: chương trình tưởng mình đang xử lý một con số nhỏ, trong khi thực tế dữ liệu lớn hơn rất nhiều, và phần dư tràn sang vùng nhớ không được phép đụng tới.

Vài điểm đáng chú ý:

• Lỗi ảnh hưởng ngược về tận GitLab 7.0 (năm 2014), gồm cả các nhánh phát hành cũ.
• Thành phần lỗi liên quan tới engine Onigmo của Ruby. Cập nhật Ruby của hệ điều hành không thay thế được việc cập nhật GitLab, vì GitLab dùng runtime đóng gói riêng.

Kiểm tra phiên bản và trạng thái:

sudo gitlab-rake gitlab:env:info
dpkg-query -W 'gitlab-ce' 'gitlab-ee'
rpm -q gitlab-ce gitlab-ee
sudo gitlab-ctl status

Ví dụ nâng cấp trên Debian/Ubuntu với bản CE 19.5.x (bản EE thì dùng gói gitlab-ee):

sudo apt-get update
sudo apt-get install gitlab-ce=19.5.1-ce.0

Trước khi bấm Enter, hãy chắc rằng bạn có bản sao lưu khôi phục được (repo, database, cấu hình, secrets), đã xem lộ trình nâng cấp và lên kế hoạch cho migration lẫn khởi động lại. Theo GitLab, bản 19.4.3 và 19.3.6 có migration thường, riêng 19.4.3 còn có migration sau triển khai. Cài đặt một node thì nên chuẩn bị tinh thần có downtime. Bản chạy container thì phải cập nhật image.

Nếu chưa thể vá ngay, bài gốc nói thẳng là không có cách cấu hình nào giảm thiểu đáng tin cậy. Việc tạm thời có thể làm: chỉ cho HTTP(S) truy cập từ mạng tin cậy hoặc VPN, giảm phơi bày dự án công khai và tích hợp bên ngoài, giữ lại log, theo dõi các sự cố crash bất thường. GitLab có phát hành luật phát hiện mã nguồn mở tên "Onigmo native worker crash" và "Org mode render error burst", nhưng đó chỉ là điểm xuất phát, không phải bằng chứng là bạn an toàn.

Argo CD: tài khoản "chỉ đọc" cũng không vô hại

Argo CD có ba lỗi cùng điểm CVSS 9.9, được vá từ 6/10 và công bố trên GitHub advisory ngày 7/10/2026. Cả ba đều nhắm vào repo-server, thành phần đọc kho Git và dựng ra manifest để triển khai.

• CVE-2026-113708 – chèn lệnh qua Kustomize remote reference. Giá trị trong URL remote base của Kustomize có thể bị truyền vào git fetch và được hiểu như tuỳ chọn của Git, dẫn tới thực thi lệnh qua các transport Git cục bộ. API tải manifest chỉ cần quyền "Application get" trên một Application có sẵn. Chặn kết nối ra ngoài của repo-server không ngăn được đường tấn công qua transport cục bộ. Giảm thiểu tạm: ghim Kustomize về bản cũ hơn 5.0 (ví dụ 4.5.7) nếu tương thích.
• CVE-2026-113709 – chạy plugin Helm qua Kustomize. Khi bật render Helm trong Kustomize, một repo độc hại có thể điều khiển thư mục cấu hình của Helm và chạy plugin do repo đó kiểm soát ngay trong argocd-repo-server. Giảm thiểu: bỏ --enable-helm khỏi kustomize.buildOptions, trừ khi production đang dựa vào chart Helm render qua Kustomize. Cách này chỉ chặn đúng lỗi này.
• CVE-2026-113672 – đọc file tuỳ ý qua Jsonnet. Trình import Jsonnet có thể đọc file ngoài repo, làm lộ biến môi trường, private key được mount và thông tin xác thực service account.

Nếu Argo CD là người điều phối cảng, repo-server chính là bộ phận đọc vận đơn. Ai nhét được một vận đơn giả vào đó là có thể ra lệnh cho cả bến.

Với lỗi Jsonnet, có thể tắt tạm trong argocd-cm:

data:
  jsonnet.enable: "false"

Các bản major cũ hơn không có bản vá được liệt kê. Bài gốc khuyên ưu tiên nhánh ổn định được hỗ trợ thay vì bản prerelease. Kiểm tra trên Kubernetes:

kubectl -n argocd get pods \
  -l app.kubernetes.io/name=argocd-repo-server \
  -o custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[*].image
kubectl -n argocd get deployment argocd-repo-server \
  -o jsonpath='{.spec.template.spec.containers[*].image}{"\n"}'
kubectl -n argocd get configmap argocd-cm -o yaml \
  | grep -E 'jsonnet.enable|kustomize.buildOptions'
kubectl -n argocd get configmap argocd-rbac-cm -o yaml

Rà lại RBAC xem ai đang có quyền applications, get. Trên các phiên bản bị ảnh hưởng, một tài khoản Argo CD chỉ đọc không được coi là vô hại. Bài gốc cũng nhấn mạnh: chỉ hạn chế API hay tắt đồng bộ tự động không sửa được các lỗi này. Việc cần làm là nâng cấp qua quy trình triển khai sẵn có, kiểm tra image repo-server đang chạy chứ không chỉ phiên bản chart, rà các repo có người đóng góp không tin cậy, siết quyền tạo manifest và quyền Kubernetes của repo-server. Bản phát hành tháng 10 còn vá thêm một lỗi vượt giới hạn AppProject liên quan đến hook xoá tài nguyên.

PHP2Shell: lỗi nằm trong chính PHP, không phải trong ứng dụng

Đây là điểm khiến PHP2Shell khác với lỗi WordPress hay Laravel thường gặp. CVE-2026-109618 và CVE-2026-109619 nằm trong runtime PHP, nên dù code của bạn viết cẩn thận tới đâu, máy chủ vẫn có thể bị thực thi mã từ xa không cần đăng nhập. Điểm CVSS là 9.2 (theo v4).

Các mô hình chạy bị ảnh hưởng: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP và LiteSpeed. Theo PHP, mod_php đặc biệt dễ bị lộ.

Nhánh cũ hơn cần có bản backport được xác nhận từ bản phân phối hoặc nhà cung cấp thương mại. Gói cập nhật đã có trên Remi (EL8, EL9, EL10) và các bản cập nhật bảo mật của Debian/Ubuntu còn được hỗ trợ.

# RHEL, AlmaLinux và họ hàng
sudo dnf upgrade --refresh 'php*'
# Debian/Ubuntu
sudo apt update && sudo apt upgrade

Với Docker, build lại image trên base đã vá, ví dụ FROM php:8.4.27-fpm. Sau khi cập nhật, khởi động lại PHP-FPM hoặc Apache và xác nhận runtime đang phục vụ web đúng là bản mới. Gói mới nằm trên đĩa nhưng tiến trình cũ vẫn chạy trong RAM thì coi như chưa vá.

Giảm thiểu tạm thời, chỉ có tác dụng một phần:

session.upload_progress.enabled = Off
php_admin_flag[session.upload_progress.enabled] = off

Cấu hình này giảm bớt đường khai thác của CVE-2026-109619 nhưng không bảo vệ trọn vẹn trước lỗi nào. Với CVE-2026-109618, PHP khuyên thêm các bước về memory_limit, giới hạn kích thước request multipart và cách ly bộ nhớ ở mức hệ điều hành. Gỡ giới hạn bộ nhớ mà không có ranh giới khác thì lại mở ra nguy cơ từ chối dịch vụ.

Không có cách khắc phục trọn vẹn nào ngoài việc vá.

Node.js: giải nén một gói tin cũng có thể thành lỗ hổng

Ngày 21/10, Node.js phát hành bản cập nhật bảo mật xử lý mười lỗ hổng trên các nhánh. Bốn lỗi mức cao đáng chú ý nhất:

• CVE-2026-111497 – Brotli. Lỗi ghi bộ nhớ ra ngoài vùng cho phép trong bộ giải nén Brotli, có thể dẫn tới thực thi mã. Đáng lo với ứng dụng giải nén dữ liệu Brotli từ nguồn không tin cậy.
• CVE-2026-105482 – DNS. dns.resolve() có thể xử lý sai hostname chứa ký tự NUL, từ đó vượt qua bước kiểm tra hostname.
• CVE-2026-105483 – TLS hostname. Địa chỉ IP viết dạng không chuẩn với chữ số full-width làm rối việc so khớp hostname với chứng chỉ. Ảnh hưởng Node.js 24.x và 26.x, 22.x không bị.
• CVE-2026-106069 – xác thực chứng chỉ TLS. Hostname không chuẩn có thể bị hiểu nhầm là địa chỉ IP. Ảnh hưởng 22.x, 24.x và 26.x.

Hai lỗi TLS giống như bảo vệ toà nhà kiểm tra thẻ ra vào: số "１２" viết bằng ký tự full-width nhìn thì y hệt "12", nhưng máy đọc lại thành thứ khác, và người không đúng danh tính vẫn lọt qua cửa.

node --version
nvm install 24.22.1
nvm use 24.22.1
docker exec <container-name> node --version

Image Docker thì đổi base, ví dụ FROM node:24.22.1. Trong lúc chờ vá: tránh giải nén Brotli từ dữ liệu không tin cậy nếu được, từ chối hostname dị dạng và IP viết không chuẩn trước khi đưa vào DNS/TLS, bắt buộc xác thực chứng chỉ chặt chẽ, không để dữ liệu người dùng quyết định đích kết nối mạng, và giới hạn kết nối ra ngoài.

PwnEscape: vá máy ảo thôi là chưa đủ

CVE-2026-99999, biệt danh PwnEscape, được công bố ngày 15/10/2026 với điểm CVSS 9.3. Nó ảnh hưởng tới nhân Linux, máy chủ KVM và có thể cả container.

Điều bất ngờ là lỗi không nằm trong KVM, mà trong ngăn xếp mạng IPv4 của nhân Linux. Việc kiểm tra sai siêu dữ liệu checksum offload có thể làm lộ bộ nhớ của máy chủ vật lý, gây crash, và có khả năng chạy mã với quyền root. Các nhà nghiên cứu đã trình diễn một cuộc thoát từ máy ảo khách sang máy chủ hoàn chỉnh trong môi trường thử nghiệm.

Nếu máy ảo là các căn hộ trong một toà chung cư, PwnEscape là lối đi bí mật từ một căn hộ xuống phòng kỹ thuật của toà nhà. Khoá cửa từng căn hộ cũng không bịt được lối đó, phải sửa chính toà nhà.

Ưu tiên cao nhất: máy chủ KVM nhiều khách thuê, nhà cung cấp VPS, CI/CD runner, hạ tầng cloud và mọi hệ thống chạy workload không tin cậy.

AlmaLinux đã có nhân vá, nhưng tại thời điểm bài gốc rà soát (22/10) vẫn nằm trong kho testing: AlmaLinux 8 là 4.18.0-553.174.2.el8_10, AlmaLinux 9 là 5.14.0-687.57.2.el9_8, AlmaLinux 10 là 6.12.0-211.66.2.el10_2. Nên thử trên môi trường kiểm thử trước, hoặc kiểm tra xem đã lên kho stable chưa.

uname -r
sudo dnf upgrade --refresh 'kernel*'
# Nếu cần dùng bản trong kho testing của AlmaLinux
sudo dnf install -y almalinux-release-testing
sudo dnf upgrade 'kernel*' --enablerepo=almalinux-testing

Cập nhật nhân cần khởi động lại, trừ khi có livepatch đã được kiểm chứng. Hãy live-migrate hoặc tắt máy ảo trước.

Hai biện pháp giảm thiểu một phần, chưa được xác nhận là đủ:

• Với máy ảo KVM dùng virtio, tắt checksum offload trong XML domain của libvirt (csum='off' gso='off' tso4='off' tso6='off' phía host, csum='off' tso4='off' tso6='off' phía guest). Cần khởi động lại guest và có thể giảm hiệu năng.
• Với người dùng cục bộ hoặc container không tin cậy, sudo sysctl -w user.max_user_namespaces=0 có thể chặn bớt một số đường khai thác. Cách này không chống được máy ảo khách độc hại và có thể làm hỏng rootless container cũng như sandbox.

Cài xong bản vá rồi, sao vẫn chưa yên tâm được?

Đây là phần nhiều đội hay bỏ qua nhất. Bài gốc chốt một câu đáng dán lên màn hình: Helm upgrade chạy thành công không chứng minh được container image có lỗi đã thật sự bị thay thế.

Trên Kubernetes và Docker, hãy kiểm tra binary đang chạy thật, không chỉ nhìn số phiên bản trong file cấu hình:

kubectl -n <namespace> exec <pod> -c <container> -- php -v
kubectl -n <namespace> exec <pod> -c <container> -- node -v
kubectl -n <namespace> rollout status deployment/<deployment-name>
kubectl -n <namespace> get pods -o wide

Nếu dùng tag có thể thay đổi (kiểu latest), xác nhận digest của image đã đổi. Có thể liệt kê toàn bộ image trong cụm bằng kubectl get pods -A rồi lọc theo gitlab|argocd|php|node.

Quan trọng hơn: vá lỗi không xoá được quyền truy cập kẻ tấn công đã có. Với hệ thống từng mở ra Internet trong lúc còn lỗi, hãy rà:

Nếu có dấu hiệu: cô lập thành phần bị ảnh hưởng, giữ nguyên bằng chứng, xoay vòng (rotate) các credential có thể đã lộ từ một môi trường tin cậy, và dựng lại từ image tin cậy khi xác nhận bị xâm nhập.

Nâng cấp gói phần mềm không phải là khôi phục sau sự cố.

Quy trình bài gốc lặp đi lặp lại cho mọi thành phần có thể tóm thành checklist:

• [ ]Xác định thành phần nào đang bị phơi bày
• [ ]Áp dụng bản vá đã kiểm chứng
• [ ]Khởi động lại dịch vụ, triển khai lại hoặc reboot
• [ ]Kiểm tra phiên bản đang chạy thật sự
• [ ]Điều tra dấu hiệu bị xâm nhập

Theo TechPipe, một bản cập nhật bảo mật trên production chỉ thật sự xong khi đoạn code có lỗi không còn chạy ở bất cứ đâu.

Tóm tắt nhanh

• P0 (làm ngay): GitLab CVE-2026-110264 (CVSS 10.0), PHP2Shell CVE-2026-109618/109619, nhân Linux PwnEscape CVE-2026-99999.
• P1: ba lỗi Argo CD CVSS 9.9 (vá từ 6/10) và bốn lỗi mức cao của Node.js về Brotli, DNS, TLS.
• Bẫy phiên bản: GitLab 19.4.2, 19.3.5, 19.2.8 chưa vá lỗi mới; PwnEscape phải vá trên host, không phải trong máy ảo.
• Giảm thiểu tạm chỉ mua thêm thời gian, không thay được bản vá.
• Vá xong phải kiểm tra binary đang chạy, rồi rà dấu hiệu xâm nhập và xoay vòng credential nếu cần.

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

Tôi đã nâng GitLab lên 19.4.2 tuần trước, vậy đã an toàn chưa?

Chưa. Bản 19.4.2 (cùng 19.3.5 và 19.2.8) chỉ vá lỗi CVE-2026-97229 trước đó. Với nhánh 19.4.x, bạn cần tối thiểu 19.4.3 để vá CVE-2026-110264.

Tôi chỉ cho người khác quyền xem trên Argo CD thì có sao không?

Có. Lỗi CVE-2026-113708 chỉ cần quyền "Application get" trên một Application có sẵn để gọi API tải manifest. Trên phiên bản bị ảnh hưởng, tài khoản chỉ đọc không được coi là vô hại.

Tắt session.upload_progress có đủ để chống PHP2Shell không?

Không. Cấu hình này chỉ giảm bớt một số đường khai thác của CVE-2026-109619 và không bảo vệ trọn vẹn trước lỗi nào. Theo khuyến cáo của PHP, cách khắc phục đầy đủ duy nhất là vá lên bản 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35 tuỳ nhánh.

Tôi thuê VPS, có cần tự làm gì với PwnEscape không?

Lỗi nằm ở nhân Linux của máy chủ ảo hoá, nên bản vá quan trọng nhất phải do nhà cung cấp áp dụng trên host. Bài gốc nhấn mạnh rằng chỉ vá máy ảo không sửa được PwnEscape. Nếu bạn tự vận hành host KVM, CI/CD runner hay hạ tầng chạy workload không tin cậy thì đó là nhóm cần ưu tiên cao nhất.