Lỗ hổng RCE trong AI Agent của Zammad: một thẻ mẫu lồng nhau, một bản sửa chỉ một chữ cái

Zammad, helpdesk mã nguồn mở, đã phát hành phiên bản 7.1.2 vào ngày 4 tháng 8 năm 2026 với mười tám bản sửa lỗi bảo mật; bản đầu tiên trong danh sách vá một lỗ hổng thực thi mã từ xa trong các trường cấu hình của tính năng AI Agent. Lỗ hổng là CVE-2026-84462, được công bố trong tư vấn GitHub GHSA-gp3x-9xm8-rcj6 cùng ngày, và phạm vi bị ảnh hưởng là mọi bản cài đặt tự vận hành trên phiên bản 7.1.1 trở xuống, bao gồm 7.1.1. Một quản trị viên có thể tạo hoặc chỉnh sửa AI Agent có thể nhập văn bản được tạo đặc biệt vào một trong các trường của agent, vượt qua bộ lọc nhằm vô hiệu hóa nó, và chạy các lệnh tùy ý trên máy chủ lưu trữ Zammad — với khả năng, theo lời của tư vấn, là “đọc, sửa đổi hoặc phá hủy toàn bộ dữ liệu được lưu trữ trên máy chủ đó.” Không cần người dùng nào khác thực hiện hành động nào: tư vấn nêu rằng “mã độc sẽ tự động chạy vào lần tiếp theo mà AI Agent bị ảnh hưởng xử lý một phiếu hỗ trợ.” GitHub đánh giá mức Cao với điểm 8.6 theo CVSS 4.0. Hồ sơ, các thẻ mức độ nghiêm trọng và tác hại của nó, cùng những mục được lập xung quanh nó, được lưu giữ trong the Orca AI Incident Archive, nơi liệt kê sự cố này cùng với phần còn lại của loạt.

Những gì khuyến cáo này xác lập

Bản tư vấn bảo mật của GitHub, được công bố ngày 4 tháng 8 năm 2026, ngắn gọn và đặc biệt cụ thể về cơ chế cùng các điều kiện tiên quyết. Bản tư vấn mô tả một "bộ lọc bảo mật bảo vệ cấu hình AI Agent của Zammad" "có thể bị vượt qua bằng cách nhập văn bản được chế tạo đặc biệt vào một trong các trường của AI Agent", và xác định chính xác đối tượng: "Một quản trị viên có quyền tạo hoặc chỉnh sửa AI Agent có thể khai thác lỗi này để chạy các lệnh tùy ý trên máy chủ lưu trữ Zammad." Phạm vi bị ảnh hưởng được ghi nhận là tối đa và bao gồm 7.1.1, phiên bản đã vá là 7.1.2. Người báo cáo được ghi nhận là colinthebomb1; tài khoản công bố là fliebe92. Bản tư vấn không công bố bằng chứng khái niệm nào và không có chi tiết khai thác nào.

GitHub đánh giá lỗ hổng này ở mức Cao, 8,6 theo CVSS 4.0, với vectơ AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H và không thay đổi phạm vi. Diễn giải ra thì điều đó có nghĩa là lỗ hổng có thể được truy cập qua mạng với độ phức tạp thấp, không có yêu cầu tấn công và không cần tương tác của người dùng, bởi một kẻ tấn công đã có đặc quyền cao bên trong ứng dụng, với tác động cao đến tính bảo mật, tính toàn vẹn và tính khả dụng của chính instance Zammad. Bản khuyến cáo liệt kê ba điểm yếu: CWE-20, xác thực đầu vào không đúng cách; CWE-94, chèn mã; và CWE-1336, lớp lỗi công cụ mẫu mà MITRE định nghĩa là không vô hiệu hóa cú pháp đặc biệt "mà có thể được diễn giải thành biểu thức mẫu hoặc các chỉ thị mã khác khi được xử lý bởi công cụ."

Bản sửa lỗi đã thay đổi một chữ cái.

Bản sửa lỗi công khai là commit e3b0c8df91ad2108c8305be23e8fe6f73fb9718d, được gửi kèm thông điệp “Maintenance: Improve ERB sanitizer.” GitHub ghi nhận ngày tác giả là 7 tháng 7 năm 2026 và ngày commit là 3 tháng 8 năm 2026, một ngày trước khuyến cáo và bản phát hành. Commit này động đến hai tệp: một dòng của lib/erb_sanitizer.rb và mười bốn dòng đặc tả được thêm vào.

Dòng duy nhất đó chính là toàn bộ bản vá. Phương thức escape_tag trước đây dùng sub của Ruby, thứ thay thế kết quả khớp đầu tiên của một mẫu trong chuỗi; giờ đây nó dùng gsub, thứ thay thế mọi kết quả khớp. Trong cả hai phiên bản, phần thay thế đều giống nhau: một dấu mở được viết là <% sẽ trở thành <%%, dạng nhân đôi mà ERB, công cụ mẫu của Ruby, kết xuất dưới dạng văn bản nguyên văn thay vì đánh giá. Bản khuyến nghị bảo mật không nêu trường AI Agent nào chứa mẫu; commit xác định bộ lọc lẽ ra phải làm cho mẫu đó trở nên vô hại.

Với sub, chỉ dấu mở đầu tiên trong chuỗi bị vô hiệu hóa. Một payload đặt dấu mở thứ hai ngay sau dấu thứ nhất vẫn sống sót qua bộ lọc: <%<%= 1 + 1 %> trở thành <%%<%= 1 + 1 %>, trong đó ERB phát ra dấu mở dẫn đầu dưới dạng văn bản rồi sau đó đánh giá thẻ bên trong. Đặc tả hồi quy được thêm trong cùng commit gọi rõ thủ thuật này — "with a nested opener smuggled inside a single tag (escape-all-openers bypass)" — và khẳng định rằng cả <%<%= 1 + 1 %> và một thẻ lồng hai lớp <%<%<%= 1 + 1 %> đều phải hiển thị dưới dạng văn bản theo nghĩa đen. Đặc tả đó là mô tả công khai rõ ràng nhất về cách bộ lọc đã bị vượt qua, vì bản tư vấn bảo mật không cung cấp thông tin nào.

Dạng của lỗi này mang tính tổng quát chứ không phải là một điều kỳ lạ riêng của Zammad: một bộ thoát dừng sau lần khớp đầu tiên sẽ bị vô hiệu hóa bởi bất kỳ đầu vào nào chứa thêm một bản sao thứ hai, lồng nhau, của chuỗi mà nó loại bỏ. Thông điệp commit gọi thay đổi này là bảo trì, vốn là cách một bản vá gia cố một ký tự thường được truyền đi — và đó là lý do tại sao bản khuyến cáo, chứ không phải diff, phải mang cảnh báo.

Bảy tuần từ bản tư vấn đến NVD

NVD đã công bố bản ghi của mình cho CVE-2026-84462 vào ngày 25 tháng 9 năm 2026, bảy tuần sau bản tư vấn, và sửa đổi lần cuối vào ngày 28 tháng 9. Bản ghi được đánh dấu là "Deferred", nghĩa là cơ quan chưa công bố phân tích của riêng mình, và khối chỉ số của bản ghi quy điểm 8.6 cho security-advisories@github.com như một chỉ số phụ — việc chấm điểm của GitHub với tư cách là cơ quan cấp số CVE, chứ không phải đánh giá độc lập của NVD. Bản ghi này hoàn toàn không có cấu hình CPE, do đó không ánh xạ lỗ hổng tới một định danh sản phẩm có phiên bản.

Cả hai chi tiết này đều quan trọng đối với bất kỳ ai theo dõi phần mềm tự lưu trữ qua nguồn cấp dữ liệu thay vì qua ghi chú phát hành. Bản vá đã được công khai và có thể hành động vào ngày 4 tháng 8; bản ghi dạng máy đọc được xuất hiện vào ngày 25 tháng 9; và ngay cả khi đó, nó vẫn đến mà không có mã định danh sản phẩm mà các trình quét dựa trên CPE dùng để đối khớp. Trong bảy tuần, tài liệu mô tả chính thức về lỗ hổng là khuyến cáo của nhà cung cấp và ghi chú phát hành của nhà cung cấp.

Điều gì đã được xác lập, và điều gì chưa.

Đã xác lập: bản khuyến cáo, phiên bản đã vá, điểm CVSS và thay đổi mã đều đến từ Zammad và từ cơ sở dữ liệu khuyến cáo của GitHub, và chúng nhất quán với nhau. Bản ghi của NVD sao chép mô tả của cơ quan cấp số mà không bổ sung phân tích riêng của mình. Kho lưu trữ xếp mức độ tin cậy của mục là A trên cơ sở đó, với sự cố không có tranh chấp.

Chưa được xác lập hoặc chưa được ghi nhận: không có bằng chứng khái niệm trong bản khuyến cáo và không có báo cáo nào về việc bị khai thác trong thực tế. EPSS của FIRST cho CVE-2026-84462 xác suất bị khai thác là 0,28 phần trăm trong ba mươi ngày tới, thuộc phân vị thứ 20, trong điểm số được công bố ngày 29 tháng 10 năm 2026. Kho lưu trữ không ghi nhận thiệt hại thực tế nào và xếp mục này ở mức độ nghiêm trọng trung bình — thấp hơn dải High của chính bản khuyến cáo. Đó là những công cụ riêng biệt trả lời những câu hỏi khác nhau, về điều mà lỗ hổng có thể cho phép so với điều đã được biết là đã xảy ra, và bài viết này báo cáo cả hai thay vì dung hòa chúng.

Sự xác nhận độc lập rất ít. Việc tìm kiếm thông tin đưa tin về CVE này trả về các cơ sở dữ liệu lỗ hổng sao chép lại văn bản của cơ quan cấp số hiệu, cùng với ghi chú phát hành của chính Zammad; không có hãng tin nào có vẻ đã đưa tin độc lập về lỗ hổng này. Đó là một phát hiện về hồ sơ, không phải lời chỉ trích hồ sơ: một lỗ hổng thực thi mã từ xa trong helpdesk đòi hỏi tài khoản quản trị viên không phải loại sự kiện tạo ra báo chí, và việc thiếu một tường thuật độc lập tự nó là một phần của những gì hồ sơ ghi lại.

Ai có thể kích hoạt nó, và điều gì đã thay đổi?

Ghi chú phát hành Zammad cho phiên bản 7.1.2, ngày 4 tháng 8 năm 2026, liệt kê mười tám lỗ hổng đã được vá trong phiên bản đó và đặt lỗ hổng vượt qua mẫu của AI Agent lên đầu. Đối với khách hàng dùng dịch vụ lưu trữ, ghi chú nêu: "Không cần thực hiện hành động nào. Các instance của bạn đã được nhóm chúng tôi vá và bảo vệ." Đối với các cài đặt tự lưu trữ, văn bản thẳng thắn hơn: "Chúng tôi khuyến nghị mạnh mẽ việc nâng cấp lên phiên bản Zammad mới nhất ngay lập tức để đảm bảo hệ thống của bạn được bảo vệ." Bản khuyến cáo không đưa ra biện pháp thay thế nào, và hồ sơ không có biện pháp giảm thiểu nào ngoài việc nâng cấp.

Yêu cầu về đặc quyền xứng đáng được xem xét kỹ hơn so với những gì vector đưa ra. PR:H có nghĩa là kẻ tấn công cần quyền truy cập đáng kể trước khi lỗ hổng có thể bị lợi dụng, và ở đây quyền truy cập đó chính là đặc quyền admin.ai_agent mà tài liệu của Zammad nói là bắt buộc để làm việc với AI Agents ngay từ đầu. Trong một helpdesk, đó thường là trưởng nhóm dịch vụ, người tinh chỉnh các bộ phân loại, công cụ gắn thẻ và trình trích xuất văn bản — không nhất thiết là người quản trị máy chủ. Cách diễn đạt của chính bản tư vấn, “một quản trị viên có quyền tạo hoặc chỉnh sửa AI Agents”, hẹp hơn so với “bất kỳ ai” và rộng hơn so với “root”. Nếu không thể nâng cấp ngay lập tức, việc thu hẹp những người nắm giữ đặc quyền đó sẽ làm giảm nhóm người có thể tiếp cận đường đi mã; đây là suy luận từ vector và tài liệu, không phải là biện pháp khắc phục do nhà cung cấp công bố.

Không có tài liệu gốc nào đưa mô hình ngôn ngữ vào đường khai thác. Lệnh chạy bên trong tiến trình Ruby của Zammad khi cấu hình của agent được kết xuất; không nội dung nào trong bản khuyến cáo, commit hay ghi chú phát hành mô tả việc mô hình tạo ra payload. Tính năng AI Agent cung cấp trường do quản trị viên có thể ghi và được xử lý bằng mẫu, còn AI là bề mặt chứ không phải cơ chế. Đó là kiểu mẫu mà bản ghi chỉ ra: định nghĩa agent — gồm hướng dẫn, mẫu và bộ lọc của nó — là cấu hình có thể thực thi, được chỉnh sửa bởi những người làm công việc hỗ trợ, chứ không phải đánh giá bảo mật.

Biện pháp khắc phục của Zammad là tương xứng và tẻ nhạt: thay đổi một phương thức, hai bài kiểm thử hồi quy, và một lần tăng phiên bản vá luôn mười bảy lỗ hổng khác cùng với lỗ hổng này. Phần đáng được ghi nhớ là mô hình phơi nhiễm. Một helpdesk cho phép trưởng nhóm hỗ trợ định nghĩa một nhân viên hỗ trợ cũng đồng thời cho phép trưởng nhóm đó viết ra thứ mà máy chủ sẽ thực thi, và thứ duy nhất đứng giữa hai điều này là một bộ lọc phải đúng với mọi bản sao lồng nhau của cú pháp mà nó loại bỏ.