Một dòng code sai, cả hệ thống sụp đổ. Nhưng ở đây, thứ sụp đổ không phải hợp đồng thông minh, mà là quyền kiểm soát toàn bộ máy Mac của bạn — bao gồm cả ví tiền điện tử đang mở trên đó. Vào ngày 9/8, một bản tin ngắn từ một trang web blockchain đã hé lộ sự tồn tại của CVE-2026-65400: lỗ hổng được xếp hạng Critical trên macOS, nằm chính trong thành phần Screen Sharing. Không cần xác thực. Không cần click chuột. Kẻ tấn công chỉ cần một kết nối mạng tới cổng VNC đang mở là có thể đăng nhập bằng bất kỳ tài khoản nào và chiếm toàn bộ màn hình.
Tôi đã dành 13 năm trong lĩnh vực bảo mật, nhưng điều khiến tôi dừng lại không phải là kỹ thuật khai thác, mà là nguồn tin. Một trang web về blockchain đưa tin về lỗ hổng macOS. Không có liên kết tới Apple Security Advisory. Không có ID CVE trên NVD. Không có danh sách phiên bản bị ảnh hưởng. Chỉ có một câu ngắn gọn: "Apple đã vá, hãy nâng cấp lên 26.6.1." Đây là kiểu thông tin mà tôi vẫn gọi là "tín hiệu đỏ có cấu trúc" — một phần sự thật, một phần khuyết thiếu, tạo ra cảm giác khẩn cấp giả tạo.
Hãy cùng tôi mổ xẻ. Không phải để dọa bạn, mà để trang bị cho bạn một cách có hệ thống.
Bối cảnh: VNC, di sản công nghệ 30 năm và "con dao hai lưỡi" tên Screen Sharing
macOS Screen Sharing dựa trên giao thức VNC (Virtual Network Computing) — một giao thức ra đời từ những năm 1990, thời điểm mà bảo mật mạng chưa tồn tại như một khái niệm. Apple khoác lên nó một lớp mã hóa và xác thực, nhưng cấu trúc lõi vẫn mang nợ kỹ thuật của ba thập kỷ.
Tính năng này mặc định tắt. Điều đó có nghĩa là người dùng phổ thông — những người dùng Mac để lướt web, xem phim — gần như không bị ảnh hưởng. Nhưng hãy ngừng lại một giây. Ai là người bật Screen Sharing trên máy Mac? Đó là quản trị viên IT, kỹ sư vận hành, nhà phát triển, những người dùng remote desktop để làm việc từ xa. Và trong số đó, một nhóm đặc biệt nguy hiểm: các nhà giao dịch crypto và người nắm giữ tài sản số.
Tại sao? Vì chiếc máy Mac có bật Screen Sharing thường là chiếc máy được đặt ở nhà, chạy 24/7, kết nối với ví nóng, sàn giao dịch, hoặc thậm chí là node xác thực. Một lỗ hổng VNC có thể tiếp cận không xác thực trên đúng chiếc máy đó — bạn có thể hình dung hậu quả. Nhưng có một điều quan trọng hơn mà bản tin này cố tình bỏ qua: các phiên bản macOS cũ hơn. Bản tin chỉ nói về macOS 26.6.1, không nói gì đến macOS 15, 14, 13. Nếu bạn là một người dùng chậm nâng cấp — nhà đầu tư dùng Macbook Pro 2019 chạy macOS Monterey, chẳng hạn — liệu bạn có được vá?
Đây là điểm mù lớn nhất của toàn bộ câu chuyện.
Core: Mổ xẻ CVE-2026-65400 dưới góc nhìn của một auditor
Trong các cuộc audit hợp đồng thông minh, khi tôi thấy một hàm có thể được gọi mà không cần xác thực, đó là điều đầu tiên tôi đánh dấu là "high severity." Một lỗ hổng screen sharing không cần xác thực có cùng bản chất: đây là lỗi logic ở tầng xử lý phiên (session handling) hoặc trạng thái máy trạng thái (state machine) trước khi xác thực.
Thông thường, một cuộc tấn công kiểu này khai thác một trong ba nguyên nhân gốc:
- Lỗi state machine trong giao thức bắt tay VNC: máy chủ chuyển trạng thái từ "chờ xác thực" sang "đã xác thực" dựa trên một cờ (flag) có thể bị ghi đè bằng một gói tin đặc biệt.
- Type confusion hoặc buffer overflow trong bộ phân tích cú pháp: dữ liệu được gửi trước khi xác thực được xử lý không đúng cách, ghi đè lên vùng nhớ chứa thông tin phiên.
- Lỗi logic nghiệp vụ: một số phiên bản VNC cho phép "guest login" hoặc "anonymous login" được kích hoạt ngầm trên cổng 5900, đặc biệt khi người dùng bật Screen Sharing qua tính năng Back to My Mac hoặc qua sharing preferences.
Với những gì bản tin mô tả — "đăng nhập bằng bất kỳ tài khoản nào" — khả năng cao đây là một lỗi ở lớp xác thực, không phải lỗi tràn bộ nhớ thông thường. Và nếu nhà nghiên cứu đã tìm ra cách "downgrade" hoặc bỏ qua xác thực sau khi vá, thì vòng đời khai thác sẽ kéo dài hơn nhiều.
Nhưng điểm mấu chốt của tôi không nằm ở kỹ thuật khai thác. Nó nằm ở chuỗi cung ứng thông tin.
Một hệ thống chỉ bền vững khi từng mắt xích tuân theo chuẩn. CVE là một chuẩn. Apple Security Advisory là một chuẩn. CISA KEV là một chuẩn. Và một bài viết trên trang tin blockchain — ngay cả khi nó viết đúng về một lỗ hổng có thật — nhưng thiếu các chuẩn này, sẽ không bao giờ đạt ngưỡng "có thể hành động" cho doanh nghiệp.
Góc nhìn phản trực giác: Phe "bò" đã đúng ở một điểm
Sau khi đọc xong bản tin, nhiều người sẽ nói: "Đây là tin giả do trang blockchain dựng lên để câu view, vì Apple chưa bao giờ có kiểu lỗ hổng VNC kinh khủng như vậy." Tôi xin khác.
Phe "bò" đúng ở điểm: macOS của Apple thực sự có bề mặt tấn công nhỏ hơn Windows. Nhờ kiến trúc sandbox, Gatekeeper, SIP, và việc Apple kiểm soát chặt toàn bộ phần cứng lẫn phần mềm, một lỗ hổng RCE không xác thực trong dịch vụ VNC là điều hiếm gặp. Nhưng nói như vậy không có nghĩa là không thể xảy ra. Năm 2021, các nhà nghiên cứu đã tìm ra lỗi trong ImageIO cho phép thực thi mã từ xa chỉ bằng một tấm ảnh. Năm 2023, một chuỗi lỗ hổng trong WebKit cho phép toàn quyền kiểm soát Safari. Mỗi lỗ hổng đó đều bắt đầu nguồn từ một dòng code sai.
Điểm khác biệt duy nhất: các lỗ hổng nói trên đều yêu cầu nạn nhân tương tác. CVE-2026-65400 thì không. Nếu lỗ hổng này có thật và có thể khai thác từ xa, mức độ nguy hiểm của nó sẽ lớn hơn hầu hết các lỗ hổng mà tôi từng thấy trong hệ sinh thái Apple. Vì vậy, tôi không vội bác bỏ. Trong bảo mật, phản ứng đúng đắn nhất trước một bản tin thiếu thông tin là "xử lý như một rủi ro có thể tồn tại
