Một lỗ đen trong bytecode mà tự tay đào ra.
Tuần qua, cộng đồng bảo mật blockchain xôn xao trước thông tin GLM-5.3 – một mô hình ngôn ngữ lớn chưa từng được công bố chính thức – đã phát hiện một lỗ hổng nghiêm trọng trong Cursor, trình soạn thảo mã nguồn AI phổ biến. Nhưng khi đào sâu vào chi tiết, tôi nhận ra: đây không phải là câu chuyện về một siêu AI, mà là một bài học về cách chúng ta nên đọc các báo cáo lỗ hổng trong thời đại AI.
Context: AI trong audit smart contract – miếng bánh thơm nhưng dễ cháy
Từ năm 2023, các công cụ AI như GPT-4, Claude đã được dùng để hỗ trợ kiểm tra mã nguồn. Trong lĩnh vực blockchain, nơi mỗi dòng code có thể trị giá hàng triệu USD, việc dùng AI để phát hiện lỗ hổng trở nên hấp dẫn. Tuy nhiên, kinh nghiệm của tôi khi audit một giao thức privacy vào năm 2024 cho thấy: AI có thể giúp tăng tốc, nhưng không thể thay thế con người. Khi đó, tôi phát hiện lỗi logic trong batch verification mà hai auditor trước bỏ sót – một lỗi mà AI thông thường sẽ không tìm ra nếu không được hướng dẫn cụ thể.
Bối cảnh hiện tại: thị trường đi ngang, các dự án cắt giảm chi phí, nhiều team chọn AI audit như một giải pháp rẻ tiền. Thông tin về GLM-5.3 xuất hiện đúng lúc, như một tín hiệu cho thấy AI đã đạt đến trình độ “phát hiện lỗ hổng nghiêm trọng”. Nhưng sự thật có đơn giản vậy?
Core: Phân tích kỹ thuật – những gì còn thiếu trong báo cáo GLM-5.3
Báo cáo gốc (mà tôi có được từ nguồn phân tích) hầu như không có thông tin kỹ thuật. Không có CWE classification, không có CVSS score, không có PoC. Chỉ có một câu khẳng định: “GLM-5.3 đã nhận diện một lỗ hổng nghiêm trọng trong Cursor.” Điều này đặt ra hai câu hỏi lớn:
- GLM-5.3 là gì? Phiên bản này không nằm trong dòng sản phẩm công khai của Zhipu AI (vốn chỉ đến GLM-4.x). Nếu đây là bản nội bộ, tại sao lại đưa ra truyền thông? Nếu đây là nhầm lẫn, thì độ tin cậy của toàn bộ câu chuyện sụp đổ.
- Lỗ hổng nằm ở đâu? Cursor dựa trên VS Code, có thể lỗ hổng thuộc về plugin, lớp AI agent, hoặc kênh đồng bộ đám mây. Mỗi trường hợp có vector tấn công khác nhau. Nhưng báo cáo không chỉ rõ, khiến việc đánh giá rủi ro là bất khả thi.
Có hai kịch bản kỹ thuật khả thi:
Kịch bản A: GLM-5.3 hoạt động như một công cụ static analysis, được cung cấp mã nguồn Cursor và tự động phát hiện lỗi. Điều này đã từng thấy với GPT-4 trong các bài toán CVE, nhưng đòi hỏi mô hình phải có khả năng suy luận sâu và hiểu cấu trúc dự án lớn. Nếu đúng, đây là bước tiến lớn.
Kịch bản B: GLM-5.3 được sử dụng trong quá trình dùng Cursor, và phát hiện lỗ hổng trong chính sản phẩm. Ví dụ: thông qua prompt injection, mô hình có thể bị lừa tiết lộ thông tin nhạy cảm hoặc thực thi mã độc. Nhưng nếu vậy, lỗ hổng không phải do AI “tự phát hiện”, mà do con người đã khai thác AI để tìm ra.
Cả hai kịch bản đều có thể xảy ra, nhưng không có dữ liệu để phân biệt. Trong thực tế audit của tôi, mỗi lỗ hổng đều kèm theo mô tả chi tiết: điều kiện kích hoạt, tác động, cách fix. Một báo cáo thiếu những thông tin đó giống như một tấm bản đồ không có tọa độ.
Tôi từng viết bot arbitrage DeFi Summer bằng Python, thất bại vì sandwich attack, và mất 200 USD. Sau đó tôi viết lại bằng Solidity, kiểm tra slippage cẩn thận, và lời 50 USD trước khi tắt vì rủi ro quá cao. Kinh nghiệm đó dạy tôi: trong bảo mật, không có gì thay thế được kiểm tra thực tế. Một báo cáo lỗ hổng mà không có PoC cũng giống như một bot arbitrage không có kiểm tra slippage – dễ bị tấn công ngược.
Contrarian: Góc nhìn ngược – AI audit có thể hiệu quả, nhưng truyền thông đang làm hỏng nó
Nhiều người sẽ nói: “Dù sao AI cũng tìm ra lỗi, điều đó quan trọng hơn chi tiết.” Nhưng tôi cho rằng điều ngược lại mới đúng. Chính sự thiếu minh bạch khiến cộng đồng khó đánh giá mức độ nghiêm trọng, và dẫn đến hai hệ lụy:
- FOMO sai lầm: Các dự án vội vàng mua dịch vụ audit AI mà không hiểu rõ năng lực thực sự, dẫn đến lỗ hổng vẫn tồn tại.
- Mất lòng tin: Khi phát hiện báo cáo không có cơ sở, người dùng sẽ hoài nghi tất cả các báo cáo tương tự, kể cả những báo cáo hợp lệ.
Sàn NFT tự build, sập thì cũng đứng được một mình. Tôi từng tự xây một marketplace NFT, và phát hiện lỗi reentrancy trong hàm withdraw. Nếu tôi chỉ tweet “tôi tìm ra lỗi nghiêm trọng” mà không đưa bằng chứng, chẳng ai tin. Nhưng tôi đã đăng issue lên GitHub, kèm code fix, và được cộng đồng ghi nhận. Sự khác biệt nằm ở chi tiết.
Điểm mù của báo cáo GLM-5.3 là: nó khai thác tâm lý “AI mạnh mẽ” để tạo sự chú ý, nhưng lại không chịu trách nhiệm về tính xác thực. Nếu thực sự có lỗ hổng, việc công bố thiếu thông tin có thể gây nguy hiểm: kẻ tấn công có thể dựa vào đó để tìm lỗi thật, trong khi người dùng không biết cách phòng thủ.
Takeaway: Khi AI phát hiện lỗ hổng, hãy hỏi “làm thế nào” trước khi hỏi “có nghiêm trọng không”
Bảo mật blockchain không phải là trò chơi của niềm tin. Mỗi lỗ hổng cần được chứng minh bằng code, bằng PoC, bằng phân tích tác động. AI có thể là công cụ hỗ trợ đắc lực, nhưng nó không thể thay thế quy trình audit chuẩn mực. DeFi Summer dạy tôi: gan là biết khi nào mai phục. Trong thị trường đi ngang này, đừng để những báo cáo mơ hồ dẫn dắt quyết định đầu tư hay bảo mật của bạn.
Hãy nhìn vào dữ liệu, không phải lời quảng cáo. Khi có một báo cáo lỗ hổng, hãy tự hỏi: PoC đâu? CVE đâu? Ai đã xác nhận? Nếu thiếu những thứ đó, hãy coi đó như một lỗ đen trong bytecode – có thể chứa điều nguy hiểm, nhưng cũng có thể chỉ là khoảng trống do thiếu thông tin.
