Tuần lễ bảo mật tồi tệ: PHP2Shell, LiteLLM và GitLab — và câu hỏi khó nhất không phải là vá lỗi

Tuần qua, hàng loạt thành phần hạ tầng phổ biến đồng loạt phát hành cảnh báo bảo mật: từ runtime PHP, Node.js cho tới GitLab tự vận hành, cổng AI LiteLLM và cả tổ chức chứng thực eMudhra. Điểm đáng chú ý là hầu hết các lỗi đều nghiêm trọng, một số đã bị khai thác trước khi có bản vá. Nhưng bài học lớn nhất lại nằm ở khâu khác: biết chính xác hệ thống nào của mình đang bị ảnh hưởng.

Minh họa tuần lễ sự cố bảo mật trên internet

Chuyện gì đã xảy ra trong tuần?

Giai đoạn từ 16 đến 23 tháng 10/2026 chứng kiến một loạt sự cố an ninh mạng nghiêm trọng trải đều trên nhiều tầng hạ tầng. PHP, Node.js và GitLab phát hành bản vá cùng ngày 21/10 — đúng hôm bản phát hành LiteLLM độc hại xuất hiện trên PyPI.

• PHP2Shell (CVE-2026-109618, CVE-2026-109619): hai lỗi thực thi mã từ xa trước khi xác thực, mỗi lỗi được chấm 9.2 điểm. Các nỗ lực khai thác đã xuất hiện trước khi lỗi được công bố.
• Node.js (CVE-2026-111497): lỗi ghi ngoài biên trong bộ giải mã Brotli tích hợp, có thể dẫn tới crash, rò rỉ bộ nhớ hoặc thực thi mã từ xa.
• GitLab (CVE-2026-110264): lỗi thực thi mã từ xa không cần xác thực, chấm CVSS 10.0, xuất phát từ tràn số nguyên trong trình biên dịch biểu thức chính quy. Lỗi tồn tại từ GitLab 7.0 phát hành năm 2014.
• LiteLLM 1.107.0: bản phát hành độc hại trên PyPI và trong image container chính thức, chạy trình đánh cắp thông tin xác thực mỗi khi Python khởi động.
• OpenCode Console: kẻ xâm nhập chạm tới một hệ thống cũ, khiến khoá API của các nhà cung cấp AI mà người dùng lưu trong Console có thể bị lộ. Một số người dùng báo bị tính phí trái phép.
• eMudhra: tám khoá riêng của chứng thực trung gian (intermediate CA) được sinh từ các số nguyên nhỏ hơn 256. Một trong số đó là số 4.

Không có mục nào trong danh sách trên là thứ hiếm gặp. Hai trong số đó là runtime mà phần lớn web đang chạy trên, một là máy chủ quản lý mã nguồn mà không ít công ty vẫn tự vận hành, và một là cổng AI mà nhiều đội ngũ vội vã áp dụng để điều phối lưu lượng LLM. Nếu bạn vận hành một hệ thống cỡ vừa trên AWS hay Azure, gần như chắc chắn có ít nhất một mục trong danh sách này là việc của bạn.

Cửa sổ khai thác ngày càng ngắn lại

Mandiant theo dõi thời gian kẻ tấn công cần để khai thác một lỗ hổng sau khi nó được công bố. Con số trung bình là 63 ngày giai đoạn 2018–2019, 44 ngày giai đoạn 2020–2021, 32 ngày giai đoạn 2021–2022. Đến năm 2023 chỉ còn 5 ngày, và 70% lỗ hổng bị khai thác mà Mandiant theo dõi năm đó là zero-day — bị khai thác trước cả khi bản vá tồn tại.

Theo phân tích của Drew Silcock trên Hacker News, các mô hình ngôn ngữ lớn đã nén khoảng thời gian này xuống hơn nữa: khoảng cách giữa lúc một lỗi thực thi mã từ xa nghiêm trọng được công khai và lúc các cuộc tấn công tự động ập tới giờ chỉ còn tính bằng giờ, thay vì hàng tuần.

PHP2Shell là ví dụ điển hình. Lỗi được tìm ra với sự hỗ trợ của một mô hình AI, bản vá xuất hiện trước cả bản tin cảnh báo sau một tranh chấp về embargo, và các nỗ lực khai thác bắt đầu trước khi phần lớn người dùng kịp cài bản vá.

Cửa sổ phơi nhiễm của bạn bằng thời gian tìm ra hệ thống bị ảnh hưởng cộng với thời gian khắc phục. Các đội ngũ đã dành nhiều năm để rút ngắn số thứ hai bằng CI/CD, runtime được quản lý và vá tự động. Còn số thứ nhất vẫn là… một bảng tính, một chuỗi tin nhắn trên Slack, và người còn nhớ chiếc máy chủ GitLab cũ được dựng lên thế nào.

Đây là lý do các khung tiêu chuẩn đặt kiểm kê tài sản lên đầu. CIS Controls xếp "kiểm kê tài sản doanh nghiệp" và "kiểm kê phần mềm" vào Control 1 và 2; quản lý lỗ hổng chỉ xuất hiện ở Control 7. Chỉ thị BOD 23-01 của CISA yêu cầu các cơ quan liên bang Mỹ chạy quét tài sản tự động mỗi 7 ngày và liệt kê lỗ hổng mỗi 14 ngày. Nếu bạn không biết một máy chủ tồn tại, bạn sẽ không vá nó.

Bốn câu hỏi cần trả lời trước khi vá

Quy trình xử lý thực chất có thể gói gọn trong bốn câu hỏi, và công cụ gốc của AWS/Azure trả lời được phần nào.

1. Thành phần bị ảnh hưởng chạy ở đâu?

Với Node.js trên Lambda, các runtime được quản lý và còn hỗ trợ sẽ tự động nhận bản cập nhật — trừ hai nhóm: các hàm dùng runtime nodejs20.x đã hết vòng đời (mất bản vá từ tháng 4/2026), và các hàm đóng gói dưới dạng container image mang theo phiên bản Node.js nướng sẵn trong image.

Trên Azure, App Service ghi lại runtime stack của từng ứng dụng Linux, và Azure Resource Graph có thể truy vấn trên mọi subscription mà bạn có quyền đọc.

Máy ảo và container thì khó hơn, vì lớp điều khiển của cloud không biết bên trong cài gì. Đó là đất diễn của AWS Systems Manager Inventory, Amazon Inspector và Microsoft Defender for Cloud — và mỗi công cụ chỉ thấy những máy đã được bật. Khoảng trống phủ sóng này chính là chỗ đau nhất.

2. Internet có chạm tới được không?

GitLab đã tự vá GitLab.com. Các instance tự vận hành là trách nhiệm của bạn, và ngoài việc nâng cấp thì không có cách né nào khác. Điều đáng lo thường không phải chiếc GitLab mà đội platform quản lý, mà là chiếc ai đó dựng năm 2019, hoặc chiếc đi kèm một thương vụ mua lại, vẫn đang trả lời trên cổng 443.

Cảnh báo: lọc theo tên chỉ tìm được những máy chủ mà ai đó đã đặt tên thật thà, còn một instance không có IP công khai vẫn có thể truy cập qua load balancer công khai. Cả hai điều này khiến việc trả lời câu hỏi trên console giữa lúc sự cố trở nên rất vất vả.

3. Ai là người quản lý?

Tìm được máy chủ rồi, vẫn cần ai đó duyệt thời gian ngừng hoạt động — và lý tưởng nhất là người biết nó được cài đặt thế nào. Tag là nơi tra đầu tiên. Nếu không có tag, CloudTrail có thể cho biết ai đã tạo tài nguyên, nhưng lịch sử sự kiện chỉ lưu 90 ngày. Với một máy chủ từ năm 2019, bạn cần trail trên S3 và truy vấn Athena.

Trong một trường hợp được ghi nhận, 89 máy ảo Azure nhàn rỗi đến từ một thương vụ mua lại và không ai trong đội hiện tại biết chúng dùng để làm gì. Những tài nguyên kiểu đó chính là nơi một chiếc GitLab chưa vá trú ngụ.

4. Nó có thể truy cập được những gì?

LiteLLM cho thấy vì sao phát hiện một gói phần mềm độc hại chỉ là khởi đầu. Theo phân tích của Microsoft, bản phát hành độc hại nhắm vào cache thông tin xác thực của AWS, Azure và Google Cloud, tệp service-account của Kubernetes, cấu hình Docker và các secret được mount. Nó còn cố lấy thông tin xác thực từ metadata service của AWS và GCP, và trên máy chủ proxy thì đọc khoá nhà cung cấp từ chính cơ sở dữ liệu của LiteLLM.

Gói độc hại là thứ scanner báo cáo. Thứ bạn thực sự phải xử lý là danh tính mà máy chủ đã chạy dưới quyền đó. Với mỗi môi trường đã cài 1.107.0, hãy tìm role của nó và những gì role đó được phép làm.

Bài kiểm tra một giờ đồng hồ

Chọn một trong các bản tin cảnh báo tuần này và bấm giờ xem đội của bạn mất bao lâu để:

• Liệt kê mọi nơi Node.js và PHP đang chạy, gồm runtime Lambda, stack App Service, container image và máy ảo.
• Tìm mọi chiếc GitLab tự vận hành (và các công cụ phát triển tự host khác), kiểm tra xem internet có chạm tới được không.
• Ghi tên người quản lý bên cạnh từng mục.
• Với mỗi môi trường đã cài LiteLLM 1.107.0, liệt kê các role nó chạy và xoay vòng mọi thứ mà các role đó chạm tới được.
• Ghi lại khoá API nhà cung cấp AI được lưu ở đâu và workload nào dùng chúng.
• Rà soát chứng thực xem có nhà phát hành eMudhra hoặc emSign nào không.

Nếu mất hơn một giờ, hãy chuẩn bị tinh thần rằng bản tin cảnh báo tiếp theo cũng sẽ tốn chừng ấy thời gian.

Kết luận cho đội ngũ tại Việt Nam

Với các doanh nghiệp Việt Nam đang chạy hệ thống trên AWS, Azure hay các cloud nội địa, bài học rất rõ ràng: đầu tư vào kiểm kê tài sản có gắn chủ sở hữu không phải là việc làm thêm cho đẹp báo cáo, mà là yếu tố quyết định tốc độ phản ứng khi có sự cố. Các lỗi như GitLab CVSS 10.0 hay PHP2Shell với điểm 9.2 không chừa ai — và khoảng thời gian từ lúc công bố tới lúc bị khai thác đang co lại còn tính bằng giờ.

Ba việc nên làm ngay: rà lại toàn bộ máy chủ tự vận hành đang mở ra internet, xoay vòng mọi thông tin xác thực từng nằm trong môi trường nghi ngờ nhiễm độc, và dựng một bản kiểm kê tài sản đủ tin cậy trước khi bản tin cảnh báo tiếp theo ập tới.