Rò rỉ mật khẩu proxy qua curl, libsoup và requests: kiểm tra

Mật khẩu của proxy thường được giữ kín khỏi mọi người: không hiển thị trong ảnh chụp màn hình, không commit vào git, giữ trong các biến môi trường. Nhưng vào năm 2026, đã phát hiện ra rằng chính HTTP-client có thể tiết lộ nó. Trong khoảng thời gian từ tháng 4 đến tháng 7, đã xuất hiện một số lỗ hổng trong curl, libcurl và libsoup, trong đó tiêu đề Proxy-Authorization được gửi đến proxy không đúng, hoặc thậm chí đến trang web mục tiêu. Dưới đây là phân tích về các điều kiện xảy ra và kiểm tra từng bước cho stack của bạn.

Chuyện gì đã xảy ra: bốn lỗ hổng trong bốn tháng

Tất cả các lỗi này đều hoạt động tương tự: client ghi nhớ tên đăng nhập và mật khẩu của một proxy và vô tình gửi chúng tiếp theo trong chuỗi.

CVE-2026-6253 (curl và libcurl 7.14.1–8.19.0). Nếu cho http:// và https:// được cấu hình với các proxy khác nhau, proxy đầu tiên yêu cầu mật khẩu, trong khi proxy thứ hai không, thì khi chuyển hướng từ việc thay đổi giao thức, curl sẽ gửi thông tin xác thực của proxy đầu tiên đến proxy thứ hai. Dữ liệu được gửi dưới dạng base64, tức là thực tế là văn bản rõ. Đã được sửa trong curl 8.20.0, phát hành vào ngày 29 tháng 4 năm 2026. Cả curl trên console cũng bị ảnh hưởng, không chỉ thư viện.
CVE-2026-8927 (libcurl 7.12.0–8.20.0). Ứng dụng tái sử dụng một handle cho nhiều yêu cầu, proxy được lấy từ các biến môi trường, và xác thực diễn ra qua Digest. Khi đó, tiêu đề Proxy-Authorization cho proxy A được gửi đến proxy B, và proxy B có thể lặp lại nó để giả mạo bạn. Đã được sửa trong curl 8.21.0 vào ngày 24 tháng 6 năm 2026. curl trên console không bị ảnh hưởng. Một lỗi gần giống như vậy được mô tả trong CVE-2026-7168, chỉ khác ở cách chọn proxy.
CVE-2026-12547 (libsoup, SoupAuthManager). libsoup lưu trữ thông tin xác thực của proxy mà không gắn chúng với địa chỉ host:port. Khi cài đặt proxy thay đổi (các tham số hệ thống, WPAD), tiêu đề cũ được gửi đến proxy mới. Được công bố vào ngày 21 tháng 7 năm 2026, đánh giá thấp.
CVE-2026-66339 (libsoup, các đường hầm CONNECT). Sau khi thiết lập đường hầm CONNECT qua HTTP-proxy, libsoup gắn Proxy-Authorization vào các yêu cầu HTTPS tiếp theo bên trong đường hầm. Tiêu đề này đã được máy chủ mục tiêu nhìn thấy. CVSS 6.5, công bố vào ngày 24 tháng 7 năm 2026.

Câu chuyện không mới. Trong thư viện Python requests từ phiên bản 2.3.0 đến 2.31.0 (CVE-2023-32681), tiêu đề Proxy-Authorization khi chuyển hướng sang HTTPS đã được gửi đến máy chủ mục tiêu, nếu tên đăng nhập và mật khẩu được nhập trực tiếp vào URL của proxy. Trong urllib3 trước phiên bản 1.26.19 và 2.2.2 (CVE-2024-37891), tiêu đề được thiết lập thủ công, không phải thông qua hỗ trợ proxy tích hợp, không bị loại bỏ khi chuyển hướng đến miền khác.

Tại sao điều này quan trọng đối với việc làm việc với proxy

Đối với proxy trả phí, mật khẩu tương đương với tiền. Ai có được nó sẽ tiêu tốn lưu lượng của bạn cho đến khi bạn thay đổi quyền truy cập. Khi thanh toán cho gigabyte, đây là một chi phí trực tiếp, và khi chia sẻ cho toàn đội, còn có cả các hành động của người khác từ IP của bạn.

Các kịch bản dễ bị tổn thương nhất trông như sau:

Các trình phân tích và giám sát, tự động đi qua các chuyển hướng. Trang web mục tiêu hoặc chuyển hướng trung gian có thể dẫn yêu cầu đến miền thu thập tiêu đề.
Các script với nhiều proxy: các proxy khác nhau cho các giao thức khác nhau, chuyển đổi proxy giữa các yêu cầu trên cùng một kết nối, kết hợp “proxy có mật khẩu” và “proxy không có mật khẩu”.
Các quy trình dài hạn trên máy chủ Linux, nơi libcurl và libsoup đi kèm với các gói hệ thống và được cập nhật cùng với bản phân phối, không phải với mã của bạn.
Mạng doanh nghiệp với WPAD và PAC-files: proxy thay đổi mà không cần sự tham gia của ứng dụng, và chính trường hợp này được mô tả trong CVE-2026-12547.

Cách kiểm tra stack của bạn: từng bước một

Tìm hiểu phiên bản thực tế của libcurl, không chỉ của curl trên console. Lệnh curl -V hiển thị cả hai, nhưng ứng dụng có thể được biên dịch với bản sao thư viện riêng. Đối với Python với pycurl, thực hiện python -c "import pycurl; print(pycurl.version)", đối với PHP gọi curl_version(). Giới hạn an toàn: 8.21.0 trở lên hoặc các nhánh đã được sửa 8.20.1+, 8.16.1+ và 8.14.2+.
Kiểm tra các phụ thuộc Python. Thực hiện pip show requests urllib3. Cần có requests không thấp hơn 2.31.0 và urllib3 không thấp hơn 1.26.19 (nhánh 1.x) hoặc 2.2.2 (nhánh 2.x). Nếu phụ thuộc đến từ một nguồn gián tiếp, hãy xem pip list trong cùng một môi trường mà trình phân tích hoạt động.
Kiểm tra libsoup trên Linux. Điều này áp dụng cho các ứng dụng GNOME, WebKitGTK và mọi thứ được biên dịch trên stack này. Cập nhật gói qua trình quản lý bản phân phối và đối chiếu với thông báo bảo mật của bản phân phối của bạn: trong các thẻ CVE này của Red Hat, các phiên bản bị ảnh hưởng được chỉ định là RHEL 6–10.
Tìm kiếm trong mã cài đặt tiêu đề thủ công. Tìm kiếm theo Proxy-Authorization trong toàn bộ kho lưu trữ. Nếu tiêu đề được thiết lập bằng tay, không phải thông qua cơ chế proxy tiêu chuẩn của client (proxies= trong requests, ProxyManager trong urllib3, CURLOPT_PROXYUSERPWD trong libcurl), đây là ứng cử viên cho việc rò rỉ khi chuyển hướng.
Tìm kiếm việc tái sử dụng kết nối khi thay đổi proxy. Một handle libcurl, một phiên requests hoặc một HTTP-agent, qua đó các yêu cầu với các proxy khác nhau được thực hiện lần lượt. Cách sửa đơn giản nhất: một phiên riêng cho mỗi proxy.
Tắt các chuyển hướng tự động ở những nơi không cần thiết. Trong requests, điều này là allow_redirects=False, trong urllib3 redirect=False, trong curl không đặt -L và CURLOPT_FOLLOWLOCATION. Khi đó, 3xx sẽ được xử lý thủ công, và bạn tự quyết định hướng đi tiếp theo. Chính con đường vòng này được các tác giả của requests và urllib3 cung cấp.
Thực hiện một bài kiểm tra thực tế để kiểm tra. Thiết lập một máy chủ HTTP đơn giản, in tất cả các tiêu đề đến, và thực hiện chuyển hướng đến một máy chủ thứ hai tương tự. Chạy qua trình phân tích của bạn với proxy trong một kịch bản thực tế, bao gồm cả việc thay đổi giao thức từ http sang https. Nếu bất kỳ máy chủ nào thấy Proxy-Authorization, việc rò rỉ đã được xác nhận trong mã của bạn, không phải trong lý thuyết.

Các cạm bẫy

Các hình ảnh Docker sống cuộc sống riêng. Đã cập nhật curl trên máy chủ, nhưng trình phân tích hoạt động trong container với hình ảnh cơ bản cũ. Cần kiểm tra bên trong container: docker exec <container> curl -V.
Curl trên console và libcurl được cập nhật khác nhau. CVE-2026-8927 không ảnh hưởng đến curl trên console, trong khi CVE-2026-6253 lại ảnh hưởng đến nó. curl -V mới trong terminal không nói gì về thư viện mà PHP hoặc Python của bạn được biên dịch từ đó.
Digest không cứu được. Đúng, trong Digest mật khẩu không được gửi dưới dạng văn bản rõ. Nhưng trong CVE-2026-8927, kẻ tấn công không cần mật khẩu: tiêu đề bị chặn được lặp lại, miễn là nonce còn hiệu lực.
Mật khẩu trong URL tiện lợi nhưng nguy hiểm. Việc rò rỉ trong requests xảy ra chính khi thông tin xác thực được nhập vào địa chỉ proxy dạng user:pass@host:port. Đây không phải là lý do để từ chối định dạng này, nhưng là lý do để giữ cho các thư viện luôn cập nhật.
Chuyển hướng có thể đến từ không phải mục tiêu. Các trang captcha, banner đồng ý, rút ngắn liên kết và CDN cũng phản hồi 3xx. Càng nhiều “theo dõi liên kết” trong crawler, bề mặt tấn công càng rộng.

Làm thế nào để hạn chế thiệt hại nếu mật khẩu vẫn bị rò rỉ

Không thể hoàn toàn loại trừ việc rò rỉ: ngày mai sẽ có CVE tiếp theo. Do đó, điều quan trọng là một lần rò rỉ có giá trị bao nhiêu.

Một dự án, một quyền truy cập. Không giữ một tên đăng nhập chung cho tất cả các trình phân tích. Trong ProxyCove, mỗi proxy mua được một cặp tên đăng nhập và mật khẩu riêng, vì vậy việc rò rỉ quyền truy cập của một script không mở ra lưu lượng của những người khác.
Không giữ trên một quyền truy cập nhiều lưu lượng hơn mức cần thiết. Nạp dần dần theo nhiệm vụ, không phải cho nửa năm tới.
Theo dõi mức tiêu thụ. Sự gia tăng đột ngột của lưu lượng mà không có sự gia tăng số lượng nhiệm vụ — dấu hiệu đầu tiên cho thấy quyền truy cập của bạn đang được người khác sử dụng.
Thay đổi mật khẩu ngay khi nghi ngờ và theo lịch trình. Cách thiết lập điều này mà không có thời gian chết đã được giải thích trong hướng dẫn về quy trình xoay mật khẩu proxy.

Loại proxy nào nên chọn và nó có liên quan gì

Việc rò rỉ không phụ thuộc vào loại proxy: lỗi nằm trong client. Nhưng giá của việc rò rỉ thì có. Proxy trung tâm dữ liệu rẻ hơn cho mỗi gigabyte, và để phân tích các trang web đơn giản với nhiều chuyển hướng, hợp lý khi giữ chúng tách biệt khỏi lưu lượng đắt tiền. Proxy cư trú nên được dành cho các nhiệm vụ mà chúng thực sự cần thiết, và tạo các quyền truy cập riêng cho chúng với các chuyển hướng tự động bị tắt. Proxy di động, đắt nhất cho mỗi gigabyte, nên được giữ trong mã với tối thiểu các phụ thuộc bên ngoài và chắc chắn kiểm tra phiên bản thư viện trong mỗi lần biên dịch.

Kết luận

Mật khẩu của proxy có thể bị rò rỉ mà không cần hack, không cần virus và không cần lỗi của con người: chỉ cần libcurl lỗi thời, chuyển hướng đến miền khác và kết nối được tái sử dụng. Danh sách kiểm tra ngắn gọn: curl và libcurl từ 8.21.0, requests từ 2.31.0, urllib3 từ 1.26.19 hoặc 2.2.2, libsoup mới, phiên riêng cho mỗi proxy, chuyển hướng dưới sự kiểm soát và một bài kiểm tra thực tế để kiểm tra. Thêm vào đó, một quyền truy cập riêng cho mỗi dự án, để một lần rò rỉ chỉ tốn của một script, không phải toàn bộ số dư.