CVE-2026-0073: Android 0-Click RCE
Tóm tắt
Đầu tháng 5 này, Google đã phát hành bản vá bảo mật cho hệ điều hành Android, trong đó đã vá lỗ hổng CVE-2026-0073 — một lỗi logic khi hệ thống Android xác thực kết nối ADB không dây, cho phép kẻ tấn công cùng mạng nội bộ thực thi mã lệnh từ xa (RCE) trên thiết bị mục tiêu mà không cần bất kỳ thao tác xác nhận nào từ phía người dùng tại thời điểm bị tấn công.
Bối cảnh
Ngày 1/5/2026, Google chính thức công bố bản vá bảo mật định kỳ cho Android, đi kèm với thông tin chi tiết về lỗ hổng CVE-2026-0073: Android Zero-Click RCE via Wireless ADB Bypass được đánh giá ở mức High (Cao) với điểm CVSS 8.8/10 theo NIST.
Điểm đáng chú ý là lỗi nằm trong thành phần ADB daemon (adbd) — một phần lõi của hệ thống Android, không phải ở lớp ứng dụng hay thư viện bên thứ ba. Điều này đồng nghĩa với việc mọi thiết bị chạy Android — từ smartphone, máy tính bảng, đến đồng hồ thông minh, tivi, và các thiết bị nhúng — đều có khả năng bị ảnh hưởng, bất kể nhà sản xuất.
Thông tin lỗ hổng
| Thuộc tính | Chi tiết |
|---|---|
| CVE ID | CVE-2026-0073 |
| Mức độ nguy hiểm | High (Cao) |
| Điểm CVSS | 8.8 (CVSS v3.1) |
| Thành phần bị ảnh hưởng | Android ADB daemon (adbd) — tệp auth.cpp |
| Hàm có lỗi | adbd_tls_verify_cert |
| Loại lỗi | Bypass Authentication |
| Hậu quả | Remote Code Execution (RCE) |
| Điều kiện khai thác | Mạng cục bộ, Wireless Debugging đã bật, đã ghép nối ADB trước đó |
| Tương tác người dùng | Không cần (tại thời điểm tấn công) |
| Bản vá | Android Security Patch Level 2026-05-01 |
Phạm vi ảnh hưởng
Do ADB daemon là thành phần trong nhân hệ điều hành Android, lỗ hổng CVE-2026-0073 ảnh hưởng đến các phiên bản Android mới nhất tại thời điểm công bố, bao gồm Android 14, 15 và 16. Các thiết bị chạy phiên bản Android cũ đã hết vòng đời hỗ trợ cập nhật cũng có thể bị ảnh hưởng nhưng sẽ không nhận được bản vá.
Bởi vì Android là nền tảng mã nguồn mở, các nhà sản xuất thiết bị (OEM) như Samsung, Xiaomi, OPPO, và các hãng khác đều dựa trên cùng một codebase lõi. Mặc dù mỗi nhà sản xuất có thể thêm tùy chỉnh riêng, nhưng thành phần adbd và logic xác thực ADB thường được giữ nguyên hoặc thay đổi không đáng kể. Do đó, thiết bị của bất kỳ hãng nào cũng đều là đối tượng có thể bị nhắm đến.
Điều kiện để khai thác
Cụm từ "Zero-Click" trong tên lỗ hổng cần được hiểu chính xác: đây là lỗ hổng không yêu cầu bất kỳ thao tác tương tác nào từ người dùng tại thời điểm bị tấn công. Tuy nhiên, để khai thác thành công, kẻ tấn công cần thiết bị mục tiêu đáp ứng các điều kiện tiên quyết sau:
- Cùng mạng cục bộ: Thiết bị của kẻ tấn công và thiết bị Android mục tiêu phải kết nối cùng một mạng (Wi-Fi công cộng, mạng nội bộ doanh nghiệp, hotspot,...).
- Wireless Debugging đã được kích hoạt: Người dùng phải đã bật chế độ nhà phát triển (Developer Options) và tính năng Gỡ lỗi không dây (Wireless Debugging / ADB qua TCP).
- Từng ghép nối ADB trước đó: Thiết bị của kẻ tấn công phải từng được ghép nối ADB với thiết bị mục tiêu ít nhất một lần.
Những điều kiện này giới hạn đáng kể số lượng thiết bị có thể bị tấn công trong thực tế. Đa số người dùng phổ thông không biết đến ADB, và ít ai chủ động bật Wireless Debugging. Tuy nhiên, trong môi trường doanh nghiệp, phòng phát triển phần mềm, hoặc các thiết bị được kỹ thuật viên cài đặt sẵn, điều kiện này có thể được đáp ứng.
Ngoài ra, theo một số thông tin, các thiết bị Android xách tay được bán tại Việt Nam, trước khi bán ra, thường được các kỹ thuật viên của cửa hàng cài đặt lại cấu hình để đảm bảo vấn đề SIM sóng hoạt động ổn. Trong quá trình này, có thể thiết bị đã được bật chế độ nhà phát triển và tính năng Gỡ lỗi không dây, nhưng sau đó có thể kỹ thuật viên quên tắt đi. Do đó các thiết bị Android xách tay có nguy cơ bị tấn công cao hơn.
Phân tích kỹ thuật
ADB và Wireless Debugging là gì?
Android Debug Bridge (ADB) là công cụ giao tiếp dòng lệnh cho phép lập trình viên và kỹ thuật viên tương tác trực tiếp với thiết bị Android — cài đặt ứng dụng, đọc log, thực thi lệnh shell, và nhiều thao tác khác. Tính năng Wireless Debugging (ADB qua TCP/IP) là phần mở rộng cho phép thực hiện toàn bộ những thao tác đó qua kết nối Wi-Fi, thay vì cáp USB.
Kể từ Android 11, Google đã tích hợp cơ chế xác thực TLS mutual authentication vào kết nối ADB không dây để tăng cường bảo mật: cả hai phía (thiết bị Android và máy tính) đều phải xuất trình chứng chỉ TLS hợp lệ và khớp với danh sách đã ghép nối từ trước. CVE-2026-0073 là lỗi trong chính cơ chế xác thực được xem là an toàn này.
Luồng kết nối ADB không dây
Lỗi logic xảy ra tại bước 3.2 — giai đoạn xác thực khóa RSA.
Phân tích mã nguồn có lỗi
Tệp tin có lỗ hổng: platform/packages/modules/adb/daemon/auth.cpp
Hàm adbd_tls_verify_cert có nhiệm vụ xác minh chứng chỉ TLS của máy tính kết nối bằng cách so sánh khóa công khai trong chứng chỉ với danh sách các khóa đã được ghép nối và lưu trữ:
int adbd_tls_verify_cert(X509_STORE_CTX* ctx, std::string* auth_key) {
if (!auth_required) {
// Any key will do.
VLOG(AUTH) << __func__ << ": auth not required";
return 1;
}
bool authorized = false;
X509* cert = X509_STORE_CTX_get0_cert(ctx);
if (cert == nullptr) {
VLOG(AUTH) << "got null x509 certificate";
return 0;
}
bssl::UniquePtr<EVP_PKEY> evp_pkey(X509_get_pubkey(cert));
if (evp_pkey == nullptr) {
VLOG(AUTH) << "got null evp_pkey from x509 certificate";
return 0;
}
IteratePublicKeys([&](std::string_view public_key) {
std::vector<std::string> split = android::base::Split(std::string(public_key), " \t");
uint8_t keybuf[ANDROID_PUBKEY_ENCODED_SIZE + 1];
const std::string& pubkey = split[0];
if (b64_pton(pubkey.c_str(), keybuf, sizeof(keybuf)) != ANDROID_PUBKEY_ENCODED_SIZE) {
LOG(ERROR) << "Invalid base64 key " << pubkey;
return true;
}
RSA* key = nullptr;
if (!android_pubkey_decode(keybuf, ANDROID_PUBKEY_ENCODED_SIZE, &key)) {
LOG(ERROR) << "Failed to parse key " << pubkey;
return true;
}
bool verified = false;
bssl::UniquePtr<EVP_PKEY> known_evp(EVP_PKEY_new());
EVP_PKEY_set1_RSA(known_evp.get(), key);
if (EVP_PKEY_cmp(known_evp.get(), evp_pkey.get())) { // <-- LỖI Ở ĐÂY
VLOG(AUTH) << "Matched auth_key=" << public_key;
verified = true;
} else {
VLOG(AUTH) << "auth_key doesn't match [" << public_key << "]";
}
RSA_free(key);
if (verified) {
*auth_key = public_key;
authorized = true;
return false;
}
return true;
});
return authorized ? 1 : 0;
}
Nguyên nhân gốc rễ (Root Cause)
Lỗi nằm ở đoạn code so sánh khoá công khai RSA sử dụnh hàm EVP_PKEY_cmp:
if (EVP_PKEY_cmp(known_evp.get(), evp_pkey.get())) {
VLOG(AUTH) << "Matched auth_key=" << public_key;
verified = true;
}
Hàm EVP_PKEY_cmp không trả về giá trị boolean thông thường mà trả về một trong bốn giá trị nguyên sau:
| Giá trị trả về | Ý nghĩa |
|---|---|
1 |
Hai khóa giống hệt nhau (xác thực thành công — hợp lệ) |
0 |
Cùng thuật toán, nhưng khóa khác nhau (xác thực thất bại — hợp lệ) |
-1 |
Hai khóa thuộc thuật toán khác nhau (lỗi so sánh — không mong đợi) |
-2 |
Lỗi nội bộ khi so sánh (lỗi hàm — không mong đợi) |
Trong ngôn ngữ C/C++, biểu thức if (n) chỉ nhận 1 trong hai giá trị là true hoặc false, trong đó n==0 tương đương với false, mọi giá trị khác 0 — bao gồm cả -1 và -2 — đều được coi là true.
Do đó:
- Máy tính gửi RSA public key không có trong
/data/misc/adb/adb_keys→EVP_PKEY_cmptrả về0→if (0)làfalse→ Xác thực thất bại (đúng hành vi) - Máy tính gửi public key không phải RSA (ví dụ: khóa EC - Elliptic Curve) →
EVP_PKEY_cmptrả về-1(thuật toán khác nhau) →if (-1)làtrue→ Xác thực thành công (lỗ hổng xảy ra tại đây)
Điều khiến CVE-2026-0073 đáng chú ý là nó tồn tại trong cơ chế xác thực được thiết kế lại từ Android 11 với mục đích khắc phục các điểm yếu của ADB truyền thống. Lỗi xuất phát từ sự không khớp về ngữ nghĩa giữa hàm so sánh và cách sử dụng hàm đó — một loại lỗi rất phổ biến trong lập trình nhưng lại cực kỳ khó phát hiện qua code review thông thường.
Đây cũng là lời nhắc nhở về tầm quan trọng của việc đọc kỹ tài liệu API, đặc biệt với các hàm trả về nhiều giá trị nguyên có ý nghĩa phân biệt, thay vì chỉ xử lý như boolean đơn giản.
Kịch bản khai thác
Với lỗi này, kẻ tấn công có thể thực hiện cuộc tấn công theo trình tự:
- Chuẩn bị: Tạo một chứng chỉ TLS sử dụng khóa công khai dạng EC (Elliptic Curve) thay vì RSA.
- Kết nối: Từ máy tính trong cùng mạng nội bộ, gửi yêu cầu kết nối ADB tới cổng Wireless Debugging của thiết bị mục tiêu, đính kèm chứng chỉ EC vừa tạo.
- Vượt xác thực: Hàm
adbd_tls_verify_certgọiEVP_PKEY_cmpđể so sánh khóa EC với từng khóa RSA trongadb_keys. Vì thuật toán khác nhau, hàm trả về-1→ điều kiệnifđược đánh giá làtrue→ thiết bị chấp nhận kết nối. - Thực thi lệnh: Sau khi kết nối ADB được thiết lập, kẻ tấn công chạy
adb shellđể có được phiên shell trực tiếp trên thiết bị Android — với quyền tương đương người dùngshell, có thể leo thang lênroottrên các thiết bị đã root. - Hậu khai thác: Cài đặt phần mềm gián điệp (spyware), đánh cắp dữ liệu nhạy cảm, theo dõi hoạt động người dùng, hoặc duy trì truy cập lâu dài.
Toàn bộ quá trình từ bước 2 đến bước 4 diễn ra hoàn toàn trong im lặng — không có thông báo nào hiển thị trên thiết bị Android, người dùng không hề hay biết.
Tham khảo POC: CVE-2026-0073-Android-adbd-authentication-bypass-POC
Vì sao lại gọi là "Zero-Click"?
Thuật ngữ "Zero-Click" trong bảo mật có nghĩa là cuộc tấn công không yêu cầu bất kỳ hành động tương tác nào từ nạn nhân tại thời điểm xảy ra tấn công — khác với các lỗ hổng phishing hay social engineering yêu cầu nạn nhân nhấp vào liên kết, mở tệp đính kèm, hoặc cài đặt ứng dụng độc hại.
CVE-2026-0073 đúng nghĩa là "zero-click" ở điểm này: một khi các điều kiện tiên quyết đã được đáp ứng, kẻ tấn công có thể chiếm quyền điều khiển thiết bị mà nạn nhân không cần làm bất cứ điều gì. Không có cửa sổ xác nhận, không có thông báo, không có dấu hiệu bất thường nào hiển thị với người dùng.
Điều này phân biệt CVE-2026-0073 với nhóm lỗ hổng phổ biến hơn như các lỗi trong trình duyệt hay ứng dụng nhắn tin — vốn cũng được gọi là "zero-click" nhưng thường khai thác thông qua dữ liệu độc hại được gửi đến thiết bị (tin nhắn, ảnh, video...). Ở đây, vector tấn công là giao thức kết nối cấp hệ điều hành.
Đánh giá mức độ rủi ro thực tế
Mặc dù điểm CVSS ở mức 8.8 (High), mức độ rủi ro trong thực tế phụ thuộc nhiều vào đối tượng:
Người dùng phổ thông: Rủi ro thấp. Tuyệt đại đa số người dùng không biết đến ADB và không bao giờ bật Developer Options hay Wireless Debugging. Các thiết bị này hoàn toàn không nằm trong phạm vi khai thác của lỗ hổng.
Lập trình viên / Kỹ thuật viên Android: Rủi ro trung bình đến cao. Đây là nhóm thường xuyên sử dụng ADB và có thể để Wireless Debugging bật khi làm việc. Việc kết nối vào các mạng Wi-Fi công cộng trong khi ADB đang mở là tình huống nguy hiểm.
Thiết bị trong môi trường doanh nghiệp và phát triển: Rủi ro cao. Các thiết bị test, thiết bị trình diễn, hoặc thiết bị được IT bộ phận cấu hình sẵn để debug có khả năng đã bật Wireless Debugging và đã ghép nối với nhiều máy tính trong nội bộ.
Thiết bị Android nhúng (IoT, kiosk, POS,...): Rủi ro cao. Nhiều thiết bị trong nhóm này chạy Android tùy biến và có thể được cài đặt với Wireless Debugging bật sẵn để tiện bảo trì từ xa. Đây là nhóm đặc biệt dễ bị bỏ qua khi vá lỗi.
Khuyến nghị
Với người dùng cá nhân
- Không tự làm gì thêm nếu chưa bao giờ bật Developer Options — thiết bị đã an toàn.
- Cập nhật bản vá bảo mật Android tháng 5/2026 ngay khi có thông báo từ nhà sản xuất.
- Nếu đã từng bật Wireless Debugging: tắt ngay nếu không còn sử dụng, kiểm tra danh sách thiết bị đã ghép nối ADB trong Settings → Developer Options → Wireless Debugging.
Với lập trình viên và kỹ thuật viên
- Tắt Wireless Debugging ngay sau khi sử dụng xong, đặc biệt trước khi kết nối vào mạng Wi-Fi công cộng.
- Xoá thường xuyên danh sách thiết bị đã ghép nối ADB (adb_keys) trên các thiết bị test.
- Ưu tiên sử dụng kết nối ADB qua USB thay vì Wireless khi làm việc trong môi trường không tin cậy.
- Nâng cấp lên Android Security Patch Level 2026-05-01 trở lên trên tất cả thiết bị phát triển.
Với doanh nghiệp và quản trị viên hệ thống
- Kiểm tra và lập danh sách toàn bộ thiết bị Android trong hệ thống, xác định thiết bị nào đang bật Wireless Debugging.
- Triển khai chính sách MDM (Mobile Device Management) để tự động tắt Developer Options trên thiết bị không có nhu cầu debug.
- Phân đoạn mạng (network segmentation): đảm bảo thiết bị Android nhạy cảm không nằm cùng VLAN với các thiết bị không tin cậy.
- Theo dõi kết nối bất thường trên cổng 5555 TCP (cổng mặc định của ADB qua TCP) qua hệ thống IDS/IPS.
- Ưu tiên vá lỗi khẩn cấp cho các thiết bị Android nhúng, kiosk, POS chạy trong môi trường công cộng hoặc bán công cộng.
Kết luận
CVE-2026-0073 là một lỗ hổng bảo mật đáng chú ý với điểm số CVSS 8.8 (High) — không phải ở mức Critical nhưng vẫn đủ nghiêm trọng để Google ưu tiên vá trong bản cập nhật bảo mật tháng 5/2026. Bản chất của lỗi rất đơn giản: một hàm so sánh khóa mật mã trả về nhiều trạng thái nhưng chỉ được xử lý như boolean, dẫn đến việc các trường hợp lỗi bị nhầm thành xác thực thành công.
Điều kiện khai thác phức tạp (cùng mạng, Wireless Debugging đang bật, đã ghép nối trước) giới hạn đáng kể số thiết bị có thể bị nhắm đến trong thực tế. Tuy nhiên, mức độ nguy hiểm không nên bị đánh giá thấp: một khi kẻ tấn công có kết nối ADB, họ có toàn quyền truy cập shell trên thiết bị — không có thông báo, không có dấu hiệu để người dùng phát hiện.
Người dùng phổ thông phần lớn không bị ảnh hưởng. Nhóm cần ưu tiên hành động là lập trình viên, kỹ thuật viên Android, và đặc biệt là các tổ chức vận hành thiết bị Android nhúng trong môi trường công cộng.
Tham khảo
All rights reserved
