Originally published on NextFuture
Bạn dựng một Ollama server nội bộ cho team và mở API pull để anh em tự tải model về. Cấu hình đó vừa trở thành một đường gửi request vào mạng nội bộ của bạn, và attacker không cần tài khoản Ollama nào. Bài này mổ đúng những gì CVE-2026-85180 làm được, tại sao bản vá trước đó không chặn, và các bước bịt ngay khi chưa có release mới.
Lỗ hổng làm được gì
Theo báo cáo, Ollama có thể bị buộc gọi tới một internal host trong lúc pull tensor model. Một registry do attacker kiểm soát trả về tensor-layer manifest, trong đó blob request redirect sang địa chỉ private — bao gồm cả cloud metadata endpoint. Điểm đáng lo nhất: pull API không yêu cầu victim phải đăng nhập.
Cụ thể hơn, manifest của attacker có thể trỏ tensor blob tới một server trả redirect về http://169.254.169.254/latest/meta-data/, tới một service trong private network của Ollama host, hoặc một internal address khác mà máy đó với tới được. Downloader sau đó tự phát GET theo redirect. Người báo lỗi cho biết đã xác nhận các request lặp lại từ một Ollama container tới internal listener qua đủ số lần retry mặc định.
Đây là mô hình SSRF kinh điển, nhưng nằm ở chỗ ít ai nghĩ tới: model puller, không phải API do bạn viết.
Tại sao bản vá cũ không cover đường này
Ollama đã có một lỗi redirect trước đó, tracked là CVE-2026-5530. Bản vá đó thêm redirect check vào server/download.go. Vấn đề là tensor model đi qua downloader riêng nằm ở x/transfer/, và guard kia không được chia sẻ sang package đó.
Theo phân tích source, đường non-tensor hiện cài một CheckRedirect callback: cho phép redirect same-host và dừng ngay ở hostname khác. Đường tensor thì tự xử lý redirect thủ công. Redirect loop của nó coi response 302, 303 hoặc 307 từ blob endpoint là một URL mới. Nếu URL đó khác host, code trả về luôn mà không kiểm tra đích là private, loopback, link-local hay internal. Trong source v0.33.2, hàm resolve() nhận cross-host Location và trả nó về cho download client.
Bài học kiến trúc rút ra ở đây đáng ghi lại: một security guard đặt ở tầng handler cụ thể sẽ không tự lan sang code path mới. Guard phải nằm ở lớp mà mọi outbound request đều phải đi qua.
Trạng thái bản vá: chưa có
Tại thời điểm bài gốc công bố, chưa có release Ollama nào vá lỗi này. Release page mới nhất ghi v0.33.2, và logic redirect có vấn đề vẫn còn trong tag đó cũng như trên main.
Có hai upstream fix tham chiếu tới issue. PR #17082 đề xuất reject các đích local, private và link-local, tính cả trường hợp DNS rebinding và proxy. PR #18021 thêm redirect guard resolve tên đích và fail closed khi DNS validation thất bại. Cả hai đang open và chưa merge tại thời điểm công bố.
Nghĩa là: đừng chờ bản vá. Chuyển sang xử lý ở tầng network.
Chặn ngay trong hôm nay
Bốn việc từ khuyến nghị của báo cáo, xếp theo thứ tự nên làm trước:
Không cho user không tin cậy submit model reference tùy ý lên Ollama server. Đây là điều kiện tiên quyết của cả chuỗi tấn công.
Giới hạn outbound traffic từ Ollama process. Chặn cloud metadata address, loopback, dải RFC 1918, dải link-local và các đích internal khác ngay tại host hoặc container network boundary.
Ưu tiên một curated internal registry và allowlist hostname của nó. Báo cáo nói rõ: cách này giảm phơi nhiễm nhưng không thay được egress filtering.
Theo dõi Ollama log và network telemetry: tìm pull request đi kèm ngay sau đó là connection tới địa chỉ private hoặc link-local.
Ví dụ minh hoạ cho ý thứ hai — chưa test trên môi trường của bạn, hãy khớp lại với network stack đang dùng:
# Ví dụ minh hoạ: chặn metadata endpoint cho container chạy Ollama
docker run --name ollama \
--add-host metadata.internal:127.0.0.1 \
--network ollama-egress-restricted \
ollama/ollama
# egress policy thực tế nên đặt ở firewall/CNI, không phải trong container
Để kiểm tra một cài đặt trước khi approve pull, chạy ollama --version rồi đối chiếu với release notes của vendor. Đừng coi v0.33.2 là đã vá lỗi này. Với source build, kiểm tra thêm redirect guard trong x/transfer/download.go, không chỉ guard cũ ở server/download.go.
Command guard không thay được network guard
Nếu team bạn đã siết phần agent chạy shell, đây là lúc thấy rõ hai lớp phòng thủ khác nhau. Một tác giả trên Dev.to vừa giới thiệu agent-exec-guard, MCP server mã nguồn mở đứng giữa agent và shell. Theo mô tả của tác giả, nó parse câu lệnh thành AST thật thay vì string matching, rồi phân loại thành ba nhóm: SAFE chạy ngay; BLOCKED bị từ chối tức thì (truy cập secrets, xoá diện rộng, exfiltration, command substitution nhét trong argument); UNCERTAIN phải escalate cho người thật approve.
Tác giả cũng cho biết bước approve dùng signed single-use HMAC token gắn với checksum của đúng câu lệnh đó, nên agent không thể tự nhận "người dùng đã approve". Dự án mới ở v0.1 và chính tác giả đang mời báo lỗi edge case, nên hãy đánh giá như một hướng tiếp cận, chưa phải control đã kiểm chứng ở production.
Điểm cần nắm: guard kiểu đó lọc câu lệnh. Nó không nhìn thấy HTTP redirect mà model puller tự đi theo sau khi lệnh ollama pull đã được duyệt là SAFE. Hai lớp này không thay thế nhau.
Đừng phóng đại mức độ
Báo cáo nói thẳng: đây không phải shell takeover trực tiếp trên Ollama, và nó không chứng minh mọi Ollama deployment đều với tới được từ public internet. Attacker vẫn cần một victim server chịu xử lý model reference hoặc registry do họ kiểm soát. Mức thiệt hại phụ thuộc vào những gì Ollama host với tới được và mạng của nó trả về.
Nói cách khác: nếu Ollama chạy cạnh cloud credentials, internal API hay service nhạy cảm khác, hãy đối xử với model puller của nó như một network-capable service.
Theo dõi tiếp
Ba mốc đáng đặt lịch nhắc: PR #17082 và PR #18021 được merge hay chưa; release note của bản Ollama kế tiếp có nêu redirect guard cho tensor path hay không; và egress rule bạn vừa thêm có chặn đúng khi test lại bằng một pull thất bại có chủ đích.
This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.
Top comments (0)