Authlib CVE-2026-96760: JWS rỗng có thể bỏ qua xác thực

Một API có thể xác minh token đúng trong các bài kiểm thử thông thường nhưng vẫn chấp nhận cấu trúc hiếm gặp mà không có chữ ký. Với Authlib, trường hợp mảng signatures rỗng trong JWS JSON có thể đi qua logic kiểm tra và trả payload như đã xác minh. Nếu payload mang vai trò hoặc danh tính, hậu quả có thể là bỏ qua xác thực.

GitHub Advisory Database duyệt CVE-2026-96760 ngày 27/10/2026. Bài này dành cho đội phát triển Python và quản trị VPS đang vận hành OAuth, OpenID Connect hoặc API dùng JWS.

Phạm vi bị ảnh hưởng

Theo GitHub Advisory GHSA-6v38-4h7w-rj9h, gói authlib đến và gồm phiên bản 1.8.0 bị ảnh hưởng. Phiên bản vá là 1.9.0. Cảnh báo được đánh giá Critical vì một bên gọi JsonWebSignature.deserialize_json() trên dữ liệu không tin cậy có thể nhận payload do kẻ tấn công tạo mà không cần khóa.

Không phải mọi ứng dụng dùng Authlib đều nằm trong đường lỗi. Điều kiện quan trọng là ứng dụng nhận JWS dạng JSON Serialization và gọi đúng API deserialize_json trên input bên ngoài. Ứng dụng chỉ dùng compact JWT qua đường kiểm tra khác cần được kiểm tra riêng, không nên kết luận từ tên thư viện.

Lỗi xảy ra như thế nào?

Trong logic cũ, cờ kết quả bắt đầu ở trạng thái hợp lệ. Vòng lặp chỉ đổi cờ khi kiểm tra từng chữ ký thất bại. Nếu mảng signatures tồn tại nhưng rỗng, vòng lặp không chạy, nên payload được trả về như đã xác minh. Đây là lỗi kiểm tra trường hợp biên, không phải khóa mật mã bị bẻ.

Vì các token có chữ ký hợp lệ vẫn hoạt động và chữ ký sai thông thường vẫn bị từ chối, bộ kiểm thử chỉ gồm mẫu hợp lệ và mẫu sửa một byte có thể bỏ sót. Cần thêm trường hợp mảng rỗng, trường thiếu và kiểu dữ liệu sai.

Rủi ro với API và dịch vụ đăng nhập

• Payload JWS chứa sub, vai trò hoặc phạm vi quyền được dùng trực tiếp để tạo phiên.
• Gateway tin kết quả Authlib rồi chuyển thông tin danh tính tới dịch vụ phía sau.
• Dịch vụ nhận JWS JSON từ webhook, đối tác hoặc client mà không kiểm tra số lượng chữ ký trước.
• Tiến trình xác minh chạy với quyền truy cập dữ liệu nhạy cảm và không có lớp phân quyền bổ sung.
• Log chỉ ghi kết quả thành công, không ghi định dạng token hoặc số chữ ký.

Checklist vá và xác minh

1. Tìm phiên bản Authlib trong image, virtualenv và lockfile; xác định dịch vụ nào gọi JsonWebSignature.deserialize_json.
2. Nâng lên Authlib 1.9.0 hoặc mới hơn trong nhánh riêng, chạy toàn bộ bài kiểm thử đăng nhập, refresh token, webhook và logout.
3. Thêm test bắt buộc từ chối JWS JSON có signatures: [], trường signatures bị thiếu và chữ ký sai.
4. Không tin vai trò trong payload chỉ vì bước giải mã thành công; kiểm tra issuer, audience, thời hạn và chính sách phân quyền.
5. Triển khai canary, theo dõi lỗi xác thực tăng lên và xác minh đó là token không hợp lệ chứ không phải hồi quy của ứng dụng.
6. Rà log lịch sử nếu endpoint nhận JWS JSON từ bên ngoài, tập trung vào phiên có vai trò bất thường hoặc payload thiếu metadata.
7. Quay vòng khóa hoặc hủy phiên khi có bằng chứng token giả đã được chấp nhận; advisory không xác nhận khai thác thực tế.

Nếu chưa thể nâng ngay

Có thể thêm kiểm tra ở lớp ứng dụng để từ chối mọi JWS JSON không có ít nhất một chữ ký trước khi gọi Authlib, đồng thời giới hạn endpoint tại gateway. Đây chỉ là giảm thiểu tạm thời. Bản vá thư viện vẫn cần được đưa vào image và triển khai lại.

Nếu ứng dụng chạy nhiều bản sao, hãy thay đồng bộ để tránh một số request vẫn rơi vào replica cũ. Sau triển khai, xác minh package thực tế bên trong container và không dựa vào tên tag image.

Bài học thiết kế cho đội Việt Nam

Xác thực token là chuỗi kiểm tra, không phải một lời gọi hàm duy nhất. Sau chữ ký còn có issuer, audience, thời hạn, nonce và phân quyền nghiệp vụ. Một lỗi thư viện không nên tự động biến thành quyền quản trị nếu hệ thống có các lớp kiểm tra độc lập.

Đội đang vận hành API Python trên Cloud VPS có thể gửi phiên bản Python, Authlib, cách nhận token, số replica và yêu cầu canary tới hotro@thuemaychu.vn để trao đổi kế hoạch môi trường thử nghiệm. Không gửi token thật, khóa ký hoặc dữ liệu người dùng qua email.

Nguồn tham khảo