curl khắc phục lỗ hổng HTTP/2 nghiêm trọng cho phép thực thi mã phía client

Dự án curl đã phát hành phiên bản 8.23.0 vào ngày 14 tháng 10 để khắc phục một lỗ hổng bảo mật có mức độ nghiêm trọng cao, cho phép các máy chủ độc hại làm hỏng bộ nhớ của client trong quá trình tải lên dữ liệu qua HTTP/2. Lỗi này được theo dõi dưới mã CVE-2026-92392, do Luna Tong từ Anthropic phát hiện và ảnh hưởng đến tất cả các phiên bản curl và libcurl từ 8.12.0 đến 8.22.0.

Chuyện gì đã xảy ra

Lỗ hổng này cho phép một máy chủ bị kiểm soát bởi kẻ tấn công kích hoạt việc thực thi mã từ xa trên máy tính của client đang tải dữ liệu lên. Cuộc tấn công đòi hỏi client phải tải lên một tệp khoảng 135KB qua giao thức HTTP/2 tới một máy chủ độc hại mà chứng chỉ của nó vượt qua các bước xác thực tiêu chuẩn. Mặc dù tác động lý thuyết bao gồm khả năng chiếm quyền kiểm soát toàn bộ hệ thống, các nhà duy trì dự án curl lưu ý rằng việc khai thác thành công là rất khó khăn và trong hầu hết các kịch bản thực tế, kết quả thường dẫn đến sự cố sập ứng dụng (crash) thay vì thực thi mã.

Lỗi này đã tồn tại trong mọi bản phát hành curl kể từ phiên bản 8.12.0, được ra mắt vào tháng 2 năm 2025. Đây là lỗ hổng đầu tiên có mức độ nghiêm trọng cao đối với dự án kể từ lỗi tràn bộ nhớ heap SOCKS5 vào tháng 10 năm 2023. Để đáp lại việc phát hiện này, nhóm curl đã rút ngắn chu kỳ phát hành thông thường tám tuần xuống còn sáu tuần nhằm cung cấp bản vá kịp thời. Cho đến nay, chưa có báo cáo nào về các cuộc tấn công đang diễn ra ngoài thực tế sử dụng lỗ hổng này.

Bản vá này giải quyết tổng cộng 24 CVE, mặc dù 23 lỗi còn lại được đánh giá ở mức độ nghiêm trọng thấp. Dự án cũng cập nhật dòng hỗ trợ dài hạn, được gọi là các bản phát hành Rock-solid curl, để đồng bộ với bản vá bảo mật này. Người dùng trên các nhánh cũ được hỗ trợ nên nâng cấp lên các phiên bản đã được vá cụ thể: 8.14.3 cho nhánh 8.14.x, 8.16.2 cho 8.16.x và 8.20.2 cho 8.20.x.

Cơ chế hoạt động

Lỗ hổng là một lỗi use-after-free bắt nguồn từ cách libcurl quản lý các chuyển giao HTTP/2. HTTP/2 cho phép nhiều luồng đồng thời trên một kết nối duy nhất, và libcurl theo dõi mỗi lần chuyển giao bằng một đối tượng gọi là easy handle. Trong quá trình tải lên, một máy chủ độc hại có thể làm chậm quá trình chuyển giao bằng cách đặt kích thước cửa sổ HTTP/2 về không, trả về một phần phản hồi, sau đó thiết lập lại (reset) luồng trong khi vẫn giữ kết nối cơ sở mở. Curl hiểu thao tác reset này như một tín hiệu để thử lại quá trình chuyển giao.

Trong giai đoạn dọn dẹp của logic thử lại này, curl trước đây đã thông báo cho lớp HTTP/2 rằng quá trình chuyển giao đã hoàn tất trước khi đẩy (flush) dữ liệu tải lên còn sót lại chưa gửi. Thứ tự này có nghĩa là các byte còn lại được ghi vào một kết nối không có chuyển giao nào được đăng ký. Nếu các byte này trông giống như các dòng yêu cầu HTTP, curl sẽ mở một luồng mới và lưu trữ một con trỏ tới easy handle. Khi ứng dụng cuối cùng giải phóng handle sau khi hoàn tất việc thử lại trên một kết nối HTTP/1.1 mới, kết nối cũ vẫn giữ một con trỏ lơ lửng (dangling pointer) tới vùng nhớ đã được giải phóng đó.

Kẻ tấn công sau đó có thể gửi dữ liệu trên luồng cũ rơi vào vùng nhớ vừa được giải phóng gần đây. Bằng cách rò rỉ các địa chỉ cục bộ để vượt qua kỹ thuật ngẫu nhiên hóa bố trí không gian địa chỉ (ASLR), kẻ tấn công có thể ghi đè lên một con trỏ hàm trong vùng nhớ đó. Khi curl sau đó gọi con trỏ này, nó sẽ thực thi mã của kẻ tấn công. Bản sửa lỗi, bao gồm việc sắp xếp lại sáu dòng code trong lib/multi.c bởi Stefan Eissing, đảm bảo rằng lớp HTTP/2 chỉ giải phóng các tham chiếu của nó tới handle sau khi tất cả dữ liệu còn sót lại đã được đẩy đi.

Chi tiết chính

• Phiên bản bị ảnh hưởng: curl và libcurl từ 8.12.0 đến 8.22.0.
• Phiên bản đã sửa: Nâng cấp lên 8.23.0, hoặc 8.14.3, 8.16.2 và 8.20.2 cho các nhánh cũ hơn.
• Phương thức tấn công: Máy chủ độc hại nhận một lần tải lên HTTP/2 khoảng 135KB.
• Mức độ nghiêm trọng: Được dự án curl đánh giá là Cao; chưa có điểm CVSS được công bố.
• Phát hiện: Được báo cáo bởi Luna Tong từ Anthropic qua HackerOne vào ngày 15 tháng 9.
• Biện pháp giảm thiểu: Tắt HTTP/2 bằng cách sử dụng --http1.1 hoặc CURLOPT_HTTP_VERSION_1_1 nếu không thể vá ngay lập tức.

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

Đối với các kỹ sư phần mềm và đội ngũ DevOps, sự cố này nhấn mạnh những rủi ro tiềm ẩn trong các thư viện hạ tầng được sử dụng rộng rãi. Curl được nhúng trong vô số ứng dụng, từ các script dòng lệnh cho đến các dịch vụ backend phức tạp. Vì libcurl mặc định thương lượng HTTP/2 cho các URL HTTPS khi máy chủ hỗ trợ, nhiều ứng dụng có thể dễ bị tổn thương mà không cần thay đổi cấu hình rõ ràng. Việc lỗ hổng đòi hỏi một môi trường xây dựng cụ thể và thời điểm chính xác để khai thác không phủ nhận rủi ro, đặc biệt là đối với các cuộc tấn công nhắm mục tiêu vào hạ tầng đã biết.

Quá trình phát hiện cũng báo hiệu một sự thay đổi trong cách tìm kiếm các lỗ hổng bảo mật mã nguồn mở. Người báo cáo đã sử dụng OSS Scanner của Anthropic, một công cụ chạy bằng AI quét các dự án mã nguồn mở và gửi email kết quả mà không cần xem xét thủ công. Điều này đặt ra câu hỏi về tương lai của nghiên cứu lỗ hổng, khi các mô hình AI trở nên đủ khả năng để xác định các lỗi hỏng bộ nhớ phức tạp mà fuzzing truyền thống có thể bỏ sót. Tuy nhiên, nó cũng tạo ra nhiễu, vì các nhà duy trì dự án đã ghi nhận sự gia tăng của các báo cáo chất lượng thấp do AI tạo ra.

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

• Kiểm tra phiên bản curl hiện tại của bạn bằng cách chạy curl --version và nâng cấp ngay lập tức lên 8.23.0 hoặc phiên bản nhánh đã được vá.
• Nếu bạn không thể cập nhật ngay, hãy buộc sử dụng HTTP/1.1 trong các ứng dụng của bạn bằng cách đặt CURLOPT_HTTP_VERSION thành CURL_HTTP_VERSION_1_1.
• Xác minh xem bản build libcurl của bạn có bao gồm hỗ trợ HTTP/2 hay không; nếu không, bạn không bị ảnh hưởng bởi lỗ hổng cụ thể này.
• Theo dõi các tracker bảo mật Debian nếu bạn sử dụng Debian 13 (trixie), phiên bản này đã nhận bản vá 8.14.1-2+deb13u7 thông qua DSA-6558-1.
• Xem xét lại bất kỳ container Docker tùy chỉnh hoặc pipeline CI/CD nào đóng gói các phiên bản curl cũ hơn cho việc truyền tệp.
• Cân nhắc tắt HTTP/2 trong các dịch vụ nội bộ nơi nó không bắt buộc phải có, nhằm giảm bề mặt tấn công.