AI Gateway của GitLab cho phép một cấu hình Flow được dàn dựng có chủ đích thoát khỏi Prompt Sandbox của nó

Vào ngày 2 tháng 10 năm 2026, GitLab đã công bố một bản phát hành bản vá nghiêm trọng cho AI Gateway của mình — phần middleware truyền các yêu cầu giữa một phiên bản GitLab và các mô hình ngôn ngữ mà các tính năng Duo của nó gọi tới — đặt tên cho CVE-2026-90970 và đánh giá nó 9,9 trên 10. Theo lời của chính GitLab, lỗ hổng này có thể đã cho phép "một người dùng đã xác thực có quyền truy cập Duo Agent Platform thoát khỏi hộp cát mẫu prompt thông qua một cấu hình luồng được tạo đặc biệt, dẫn đến thực thi lệnh tùy ý trên AI Gateway." Chỉ những tổ chức đang vận hành AI Gateway tự lưu trữ mới cần hành động: GitLab đã sửa các gateway mà mình vận hành cho GitLab.com, GitLab Dedicated và các khách hàng tự quản lý sử dụng gateway do GitLab lưu trữ, và đã nói rõ điều đó trong khuyến cáo. Thông báo của GitLab không nói rằng lỗ hổng này đã từng bị khai thác, và đánh giá do Cơ quan An ninh mạng và Cơ sở hạ tầng Hoa Kỳ đính kèm vào hồ sơ CVE cùng ngày liệt kê khai thác là "không". Công lao phát hiện được ghi nhận cho nhà nghiên cứu HackerOne được biết đến với tên invisiblemeerkat. Khuyến cáo của GitLab, hồ sơ NVD và các bài đưa tin sau đó nhất quán với nhau về việc lỗ hổng là gì và những phiên bản nào chứa nó; chúng cũng nhất quán tương tự về những gì chưa được biết, cụ thể là liệu có ai từng sử dụng nó hay không. Hồ sơ này nằm cùng với các lỗ hổng cơ sở hạ tầng agent đã được ghi nhận khác trong kho lưu trữ sự cố AI, nơi mỗi mục mang theo nguồn, mức độ nghiêm trọng, mức độ tin cậy và cờ tranh chấp của riêng nó.

Điều mà bản khuyến cáo thực sự nói, và điều mà nó bỏ sót

Bản tư vấn bảo mật rất ngắn. Được đăng trên trang tài liệu của GitLab với tiêu đề “GitLab AI Gateway Critical Patch Release: 19.2.4, 19.3.2 và 19.4.1”, bản tư vấn liệt kê một bản vá bảo mật, có tiêu đề “Improper Neutralization issue in custom flow prompt template impacts AI Gateway” và được đánh dấu Nghiêm trọng. Bản tư vấn đưa ra vector CVSS 3.1 là AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — có thể truy cập qua mạng, độ phức tạp tấn công thấp, yêu cầu đặc quyền thấp, không cần tương tác của người dùng, phạm vi bị thay đổi và tác động cao đến tính bảo mật, tính toàn vẹn và tính sẵn sàng. Vector đó đáng để đọc vì nó mô tả chính xác kẻ tấn công: đặc quyền thấp, nhưng vẫn là đặc quyền. Bản tư vấn nêu “một người dùng đã xác thực có quyền truy cập Duo Agent Platform” và dừng ở đó. Bản tư vấn không nêu tên vai trò, quyền cụ thể hoặc các điều kiện mà cụm từ “trong những điều kiện nhất định” của chính bản tư vấn đề cập.

Nó không công bố bản chứng minh khái niệm, không mô tả cấu hình luồng được dựng có chủ đích và không đưa ra biện pháp thay thế cho các cổng kết nối không thể cập nhật ngay lập tức. The Hacker News, trong báo cáo ngày 2 tháng 10, ghi nhận những thiếu sót tương tự và bổ sung một điểm quan trọng về mặt vận hành: bản khuyến nghị không đưa ra cách nào để kiểm tra liệu một cổng kết nối có bị tấn công trước khi nó được vá hay không. Security Affairs, viết vào ngày hôm sau, ghi nhận những khoảng trống thông tin tương tự.

Mục nhập liệt kê điểm yếu phổ biến gắn với CVE là CWE-1336, việc vô hiệu hóa không đúng các phần tử đặc biệt được sử dụng trong một template engine. Khuyến nghị của GitLab không hề dùng từ Jinja. Tài liệu trong chính kho lưu trữ của AI Gateway thì có: tài liệu prompt-registry của nó mô tả các tệp cấu hình prompt "hỗ trợ biểu thức Jinja cho nhiều vai trò như người dùng và hệ thống", và mô tả một lớp Prompt "sử dụng Jinja để nội suy các mẫu prompt với các đối số đầu vào". Lỗ hổng mà CVE mô tả chính là loại lỗi mà nhóm công cụ đó nổi tiếng — văn bản do người dùng cung cấp đi đến một mẫu được đánh giá thay vì được in ra.

Vì sao một lệnh trên máy chủ cụ thể này lại đáng giá 9.9

AI Gateway không phải là một sidecar. Theo tài liệu tự lưu trữ của GitLab, nó nhận yêu cầu từ GitLab, lắp ghép các prompt và giao tiếp với backend mô hình — một máy chủ vLLM, Amazon Bedrock, Azure OpenAI hoặc một nhà cung cấp bên ngoài — và trong một triển khai hoàn toàn tự lưu trữ, nó là thành phần giữ các prompt và phản hồi bên trong mạng của chính tổ chức. Hướng dẫn cài đặt AI Gateway của GitLab cũng cho biết quản trị viên cần tạo một cặp khóa ký và truyền hai nửa cho dịch vụ dưới dạng biến môi trường, là AIGW_SELF_SIGNED_JWT__SIGNING_KEY và AIGW_SELF_SIGNED_JWT__VALIDATION_KEY (với các tương đương cho Duo Workflow). Security Affairs nêu rõ hậu quả: thực thi lệnh trên gateway đưa kẻ tấn công vào một máy chủ nắm giữ tư liệu ký JWT và nằm trên đường đi giữa phiên bản GitLab và hạ tầng mô hình.

Đó chính là sự khác biệt giữa một vụ thoát sandbox trong một công cụ đồ chơi và một vụ thoát sandbox trong môi trường production. Cuộc thoát hiểm không cần phải chạm tới một mô hình; nó cần chạm tới tiến trình đang giữ những chiếc khóa mà các lệnh gọi mô hình được ký bằng.

Tài liệu sản phẩm của GitLab, tách biệt với bản khuyến nghị, nêu rõ rằng việc tạo hoặc chỉnh sửa một luồng tùy chỉnh yêu cầu vai trò Maintainer hoặc Owner trong dự án quản lý, và việc chạy một luồng như vậy yêu cầu vai trò Developer trở lên. Bản khuyến nghị không xác nhận sự ánh xạ đó, và The Hacker News lưu ý rằng không có vai trò nào được nêu tên ngoài "Duo Agent Platform access". Người đọc đang ước tính mức độ phơi nhiễm của chính mình nên coi tài liệu là mô hình quyền của sản phẩm và sự im lặng của bản khuyến nghị đúng như bản chất của nó: im lặng, chứ không phải mâu thuẫn.

Đã thiết lập, và chưa thiết lập

Các trường của chính bản ghi đều nhất quán với mọi điều ở trên và không bổ sung gì không có trong bản khuyến cáo. Phần tiếp theo là sự phân tách mà người đọc không thể có được từ một bản tóm tắt một dòng.

• Đã xác định: một lỗ hổng có mức độ nghiêm trọng tới hạn trong GitLab AI Gateway, được công bố ngày 2 tháng 10 năm 2026, CVSS 9.9, CWE-1336, có thể bị một người dùng Duo Agent Platform đã xác thực truy cập thông qua cấu hình luồng được thiết kế đặc biệt, dẫn đến thực thi lệnh trên máy chủ gateway.

• Đã xác định: phạm vi bị ảnh hưởng — tất cả các phiên bản AI Gateway từ 18.1.6 trước 19.2.4, 19.3 trước 19.3.2 và 19.4 trước 19.4.1 — và các phiên bản đã khắc phục, 19.2.4, 19.3.2 và 19.4.1.

• Đã xác lập:Các cổng do GitLab lưu trữ đã được vá trước khi công bố và khách hàng của họ không cần thực hiện hành động nào; những người vận hành tự lưu trữ đã được liên hệ trực tiếp trước bài đăng phát hành, điều mà chính GitLab nêu trong bản khuyến cáo.

• Đã xác lập: ghi công cho người báo cáo, invisiblemeerkat, và việc không có bất kỳ tuyên bố nào về khai thác trong tự nhiên.

• Chưa xác định: liệu có ai đã khai thác nó hay chưa. Đánh giá SSVC của CISA đề ngày 2 tháng 10 năm 2026 và hiển thị trong bản ghi NVD ghi khả năng khai thác là “none”, khả năng tự động hóa là “no” và tác động kỹ thuật là “total”; danh mục Known Exploited Vulnerabilities của CISA không liệt kê CVE-2026-90970 trong bản sửa đổi ngày 20 tháng 10 năm 2026, mà tôi đã trực tiếp kiểm tra. Mô hình EPSS của FIRST đặt xác suất bị khai thác trong 30 ngày tới ở mức 0,94 phần trăm vào ngày 21 tháng 10 năm 2026 — thấp, và không phải bằng không.

• Chưa xác định: có bao nhiêu gateway tự triển khai tồn tại, bao nhiêu gateway đã bị phơi lộ, hoặc liệu có gateway nào bị tấn công trước khi vá hay không. Không có nguồn nào trong hồ sơ này đưa ra số lượng, và khuyến cáo của GitLab không cung cấp phương pháp phát hiện.

Phạm vi bị ảnh hưởng và các phiên bản không có bản sửa lỗi nào được liệt kê

Cách tính phiên bản không gọn gàng như ba bản phát hành đã sửa gợi ý. Phạm vi bị ảnh hưởng bắt đầu từ 18.1.6, và không có bản phát hành đã sửa nào được công bố trên bất kỳ nhánh nào dưới 19.2.4. Do đó, mọi gateway từ 18.1.6 đến dòng 19.1 đều nằm trong phạm vi bị ảnh hưởng đã nêu mà không có phiên bản vá nào được nêu tên cho chúng. The Hacker News nêu bật hệ quả tương tự và những câu hỏi kéo theo: tài liệu cài đặt của GitLab hướng dẫn quản trị viên chạy image gateway có phiên bản khớp với phiên bản phụ GitLab của họ, và bản khuyến cáo không cho biết liệu gateway 19.2.4 có hoạt động với GitLab 19.1 hoặc sớm hơn hay không, cũng như liệu có kế hoạch sửa lỗi cho các dòng cũ hơn hay không. Chính sách phiên bản được hỗ trợ của GitLab, như The Hacker News lưu ý, hiện liệt kê 19.4, 19.3 và 19.2 — đúng ba dòng đã nhận được bản sửa.

Biện pháp khắc phục là thay thế container chứ không phải vá: gateway được phát hành dưới dạng Docker image hoặc Helm chart riêng. Hướng dẫn cài đặt của GitLab mô tả việc dừng và xóa container đang chạy, kéo image mới với tag self-hosted-vX.Y.Z-ee, rồi khởi động lại nó với các biến môi trường còn nguyên vẹn; các triển khai Helm đặt tag trong trường image của chart. Cả bản khuyến nghị lẫn hướng dẫn cài đặt đều không cung cấp chữ ký hay chỉ dấu nào để phân biệt một gateway đã bị tấn công với một gateway sạch.

Cùng lớp lỗi, sớm hơn tám tháng

Đây không phải lần đầu tiên GitLab công bố mức điểm 9.9 cho lỗ hổng chèn mẫu trong AI Gateway. Vào ngày 6 tháng 2 năm 2026, họ đã phát hành AI Gateway 18.6.2, 18.7.1 và 18.8.1 cho CVE-2026-1868, được mô tả trong khuyến nghị bảo mật đó là “vấn đề mở rộng mẫu không an toàn” (Insecure Template expansion issue), trong đó thành phần Duo Workflow Service “dễ bị ảnh hưởng bởi việc mở rộng mẫu không an toàn dữ liệu do người dùng cung cấp thông qua các định nghĩa Duo Agent Platform Flow được tạo dựng tinh vi”, có thể bị lợi dụng để gây từ chối dịch vụ hoặc thực thi mã trên gateway. Véctơ CVSS giống hệt véctơ của tháng 10, đến từng ký tự, và CWE cũng vậy. Người báo cáo thì khác: lỗ hổng đó được phát hiện nội bộ, bởi thành viên nhóm GitLab Joern Schneeweisz.

Bản khuyến cáo tháng Mười không đề cập đến bản tháng Hai, và The Hacker News nói rõ như vậy. Liệu hai bản có chung nguyên nhân gốc, cùng gặp phải một bản vá không phát huy tác dụng, hay chỉ đơn thuần chia sẻ một ngôn ngữ và một mô hình mối đe dọa, thì không tài liệu công khai nào trong hai tài liệu trả lời. Điều được ghi nhận là một template engine trong một thành phần middleware AI giờ đã tạo ra hai khuyến cáo bảo mật nghiêm trọng về thực thi lệnh với cùng mức điểm trong cùng một năm, và rằng bản thứ hai cần một nhà nghiên cứu bên ngoài mới phát hiện ra.

Điều gì đã thay đổi và những gì còn lại để các nhà vận hành quyết định

Thay đổi cụ thể là ba thẻ image và một đợt liên hệ trực tiếp. GitLab cho biết đã liên hệ với khách hàng dùng gateway tự vận hành trước khi công bố, và bản khuyến cáo được phát hành cùng với các image đã sửa trong cùng ngày. Đối với tất cả những trường hợp còn lại — GitLab.com, GitLab Dedicated và các instance tự quản lý trỏ tới gateway do GitLab vận hành — bản sửa đã được áp dụng ở phía máy chủ và, theo phía GitLab, không cần làm gì thêm.

Đối với người vận hành tự lưu trữ, quyết định này hẹp hơn và kém dễ chịu hơn so với một chu kỳ vá thông thường. Không có cách xử lý tạm thời nào cho một gateway không thể được di chuyển ngay lập tức. Không có phương pháp nào đã được phát hành để xác định liệu máy chủ đã bị xâm phạm từ trước hay không, nghĩa là lựa chọn hồi cứu duy nhất là lựa chọn thông thường: coi container là một hệ thống có tính toàn vẹn chưa được chứng minh, và tìm kiếm các dấu hiệu thực thi nằm ngoài hành vi bình thường của nó. Và đối với các gateway trên 18.x hoặc 19.1, bản khuyến cáo không nêu tên bất kỳ phiên bản đích nào cả — một thiếu sót mà The Hacker News đưa tin và thông báo của GitLab không đề cập đến.

Cách phân loại của chính kho lưu trữ được cố ý thu hẹp hơn so với nhà cung cấp. Kho lưu trữ ghi mục này là một lỗ hổng, ở mức tin cậy A với các nguồn đồng thuận, không bị tranh cãi, không ghi nhận thiệt hại thực tế, và với trường mức độ nghiêm trọng là "high" so với mức "critical" của GitLab và NVD. Đó là câu trả lời cho những câu hỏi khác nhau: điểm số mô tả lỗ hổng sẽ cho phép điều gì, còn xếp hạng của kho lưu trữ mô tả điều được biết là đã xảy ra. Theo hồ sơ công khai, không có gì xảy ra — không bị khai thác, không có nạn nhân, không có báo cáo sự cố. Giá trị của mục này là nó ghi lại, với một số CVE và một phiên bản đã sửa, chính xác cách một mẫu prompt trở thành một dòng lệnh trong phần mềm trung gian mà các tính năng AI doanh nghiệp phụ thuộc vào.