Một JWT, hai CVE, và hàng loạt hệ thống bị mở cửa sau lưng quản trị viên

Tổng quan

Trong các hệ thống quản lý danh tính hiện đại, JWT được xem là “chứng chỉ niềm tin” - một khi chữ ký hợp lệ, hệ thống thường mặc định rằng danh tính bên trong token cũng đáng tin cậy. Nhưng điều gì sẽ xảy ra nếu niềm tin đó không còn đúng, trong khi hệ thống vẫn tiếp tục cấp quyền?

Hai lỗ hổng CVE-2026-1486 và CVE-2026-1529 trong Keycloak đã phơi bày một vấn đề nguy hiểm hơn cả lỗi mã nguồn hay tràn bộ nhớ: lỗi logic trong quyết định tin cậy. Không cần khai thác phức tạp, không cần tương tác người dùng, kẻ tấn công chỉ cần một JWT “được ký đúng cách” - ngay cả khi danh tính phát hành token đó đã bị vô hiệu hóa hoặc không còn được phép.

Bài viết này phân tích chi tiết cách hai lỗ hổng trên hoạt động, vì sao chúng đặc biệt nguy hiểm trong môi trường doanh nghiệp sử dụng SSO và IdP bên ngoài, và cách Keycloak 26.5.3 đã vá lại những sai lệch tưởng như “nhỏ” nhưng có thể dẫn tới unauthorized access ở quy mô lớn.

Giời thiệu về Keycloak

Tổng quan về Keycloak

Keycloak là một nền tảng Identity and Access Management (IAM) mã nguồn mở, được phát triển bởi Red Hat, nhằm giải quyết bài toán xác thực và phân quyền tập trung cho các hệ thống hiện đại. Thay vì mỗi ứng dụng tự xử lý đăng nhập, quản lý mật khẩu và quyền truy cập, Keycloak sẽ đóng vai trò là trung tâm định danh, giúp đơn giản hóa và chuẩn hóa toàn bộ luồng xác thực.
Keycloak hỗ trợ đầy đủ các chuẩn phổ biến như OAuth 2.0, OpenID Connect (OIDC) và SAML 2.0, cho phép tích hợp linh hoạt với ứng dụng web, mobile, API và microservices. Nhờ đó, các hệ thống có thể triển khai Single Sign-On (SSO), federated identity, và centralized access control mà không cần tự xây dựng cơ chế bảo mật phức tạp từ đầu.
Một trong những điểm mạnh cốt lõi của Keycloak là khả năng liên kết với nhiều Identity Provider (IdP) khác nhau, bao gồm LDAP, Active Directory, hoặc các IdP bên thứ ba như Google, GitHub, Azure AD.

Dịch vụ của Keycloak

Keycloak cung cấp một tập hợp dịch vụ toàn diện để quản lý xác thực, phân quyền và danh tính người dùng.

Xác thực và Single Sign-On (SSO)
Quản lý danh tính người dùng (User Identity Management)
Phân quyền và kiểm soát truy cập (Authorization Services)
Liên kết và liên đoàn danh tính (Identity Federation)
Hỗ trợ chuẩn OAuth 2.0, OpenID Connect và SAML
Quản lý token và phiên làm việc
Quản trị, giám sát và audit
Hỗ trợ mở rộng và tích hợp

Chi tiết lỗ hổng

Mô tả lỗ hổng

CVE-2026-1486

Mô tả: Lỗ hổng bảo mật nghiêm trọng trong Keycloak, liên quan đến việc xử lý không đúng logic xác thực trong luồng JWT Authorization Grant (theo chuẩn OAuth 2.0 – RFC 7523).
CVSS score: 8.8
Mức độ nghiêm trọng: High
Ảnh hưởng: Nếu truy cập thành công kẻ tấn công có thể truy cập tài nguyên được Keycloak bảo vệ.

CVE-2026-1529

Mô tả: Lỗ hổng bảo mật trong Keycloak, xuất phát từ việc xác thực không đầy đủ các invitation token dựa trên JWT được sử dụng trong quá trình mời và đăng ký người dùng vào một organization hoặc phạm vi quản lý tương đương.
CVSS score: 8.1
Mức độ nghiêm trọng: High
Ảnh hưởng: Nếu bị khai thác, lỗ hổng này có thể dẫn đến: Unauthorized self-registration, truy cập trái phép vào dữ liệu và tài nguyên của tổ chức hoặc vi phạm mô hình phân tách tenant trong các hệ thống đa tổ chức (multi-tenant).

Phạm vi ảnh hưởng

CVE-2026-1486

Ảnh hưởng đến:
- Tất cả các phiên bản Keycloak trước 26.5.3
Bao gồm:
- Keycloak upstream (community)
- Red Hat Build of Keycloak (RHBK)
Không bị ảnh hưởng:
- Keycloak 26.5.3 trở lên

CVE-2026-1529

Ảnh hưởng đến:
- Tất cả các phiên bản Keycloak trước 26.5.3
Bao gồm:
- Các phiên bản có hỗ trợ organization / invitation flow
Không bị ảnh hưởng:
- Keycloak 26.5.3 trở lên

Chi tiết lỗ hổng

Đầu tiên như đã đề cập thì cả hai lỗ hổng CVE-2026-1486 và CVE-2026-1529 tuy nằm ở hai chức năng khác nhau của Keycloak (JWT Authorization Grant và Invitation Flow), nhưng chia sẻ cùng một bản chất cốt lõi:

Keycloak xác thực token đúng về mặt kỹ thuật, nhưng đưa ra quyết định tin cậy sai về mặt ngữ cảnh và vòng đời
Từ đây mà kẻ tấn công có thể lựa những điều mà hệ thống coi là hợp lệ để tiến hành khai thác.

Giai đoạn đầu tiên là thăm dò hệ thống với một mục tiêu là: Hệ thống có sử dụng Keycloak, dựa vào JWT làm đơn vị tin cậy và có các trust boundary động (IdP, invitation, organization).

Khi đã xác định được mục tiêu cụ thể, kẻ tấn công sẽ chuyển qua một giai đoạn tiếp theo được gọi là Trust Surface Mapping. Attacker không tìm bug kỹ thuật, mà tìm điểm mà niềm tin có thể “lỗi thời” hoặc “mất ràng buộc”. Sẽ có hai trust chính

Nếu đọc xong phần trên mà bạn chưa hiểu trust là gì? Thì trong bối cảnh Keycloak / IAM / OAuth / JWT, trust (niềm tin) là: Quyết định của hệ thống rằng “Thông tin này đáng tin và có thể dùng để cấp quyền truy cập”. Đầu tiên kẻ tấn công sẽ xác định Identity Provider từng tồn tại:

Hệ thống từng tích hợp IdP bên ngoài.
JWT issuer có domain khác realm nội bộ.
Có nhiều issuer khác nhau trong các token đã quan sát.

Sau bước này kẻ tấn công sẽ thực hiện chuẩn bị các Token đã được chỉnh sửa để tiến hành khai thác:

Đúng chuẩn.
Đúng cấu trúc.
Nhưng không còn đúng ngữ cảnh tin cậy.

Token sau đó được gửi tới Keycloak qua:

OAuth token endpoint (JWT Authorization Grant)
Invitation accept / registration endpoint

Đến bước kiểm tra của Keycloak, đây cũng là điểm cốt lõi của vấn đề, Keycloak sẽ thực hiện tra như sau:

Token có đúng chuẩn không?

Chữ ký có hợp lệ không?
Nhưng không kiểm tra đầy đủ:
- Trạng thái hiện tại của IdP (CVE-1486).
- Ràng buộc ngữ cảnh invitation (CVE-1529).

Và đương nhiên khi đã kiểm tra như vậy thì hậu quả sẽ đến với hệ thống của nạn nhân, Attacker có: Access token hợp lệ hoặc tài khoản hợp lệ trong organization

Hậu quả để lại

Ảnh hưởng ở cấp độ xác thực (Authentication Layer)

Bypass xác thực.
Giả mạo người dùng hợp lệ.
Giả mạo vai trò (role escalation).

Leo thang đặc quyền (Privilege Escalation)

Thay đổi cấu hình hệ thống.
Tạo user backdoor.
Cấp quyền admin vĩnh viễn.
Xuất toàn bộ user database.

Phá vỡ mô hình Trust Boundary

Cross-realm trust abuse.
Client impersonation.
Token reuse ngoài phạm vi cho phép.

Ảnh hưởng lan rộng (Lateral Movement)

Truy cập dữ liệu nhạy cảm
Chiếm quyền hệ thống nội bộ
Pivot sang hạ tầng khác

Kết luận

Hai lỗ hổng CVE-2026-1486 và CVE-2026-1529 trong Keycloak không phải là những lỗi kỹ thuật ồn ào như tràn bộ nhớ hay thực thi mã từ xa, nhưng lại nguy hiểm hơn ở một khía cạnh khác: chúng làm sai lệch các quyết định tin cậy cốt lõi của hệ thống xác thực.

Trong CVE-2026-1486, Keycloak tiếp tục tin tưởng và cấp quyền cho JWT đến từ một Identity Provider đã bị vô hiệu hóa, chỉ vì chữ ký token vẫn hợp lệ. Điều này phá vỡ giả định quan trọng rằng việc disable IdP đồng nghĩa với việc chấm dứt niềm tin. Còn với CVE-2026-1529, quá trình xác thực invitation token không được thực hiện đầy đủ, mở ra khả năng tự đăng ký trái phép vào tổ chức, vượt qua các rào cản quản trị được thiết kế để kiểm soát onboarding.

Khuyến nghị

Nâng cấp phiên bản (BẮT BUỘC)
- Nâng cấp Keycloak lên phiên bản 26.5.3 hoặc cao hơn
- Áp dụng cho:
  - Keycloak upstream (community)
  - Red Hat Build of Keycloak (RHBK)
Đối với CVE-2026-1486 – JWT Authorization Grant
- Kiểm tra danh sách các Identity Provider đã từng bị disable:
  - External IdP
  - OIDC / JWT-based IdP
- Với mỗi IdP đã disable:
  - Rotate hoặc thu hồi signing keys
  - Đảm bảo key cũ không còn được tin cậy ở bất kỳ hệ thống nào
Đối với CVE-2026-1529 – Invitation Token
- Kiểm tra xem hệ thống có sử dụng:
  - Organization
  - Invitation-based onboarding
- Nếu có:
  - Xem lại các tài khoản được tạo thông qua invitation token
  - Đặc biệt chú ý các user có:
    - Organization ID không khớp logic vận hành
    - Email không thuộc domain mong đợi
Tăng cường kiểm soát vận hành (Defense-in-Depth)
- Bật và theo dõi các sự kiện:
  - Token issuance
  - Organization join
  - Authentication via JWT grant
- Tích hợp log Keycloak với:
  - SIEM
  - SOC monitoring

Một JWT, hai CVE, và hàng loạt hệ thống bị mở cửa sau lưng quản trị viên

Tổng quan