Lỗ hổng server-side request forgery trong Open WebUI của open-webui làm lộ phản hồi nội bộ

Open WebUI là một nền tảng AI self-hosted có khả năng mở rộng, nhiều tính năng và thân thiện với người dùng. Trước 0.11.1, POST /api/v1/retrieval/process/web và POST /api/v1/retrieval/process/web/search trong backend/open_webui/retrieval/web/utils.py đã coi việc Python phân loại một địa chỉ là globally routable như bằng chứng rằng destination là bên ngoài. Người dùng đã xác thực có thể khiến một instance chạy trên Azure fetch và trả về nội dung từ 168.63.129.16, Azure platform channel, cũng như các reserved range khác mà cơ chế phân loại tiêu chuẩn không từ chối. Vấn đề này được sửa trong version 0.11.1.

• Package open-webui cho pip: các phiên bản < 0.11.1 được xác định là affected.
• Vendor advisory xác định 0.11.1 là phiên bản patched. Trạng thái của mọi nhánh later hoặc parallel không được xác nhận ngoài release fixed cụ thể này.
• Đối với 168.63.129.16, exposure liên quan đến Azure platform channel yêu cầu host Open WebUI chạy trên Azure. Các reserved range khác chỉ có thể bị truy cập nếu deployment thực sự route được tới chúng.
• Advisory nêu rằng code có trong mọi build, không bị giới hạn bởi optional component. Các deployment đặt ENABLE_LOCAL_WEB_FETCH=true cố ý bỏ qua address screen trong mọi version; đây là một điều kiện exposure riêng, không phải bằng chứng rằng deployment đã được bảo vệ.

Lỗ hổng nằm trong thành phần dùng chung backend/open_webui/retrieval/web/utils.py, được các chức năng server-side web fetch sử dụng. Cơ chế cũ dùng phân loại địa chỉ toàn cục của Python như một đại diện cho câu hỏi liệu đích đến có phải là hệ thống bên ngoài hay không. Hai câu hỏi này không tương đương: một số dải địa chỉ dành cho mục đích đặc biệt vẫn được thư viện phân loại là globally routable, trong khi thực tế chúng có thể trỏ tới endpoint nội bộ hoặc endpoint của nền tảng máy chủ.

URL do người dùng kiểm soát được đưa vào POST /api/v1/retrieval/process/web để nạp URL vào RAG hoặc POST /api/v1/retrieval/process/web/search để tìm kiếm web. Các endpoint này yêu cầu tài khoản đã xác thực và đã được verify; không cần quyền administrator hoặc workspace permission đặc biệt. Khi địa chỉ vượt qua kiểm tra, Open WebUI thực hiện request từ phía máy chủ và trả response body về API, đồng thời đưa nội dung đó vào RAG context.

Advisory xác nhận lỗi nằm trong code được phân phối ở mọi build, không bị giới hạn bởi một optional component. Azure platform channel 168.63.129.16 là ví dụ cụ thể vì địa chỉ này có thể truy cập từ Azure virtual machine dù bị thư viện phân loại như địa chỉ toàn cục. Khả năng đọc được dữ liệu cụ thể nào vẫn phụ thuộc vào routing, quyền của endpoint nội bộ và cấu hình triển khai; bằng chứng hiện có không xác định toàn bộ nội dung có thể truy cập.

Lỗ hổng có thể bị khai thác qua network thông qua hai endpoint server-side web fetch nêu trên. Kẻ tấn công cần một tài khoản đã xác thực và đã được verify, nhưng không cần quyền administrator, workspace permission đặc biệt hoặc user interaction từ nạn nhân. Bản ghi phân loại attack complexity là cao, vì vậy việc khai thác không phải là một request tùy ý trong mọi môi trường.

Bản ghi cho biết public exploit tồn tại, và advisory có proof of concept cho thấy server có thể truy xuất một địa chỉ dành riêng rồi trả nội dung về cho người gọi. Advisory cũng nêu rõ thử nghiệm không gửi request tới một Azure platform channel đang hoạt động; do đó bằng chứng này xác nhận hành vi của ứng dụng nhưng không xác lập việc khai thác thực tế trong các môi trường triển khai. Trạng thái known exploited không được thiết lập trong bằng chứng được cung cấp.

Kết quả kỹ thuật chính là Open WebUI thực hiện outbound GET tới một destination không nên được coi là external rồi trả response body cho người dùng đã xác thực. Đây là SSRF có phạm vi ảnh hưởng sang các tài nguyên bên ngoài trust boundary của ứng dụng, với rủi ro chính là mất confidentiality của response từ internal service hoặc cloud platform channel.

Quyền khai thác yêu cầu tài khoản đã xác thực, nên đây không phải là unauthenticated access. Đối với Azure, một người dùng hợp lệ có thể khiến host truy cập Azure platform channel; đối với các reserved range khác, kết quả phụ thuộc vào routing của host. Record không xác lập arbitrary write, code execution hoặc một credential cụ thể đã bị lấy, và cũng không cho thấy rằng mọi deployment đều truy cập được cùng một tập tài nguyên nội bộ.

• Người dùng đã xác thực có thể đọc response body từ các địa chỉ dùng cho mục đích nội bộ mà operator không định cung cấp cho người dùng Open WebUI.
• Trên Azure, phạm vi này bao gồm platform channel mà mọi Azure virtual machine có thể truy cập; dữ liệu trả về có thể chứa thông tin về nền tảng hoặc host, nhưng bằng chứng hiện có không xác định một secret cụ thể đã bị lấy.
• Nội dung được fetch cũng đi vào RAG context, làm mở rộng ranh giới dữ liệu giữa dịch vụ Open WebUI và các tài nguyên nội bộ mà ứng dụng có thể kết nối.
• Mức độ ảnh hưởng thực tế phụ thuộc vào việc người dùng có tài khoản hợp lệ, host có route tới đích hay không, kiểm soát outbound network và việc địa chỉ có bị chặn thủ công hay không. Không có bằng chứng trong record cho thấy lỗi này tự nó gây mất availability hoặc cho phép arbitrary code execution.

1. Nâng cấp package open-webui lên 0.11.1, là release fixed cụ thể được advisory xác nhận.
2. Nếu chưa thể nâng cấp ngay, thêm các destination cần chặn vào WEB_FETCH_FILTER_LIST, tối thiểu gồm 168.63.129.16 khi triển khai trên Azure, đồng thời áp dụng outbound network restriction ở lớp hạ tầng. Đây là biện pháp giảm thiểu tạm thời và cần được kiểm thử vì hành vi filtering cũ có thể không bao phủ mọi cách viết địa chỉ hoặc mọi redirect path.
3. Không bật ENABLE_LOCAL_WEB_FETCH như một workaround. Tùy chọn này vô hiệu hóa address screen theo thiết kế và có thể làm các internal destination reachable một cách có chủ đích.
4. Sau khi sửa, xác minh rằng address screening được áp dụng khi URL được kiểm tra và khi kết nối thực sự được tạo, bao gồm redirect hop, proxy path, DNS cache và DNS rebinding. Kiểm tra này giúp bảo đảm bản triển khai nhận đúng thay đổi sửa lỗi thay vì chỉ thay đổi version metadata.
5. Rà soát request và response history để xác định liệu các tài khoản đã xác thực có từng yêu cầu internal destination hay không. Advisory không cung cấp IOC cụ thể, vì vậy việc không thấy một mẫu log nhất định không loại trừ exposure.

• Kiểm kê các triển khai Open WebUI, package open-webui, nơi chạy server-side RAG URL ingestion hoặc web search, sau đó đối chiếu release đang dùng với ranh giới affected và fixed do vendor công bố.
• Xác định host có chạy trên Azure hay không, đặc biệt là Azure virtual machine, AKS, Container Apps hoặc môi trường tương đương, và kiểm tra khả năng routing tới 168.63.129.16 cùng các dải dành riêng khác.
• Kiểm tra giá trị của ENABLE_LOCAL_WEB_FETCH và WEB_FETCH_FILTER_LIST. Cần lưu ý rằng bật ENABLE_LOCAL_WEB_FETCH=true sẽ vô hiệu hóa address screen theo thiết kế.
• Rà soát authentication log và request log cho các lời gọi tới POST /api/v1/retrieval/process/web hoặc POST /api/v1/retrieval/process/web/search có URL đích là địa chỉ nội bộ, reserved range hoặc Azure platform channel. Đây là dấu hiệu cần điều tra, không phải một IOC được vendor xác nhận.
• Trên bản đã sửa, kiểm thử trong môi trường kiểm soát rằng reserved destination bị từ chối ở cả URL validation và connection time, bao gồm redirect hoặc DNS rebinding, trong khi public destination hợp lệ vẫn hoạt động. Có thể tìm các cảnh báo như Blocked by filter list hoặc Blocked non-global address nếu logging của ứng dụng được bật. Việc không thấy log như vậy không chứng minh rằng hệ thống an toàn.