Bạn có bao giờ nghĩ rằng chỉ cần một người dùng đã đăng nhập, với quyền truy cập vào tính năng AI, cũng có thể chiếm quyền điều khiển toàn bộ máy chủ GitLab của doanh nghiệp bạn? Nghe có vẻ như kịch bản trong một bộ phim về tin tặc, nhưng đó chính xác là những gì đang diễn ra ngay lúc này.
GitLab vừa phát hành bản vá khẩn cấp cho một lỗ hổng cực kỳ nghiêm trọng trong AI Gateway – thành phần kết nối GitLab với các mô hình AI. Lỗ hổng này được đánh giá với mức độ nghiêm trọng lên tới 9.9/10 theo thang điểm CVSS, gần như là mức cao nhất có thể.
Và điều đáng lo ngại hơn cả là: lỗ hổng này chỉ ảnh hưởng đến những tổ chức tự vận hành AI Gateway – tức là những doanh nghiệp muốn giữ dữ liệu AI trong môi trường của riêng mình. Chính vì muốn an toàn hơn, họ lại đang đối mặt với rủi ro lớn hơn.
Hãy cùng tôi, SilverZ, với 20 năm chứng kiến không ít lần các lỗ hổng bảo mật khiến cả ngành công nghệ phải "toát mồ hôi", phân tích sự việc này từ gốc rễ. Bởi vì nếu bạn đang vận hành GitLab trong doanh nghiệp của mình, đây không còn là tin tức xa lạ nữa.
Lỗ hổng CVE-2026-90970 là gì và nguy hiểm đến mức nào?
Trước khi đi vào chi tiết, hãy cùng tôi làm rõ bản chất của sự việc. Lỗ hổng được theo dõi với mã CVE-2026-90970, được GitLab công bố vào ngày 2 tháng 10 năm 2026 và xếp hạng critical với điểm CVSS 9.9 trên 10.
Vậy điều gì khiến lỗ hổng này nguy hiểm đến vậy? Hãy tưởng tượng AI Gateway như một cánh cổng kết nối giữa GitLab của bạn và các mô hình AI. Cánh cổng này xử lý các yêu cầu, gửi chúng đến mô hình AI, và mang kết quả trở về. Nhưng nếu ai đó có thể phá vỡ cánh cổng đó, họ có thể thực thi lệnh trực tiếp trên máy chủ đang chạy gateway.
Theo mô tả, lỗ hổng nằm trong prompt template của một custom flow – một luồng công việc do AI điều khiển mà người dùng tạo trên Duo Agent Platform để tự động hóa các tác vụ nhiều bước. Một người dùng đã đăng nhập, có quyền truy cập vào Duo Agent Platform, có thể lợi dụng lỗ hổng này để "thoát khỏi sandbox của prompt template" thông qua một cấu hình flow được tạo đặc biệt.
Hậu quả là gì? Kẻ tấn công có thể thực thi lệnh tùy ý trên gateway. Điều này đồng nghĩa với việc họ có thể làm bất cứ điều gì mà một quản trị viên hệ thống có thể làm: đọc dữ liệu nhạy cảm, cài đặt phần mềm độc hại, hoặc tệ hơn là chiếm đoạt toàn bộ hệ thống.
Mối đe dọa tiềm ẩn: Khi khóa ký JWT bị đánh cắp
Điều khiến tôi đặc biệt lo lắng về lỗ hổng này không chỉ là khả năng thực thi lệnh, mà còn là những gì kẻ tấn công có thể đánh cắp được.
Một AI Gateway tự vận hành lưu trữ khóa ký cho JSON Web Tokens (JWT) – và theo hướng dẫn cài đặt của GitLab, những khóa này phải được đối xử như thông tin xác thực nhạy cảm. Nếu kẻ tấn công có được những khóa này, chúng có thể giả mạo token hợp lệ để truy cập vào GitLab instance, hoặc thậm chí là vào các nhà cung cấp mô hình AI mà tổ chức của bạn đang kết nối.
Hãy nghĩ về điều đó. Không chỉ dữ liệu nội bộ của bạn bị đe dọa, mà còn là mối quan hệ đối tác với các nhà cung cấp AI – những mối quan hệ được xây dựng dựa trên niềm tin và các thỏa thuận bảo mật nghiêm ngặt.
Ai bị ảnh hưởng và ai có thể yên tâm?
Đây là phần quan trọng nhất mà bất kỳ quản trị viên GitLab nào cũng cần nắm rõ. Không phải tất cả người dùng GitLab đều bị ảnh hưởng bởi lỗ hổng này.
Những tổ chức có thể yên tâm:
- Khách hàng sử dụng GitLab.com – gateway đã được GitLab vá tự động.
- Khách hàng sử dụng GitLab Dedicated – cũng đã được vá.
- Khách hàng tự quản lý nhưng sử dụng gateway do GitLab vận hành – không cần hành động.
Những tổ chức cần hành động ngay lập tức:
- Khách hàng tự quản lý (self-managed) tự vận hành AI Gateway của riêng mình.
GitLab đã gửi hướng dẫn cập nhật đến những khách hàng này trước khi công bố bản vá, một dấu hiệu cho thấy mức độ nghiêm trọng của vấn đề.
Các phiên bản bị ảnh hưởng và bản vá
Dưới đây là bảng tổng hợp các phiên bản AI Gateway bị ảnh hưởng và phiên bản đã được vá:
| Phiên bản đang sử dụng | Phiên bản đã vá |
|---|---|
| 18.1.6 trở lên, trước 19.2.4 | 19.2.4 |
| 19.3, trước 19.3.2 | 19.3.2 |
| 19.4, trước 19.4.1 | 19.4.1 |
Điều đáng chú ý là không có phiên bản vá nào được liệt kê cho các phiên bản dưới 19.2.4. Điều này có nghĩa là mọi phiên bản gateway từ 18.1.6 đến dòng 19.1 đều nằm trong vùng bị ảnh hưởng.
Hướng dẫn cài đặt của GitLab khuyến nghị quản trị viên sử dụng hình ảnh gateway phù hợp với phiên bản GitLab minor của họ. Tuy nhiên, tài liệu không nói rõ liệu gateway 19.2.4 có tương thích với GitLab 19.1 hoặc cũ hơn hay không, cũng như liệu có kế hoạch vá cho các dòng cũ hơn hay không.
Tính đến ngày 2 tháng 10, chính sách bảo trì của GitLab chỉ liệt kê các phiên bản 19.4, 19.3 và 19.2 là những phiên bản nhận được bản vá bảo mật. Đây cũng chính là ba dòng đã được vá gateway.
Cách cập nhật AI Gateway
Nếu bạn đang vận hành AI Gateway tự túc, đây là những gì bạn cần làm ngay:
Đối với triển khai Docker
Dừng và xóa container đang chạy, sau đó kéo và chạy image tag mới. Ví dụ: self-hosted-v19.4.1-ee.
Đối với triển khai Helm
Đặt tag mới trong phần cài đặt image của chart.
GitLab lưu ý rằng không có workaround nào được liệt kê cho các gateway không thể cập nhật ngay lập tức. Và điều đáng lo ngại hơn là không có cách nào để kiểm tra liệu gateway đã bị tấn công trước khi cập nhật hay chưa.
Liệu lỗ hổng đã bị khai thác chưa?
Đây có lẽ là câu hỏi mà bất kỳ quản trị viên nào cũng đang đặt ra. Tin tốt là: theo Cơ quan An ninh mạng và Cơ sở hạ tầng Hoa Kỳ (CISA), tình trạng khai thác hiện được đánh giá là "none" – tức là chưa có bằng chứng về việc lỗ hổng bị khai thác trong thực tế.
Tuy nhiên, điều này không có nghĩa là bạn có thể chủ quan. Lỗ hổng đã được công bố công khai, và như tôi vẫn thường nói với các học trò của mình: "Khi lỗ hổng được công bố, đó là lúc cuộc đua bắt đầu." Kẻ tấn công có thể đang âm thầm phát triển khai thác, và bạn không muốn trở thành người thử nghiệm đầu tiên.
Bối cảnh rộng hơn: Khi AI trở thành bề mặt tấn công mới
Sự cố này không phải là trường hợp cá biệt. Nó là một phần của xu hướng đáng lo ngại hơn: AI đang trở thành bề mặt tấn công mới.
Trước đây, tin tặc thường nhắm vào các lỗ hổng trong hệ điều hành, cơ sở dữ liệu, hoặc ứng dụng web. Nhưng khi các tổ chức ngày càng tích hợp AI vào quy trình làm việc, các thành phần AI như AI Gateway trở thành mục tiêu hấp dẫn. Chúng thường có quyền truy cập rộng rãi, xử lý dữ liệu nhạy cảm, và đôi khi được triển khai mà không được giám sát chặt chẽ như các hệ thống quan trọng khác.
Điều này đặt ra một câu hỏi lớn: Liệu các tổ chức có đang đầu tư đủ vào bảo mật AI? Hay họ đang quá tập trung vào việc triển khai AI nhanh chóng mà bỏ qua các rủi ro bảo mật đi kèm?
Bài học cho doanh nghiệp Việt Nam
Ngay cả khi bạn không sử dụng GitLab, sự cố này vẫn mang đến những bài học quý giá cho bất kỳ doanh nghiệp nào đang triển khai AI.
1. Kiểm kê tài sản AI của bạn
Bạn có biết mình đang chạy bao nhiêu thành phần AI? Chúng được triển khai ở đâu? Ai có quyền truy cập? Nếu bạn không thể trả lời những câu hỏi này, bạn đang quản lý rủi ro một cách mù quáng.
2. Ưu tiên vá lỗ hổng cho các thành phần AI
Các thành phần AI thường được xem là "phụ trợ" và ít được chú ý hơn so với cơ sở dữ liệu hay máy chủ web. Nhưng như sự cố này cho thấy, chúng có thể là cánh cửa dẫn đến toàn bộ hệ thống của bạn.
3. Giới hạn quyền truy cập vào Duo Agent Platform
Lỗ hổng này yêu cầu người dùng phải có quyền truy cập vào Duo Agent Platform. Hãy xem xét lại ai thực sự cần quyền này, và liệu bạn có thể giới hạn nó cho một nhóm nhỏ người dùng được tin cậy hay không.
4. Không có giải pháp thay thế cho việc cập nhật
GitLab không cung cấp workaround cho lỗ hổng này. Điều đó có nghĩa là cập nhật là lựa chọn duy nhất. Đừng trì hoãn.
An toàn AI không phải là đích đến, mà là hành trình
Tôi đã chứng kiến ngành công nghệ trải qua không ít cuộc khủng hoảng bảo mật. Từ những lỗ hổng trong các thư viện phổ biến, đến các cuộc tấn công chuỗi cung ứng, và giờ là các lỗ hổng trong hạ tầng AI. Mỗi lần như vậy, tôi lại thấy cùng một bài học được lặp lại: những gì chúng ta xây dựng để kết nối và đổi mới cũng chính là những gì chúng ta cần bảo vệ.
AI Gateway là một thành phần tuyệt vời. Nó cho phép doanh nghiệp giữ dữ liệu AI trong môi trường của riêng mình, kiểm soát nhiều hơn, và tuân thủ các quy định nghiêm ngặt. Nhưng chính vì nó mạnh mẽ, nó cũng trở thành mục tiêu hấp dẫn.
Lỗ hổng CVE-2026-90970 không phải là dấu chấm hết cho GitLab hay AI Gateway. Nó là một lời nhắc nhở rằng trong kỷ nguyên AI, bảo mật không thể là một suy nghĩ sau cùng. Nó phải là một phần của mọi quyết định kiến trúc, mọi quy trình triển khai, và mọi kế hoạch vận hành.
Và như tôi vẫn thường nói: "Công nghệ càng thông minh, càng cần những người sử dụng nó một cách khôn ngoan."
Nếu doanh nghiệp của bạn đang vận hành AI Gateway tự túc, bạn sẽ xử lý lỗ hổng này như thế nào – cập nhật ngay lập tức dù có thể gây gián đoạn, hay chờ đợi một khung thời gian bảo trì an toàn hơn? Và quan trọng hơn, bạn có nghĩ rằng các tổ chức đang dành đủ nguồn lực để bảo vệ hạ tầng AI của mình, hay đang quá tập trung vào việc triển khai nhanh mà bỏ qua rủi ro bảo mật? Hãy chia sẻ quan điểm của bạn bên dưới, bởi vì trong kỷ nguyên AI, an toàn không còn là lựa chọn – đó là trách nhiệm!
0 Comment
Add your comment to this article