CVE-2026-65633 in ash_authentication
Tóm tắt
Bởi VulDB • 25/08/2026
Lỗ hổng Xác thực không đúng cách (Improper Authentication) trong AshAuthentication của team-alembic cho phép các JWT có mục đích hạn chế được phát lại dưới dạng thông tin xác thực API bearer đầy đủ khi một tài nguyên sử dụng cơ chế xác minh token bearer stateless.
Trình trợ giúp xác thực token bearer `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` kiểm tra chữ ký của Authorization: Bearer JWT và từ chối các token chứa claim `act`, nhưng không thực hiện bất kỳ kiểm tra nào để đảm bảo rằng claim mục đích (purpose) của token bằng "user" tại ranh giới bearer. Khi tài nguyên được cấu hình với `require_token_presence_for_authentication?: false` (mặc định DSL), trình trợ giúp `validate_token/3` tiếp theo sẽ trả về `{:ok, nil}` mà không tham chiếu đến nguồn token, do đó cũng không có bất kỳ kiểm tra nào về mục đích ở các lớp phía dưới. Kết quả là, bất kỳ JWT hợp lệ và chưa hết hạn nào do chính thư viện phát hành cho một luồng đơn lẻ với mục đích hẹp (nổi bật nhất là token `purpose: sign_in` mà WebAuthn luôn tạo ra trong quá trình đăng nhập, cũng như Password strategy khi các token đăng nhập được kích hoạt) sẽ được chấp nhận trực tiếp dưới dạng thông tin xác thực bearer đa năng và phân giải thành việc gán `current_user` đầy đủ.
Điều này bỏ qua hợp đồng trao đổi token dự kiến của thư viện, theo đó token sign_in phải được trình bày đúng một lần cho quá trình chuẩn bị nhằm kiểm tra claim mục đích và ngay lập tức thu hồi token. Việc sử dụng đầu tiên của một token đăng nhập còn hạn chế được trình bày trực tiếp trong tiêu đề Authorization sẽ thành công vì đường dẫn bearer stateless không giới hạn nó với `purpose == "user"`.
Một kẻ tấn công có thể lấy được token sign-in chưa được trao đổi cho đối tượng mục tiêu (ví dụ: qua rò rỉ log hoặc referrer, kênh phân phối magic-link bị chặn bắt, hoặc trung gian bị xâm nhập một phần) và trình bày nó dưới dạng token bearer để xác thực với tư cách là đối tượng đó, hoàn toàn bỏ qua các ngữ nghĩa sử dụng một lần và thu hồi dự kiến. Việc khai thác lỗ hổng này cũng yêu cầu ứng dụng chủ phải kết nối `retrieve_from_bearer/3` trên một route có thể truy cập và sử dụng WebAuthn (token đăng nhập luôn được phát hành) hoặc Password strategy với `sign_in_tokens_enabled?: true`. Các tài nguyên được cấu hình với `require_token_presence_for_authentication?: true` (bao gồm các ứng dụng do Igniter installer tạo từ v4.5.0 trở đi) và đường dẫn dựa trên phiên (`authenticate_resource_from_session/4`) sẽ thực thi kiểm tra `purpose == "user"` đối với bản ghi token đã lưu trữ và không bị ảnh hưởng.
Vấn đề này ảnh hưởng đến ash_authentication: từ 3.10.5 trước 4.14.2 và từ 5.0.0-rc.0 trước 5.0.0-rc.13.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.