Cloudflare khắc phục sự cố rò rỉ dữ liệu giữa các yêu cầu trong engine suy luận GLM-5.3

Cloudflare công bố một sự cố bảo mật liên quan đến nền tảng Workers AI, trong đó mô hình GLM-5.3 vô tình trả về dữ liệu từ các yêu cầu của những người dùng khác. Lỗ hổng này hoạt động từ ngày 27 tháng 8 đến ngày 9 tháng 9 năm 2026, ảnh hưởng đến 155 phản hồi và được kích hoạt bởi các prompt có ngữ cảnh dài cụ thể. Cloudflare sau đó đã vá engine suy luận cơ bản và khôi phục mô hình với các biện pháp kiểm tra an toàn được nâng cao.

Chuyện gì đã xảy ra

Vào ngày 8 tháng 9 năm 2026, nhà nghiên cứu bảo mật Gadi Evron báo cáo rằng mô hình @cf/zai-org/glm-5.3 trên Workers AI đang bị rò rỉ dữ liệu phiên. Cloudflare đã tái hiện vấn đề vào sáng hôm sau và đưa mô hình ngoại tuyến trong vòng 40 phút. Cuộc điều tra cho thấy, trong khoảng thời gian từ ngày 27 tháng 8 đến ngày 9 tháng 9, một số lượng nhỏ khách hàng đã nhận được các phản hồi chứa văn bản từ những yêu cầu của các khách hàng khác gửi tới cùng một mô hình ngay trước khi yêu cầu của họ được xử lý. Tất cả 155 phản hồi bị ảnh hưởng đều được tạo ra từ các prompt vượt quá 681.280 token. Cloudflare không tìm thấy bằng chứng về việc khai thác có chủ đích, lưu ý rằng các mẫu yêu cầu phù hợp với việc sử dụng ngữ cảnh dài thông thường chứ không phải các cuộc tấn công nhắm mục tiêu.

Nguyên nhân gốc rễ là sự kết hợp giữa một lỗi cấu hình và một lỗi trong SGLang, engine suy luận mã nguồn mở cung cấp năng lượng cho dịch vụ. Cloudflare đã triển khai GLM-5.3 với cửa sổ ngữ cảnh (context window) là 1.048.576 token, nhưng hồ chứa bộ nhớ đệm Key-Value (KV cache pool) trên các GPU prefill chỉ có thể chứa 681.280 token. Mặc dù đội ngũ kỹ thuật nhận thức được sự sai lệch này, họ giả định rằng engine sẽ trả về một lỗi đối với các prompt không vừa khớp. Thay vào đó, engine đã cố gắng xử lý yêu cầu bằng một đường dẫn từ chối bị lỗi, dẫn đến việc lộ dữ liệu. Không có mô hình nào khác được lưu trữ trên Workers AI bị ảnh hưởng vì hồ chứa KV của chúng lớn hơn độ dài ngữ cảnh tương ứng.

Cơ chế hoạt động

Workers AI phục vụ GLM-5.3 bằng kiến trúc phân tách (disaggregated architecture), nơi các GPU prefill xử lý prompt và tạo ra các bộ nhớ đệm KV, sau đó được truyền qua truy cập bộ nhớ trực tiếp từ xa (RDMA) tới các GPU decode để tạo phản hồi. Bộ nhớ đệm KV được lưu trữ trong một hồ chứa dùng chung gồm các trang có kích thước cố định trong bộ nhớ GPU. Để duy trì hiệu suất cao, các trang này không được xóa sạch (zeroed out) giữa các yêu cầu; engine dựa vào việc theo dõi quyền sở hữu nghiêm ngặt để đảm bảo rằng một yêu cầu mới sẽ ghi đè lên bất kỳ dữ liệu cũ nào trong các trang được gán cho nó.

Khi một prompt vượt quá kích thước hồ chứa KV, bộ lập lịch SGLang đánh dấu yêu cầu đó là bị từ chối nhưng thay thế nó bằng một placeholder một token để cho phép nó chảy qua cơ chế batch. Trong thiết lập một nút đơn (single-node setup), điều này sẽ dẫn đến một lỗi. Tuy nhiên, trong thiết lập phân tách, các hàng đợi chấp nhận (admission queues) kiểm tra xem một yêu cầu đã "hoàn thành" hay chưa, thay vì kiểm tra xem nó có bị "từ chối" hay không. Vì yêu cầu bị từ chối không được đánh dấu là hoàn thành, nó được chấp nhận vào nút prefill. Nút prefill tạo ra một bộ nhớ đệm cho placeholder một token và truyền nó sang nút decode. Nút decode, mong đợi một lần truyền đầy đủ, đã giữ lại các trang dự trữ còn lại vẫn chứa dữ liệu cũ (stale data) từ những người dùng trước đó. Do đó, phản hồi cuối cùng bao gồm văn bản mạch lạc được tạo từ placeholder trộn lẫn với dữ liệu bị rò rỉ từ các trang bộ nhớ đệm cũ.

Chi tiết chính

• Mô hình bị ảnh hưởng: Chỉ @cf/zai-org/glm-5.3 bị tác động; tất cả các mô hình Workers AI khác vẫn an toàn.
• Khoảng thời gian phơi nhiễm: Lỗ hổng tồn tại từ ngày 27 tháng 8 năm 2026 cho đến khi mô hình bị đưa ngoại tuyến vào ngày 9 tháng 9 năm 2026.
• Phạm vi ảnh hưởng: Chính xác 155 phản hồi bị ảnh hưởng, tất cả đều bắt nguồn từ các prompt dài hơn 681.280 token.
• Nguyên nhân gốc rễ: Sự sai lệch giữa cửa sổ ngữ cảnh 1.048.576 token và hồ chứa bộ nhớ đệm KV 681.280 token, kết hợp với lỗi trong cách SGLang xử lý các yêu cầu bị từ chối ở chế độ phân tách.
• Khắc phục: Cloudflare đã tăng kích thước hồ chứa KV lên khoảng 2,04 triệu token và vá SGLang để hủy bỏ đúng cách các yêu cầu bị từ chối trước khi truyền KV.
• Các bản vá upstream: Các nhà duy trì SGLang đã hợp nhất nhiều bản vá, bao gồm PR #38704 và #38935, và phát hành các phiên bản v0.5.21 và v0.5.22 để giải quyết vấn đề cho tất cả người dùng.

Tại sao điều này quan trọng

Sự cố này làm nổi bật tính dễ tổn thương của an toàn bộ nhớ trong các engine suy luận LLM hiệu suất cao. Khi các nhà cung cấp thúc đẩy cửa sổ ngữ cảnh lớn hơn và thông lượng nhanh hơn, họ thường áp dụng các kiến trúc phức tạp như prefill và decode phân tách. Các hệ thống này phụ thuộc vào việc quản lý trạng thái chính xác trên nhiều nút. Khi các giá trị cấu hình như độ dài ngữ cảnh và kích thước hồ chứa bộ nhớ không được thực thi nghiêm ngặt, các trường hợp biên (edge cases) có thể dẫn đến các lỗ hổng bảo mật nghiêm trọng. Đối với các nhóm kỹ thuật xây dựng trên nền tảng các nền tảng này, điều này nhấn mạnh tầm quan trọng của việc hiểu rằng các tối ưu hóa hiệu suất như tái sử dụng bộ nhớ không xóa sạch đi kèm với trách nhiệm đáng kể đối với nhà cung cấp hạ tầng.

Đối với các nhà phát triển sử dụng Workers AI hoặc các dịch vụ tương tự, sự kiện này là lời nhắc nhở rằng sự cô lập tenant (tenant isolation) không chỉ là mối lo ngại ở cấp độ mạng mà còn là thách thức quản lý bộ nhớ bên trong chính engine suy luận. Mặc dù phản ứng nhanh chóng của Cloudflare đã hạn chế mức độ phơi nhiễm, thực tế là 155 người dùng đã nhận được dữ liệu bị rò rỉ cho thấy rằng ngay cả những khoảng thời gian ngắn ngủi của lỗ hổng cũng có thể gây ra hậu quả hữu hình. Nó cũng chứng minh giá trị của việc công bố phối hợp và cộng tác mã nguồn mở, vì các bản vá do Cloudflare phát triển đã được hợp nhất upstream để mang lại lợi ích cho cộng đồng SGLang rộng lớn hơn.

Bạn có thể làm gì

• Cập nhật SGLang: Nếu bạn vận hành hạ tầng suy luận riêng sử dụng SGLang, hãy nâng cấp ngay lập tức lên phiên bản v0.5.22 trở lên để tích hợp các bản vá bảo mật mới nhất.
• Xác thực Cấu hình: Đảm bảo rằng kích thước hồ chứa bộ nhớ đệm KV của bạn lớn hơn nghiêm ngặt so với độ dài ngữ cảnh tối đa cho mọi mô hình bạn triển khai. Đừng dựa vào engine để xử lý mượt mà các sai lệch.
• Giám sát Bất thường: Triển khai ghi log và giám sát thời gian phản hồi và số lượng token. Các phản hồi đến bất ngờ nhanh đối với các prompt dài có thể chỉ ra việc xử lý bị cắt xén hoặc lỗi bộ nhớ đệm.
• Xem xét Thiết lập Phân tách: Nếu sử dụng kiến trúc prefill/decode phân tách, hãy xác minh rằng các đường dẫn từ chối được xử lý đúng cách trên các nút và các yêu cầu bị từ chối không tiến hành truyền KV.
• Kiểm tra Các vấn đề Upstream: Thường xuyên xem xét các tracker vấn đề của các engine suy luận bạn phụ thuộc vào, chẳng hạn như SGLang, để biết các lỗi an toàn bộ nhớ và điều kiện tranh chấp (race conditions) đã biết.
• Kiểm toán Sử dụng Ngữ cảnh Dài: Nếu ứng dụng của bạn phụ thuộc vào các cửa sổ ngữ cảnh rất dài, hãy thực hiện các bài kiểm tra tích hợp cụ thể để xác thực tính mạch lạc của đầu ra và sự cô lập dưới tải, thay vì chỉ kiểm tra các mã trạng thái HTTP.