# 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**

![](https://miro.medium.com/v2/resize:fit:1358/0*9Xl-yWj7LPr_HDdF align="center")

### **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**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1770951473292/ccf44d2c-974a-4d8d-a6c0-cefb21cb34cd.png align="center")

Đầ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.**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1771304154709/1ca4a366-4e72-41b9-bee7-1b1066f1f814.png align="center")

**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ị**

1. **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)
            
2. **Đố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
            
3. **Đố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
                
4. **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
            

## **Tham khảo**

1. [CVE-2026-1486 - Red Hat Customer Portal](https://access.redhat.com/security/cve/cve-2026-1486)
    
2. [CVE-2026-1529 - Red Hat Customer Portal](https://access.redhat.com/security/cve/cve-2026-1529)
    
3. [Keycloak](https://www.keycloak.org/)