CVE giả, báo cáo do AI tạo và nhu cầu xác minh

Việc tạo ra các báo cáo lỗ hổng bảo mật có vẻ đáng tin ngày càng ít tốn kém, làm gia tăng hệ quả đối với những người duy trì phần mềm và các đội ngũ bảo mật. Sáu Lỗ hổng và Phơi nhiễm Phổ biến (CVE) liên quan đến SQLite được công bố vào tháng 7 năm 2026, trong đó hai lỗ hổng nhận điểm mức độ nghiêm trọng 9.8. Các báo cáo có vẻ hợp lệ, mô tả lỗi an toàn bộ nhớ và kèm theo giải thích kỹ thuật cùng mã khai thác thử nghiệm.

Tuy nhiên, các nhà nghiên cứu của JFrog phát hiện một số hàm được nhắc đến trong các báo cáo này không có trong những phiên bản bị ảnh hưởng. Hơn nữa, không PoC (bằng chứng khái niệm) nào tái hiện được các lỗ hổng như đã nêu. Trang CVE của chính SQLite hiện cho biết sáu báo cáo này không phải là lỗi; các hồ sơ CVE sau đó đã bị bác bỏ.

Vấn đề không chỉ xảy ra với SQLite. Daniel Stenberg, người duy trì curl, ước tính vào năm ngoái rằng khoảng 20% báo cáo bảo mật gửi đến là sản phẩm của những nội dung rác do AI tạo ra. Cơ quan Đánh số CVE (CNA) của GitHub nhận được gần 4.000 yêu cầu CVE vào tháng 5 năm 2026; con số này tương đương mức tăng khoảng 10 lần so với cùng kỳ năm trước. GitHub không quy mức tăng này cho AI cũng không ghi nhận chất lượng hồ sơ gửi lên suy giảm, nhưng số lượng tăng vọt cho thấy quy trình công bố lỗ hổng đang bị quá tải.

AI giúp việc tạo ra các cáo buộc chi tiết về lỗ hổng trở nên dễ dàng hơn, nhưng việc xác định những cáo buộc đó có xác đáng hay không lại tốn nhiều thời gian. Hơn nữa, một khi CVE đã xuất hiện trên các nguồn cấp dữ liệu bảo mật và cơ sở dữ liệu công khai, việc sửa hồ sơ gốc không đồng nghĩa mọi bản sao cũng sẽ tự động được cập nhật. Vì vậy, nhu cầu phân biệt giữa lỗ hổng được báo cáo và lỗ hổng đã được xác minh về mặt kỹ thuật ngày càng tăng.

CVE “giả” là gì?

Mọi người thường dùng thuật ngữ “CVE giả” để nói về một CVE có khả năng đã được báo cáo không chính xác. Tuy nhiên, “giả” không có nghĩa là cố tình gây hiểu lầm. Báo cáo có thể xuất phát từ phân tích tĩnh bỏ sót một bước kiểm tra xác thực hoặc hiểu nhầm rằng kẻ tấn công kiểm soát được dữ liệu đầu vào. Báo cáo có thể mô tả một hàm có thật nhưng lại nêu ra một đường tấn công không hợp lệ. Một mã định danh (mã CVE) có thể được cấp rồi bị hủy sau đó nếu điều kiện được báo cáo thực tế không phải là lỗ hổng. Điều này khác với một báo cáo cố tình bịa đặt.

Tranh chấp cũng không đồng nghĩa với CVE giả. Nhà cung cấp có thể phản bác kết luận của nhà nghiên cứu về khả năng khai thác, ranh giới mối đe dọa hoặc việc một hàm có được thiết kế để xử lý dữ liệu đầu vào không đáng tin cậy hay không. Nhưng tranh chấp không chứng minh rằng nhà nghiên cứu đã sai. Việc bác bỏ CVE cũng không nhất thiết có nghĩa là CVE đó bị bịa đặt; CVE có thể bị bác bỏ vì trùng lặp hoặc vì lý do hành chính. Dù mã định danh CVE không phải là sự xác minh kỹ thuật độc lập, ngành này vẫn cần xem xét nghiêm túc các báo cáo có căn cứ.

Vì sao CVE giả là vấn đề

Một vấn đề chúng ta đang chứng kiến là có người dùng AI để tạo báo cáo lỗ hổng mà không xác minh đầy đủ các phát hiện. Những báo cáo này có thể bao gồm giải thích kỹ thuật chi tiết, tham chiếu mã nguồn, thậm chí cả PoC, khiến chúng trông có vẻ đáng tin. Nhưng như các CVE liên quan đến SQLite cho thấy, một số hàm được dẫn chiếu thậm chí không tồn tại trong những phiên bản bị ảnh hưởng.

GitHub cho biết số lượng báo cáo lỗ hổng gửi lên đã tăng đáng kể trong năm 2026, dù không quy mức tăng đó cho AI cũng không báo cáo rằng chất lượng hồ sơ gửi lên suy giảm. Mối lo ngại là khi số lượng báo cáo tăng, khối lượng công việc cần thiết để điều tra chúng cũng tăng theo, bất kể các phát hiện có xác thực hay không.

Những người từng phân loại báo cáo lỗ hổng sẽ dễ nhận ra khó khăn thực tế này. Một mô hình AI có thể phát hiện lời gọi API đáng ngờ, phác thảo sơ bộ một kịch bản khai thác và nhanh chóng tạo ra một báo cáo trông chuyên nghiệp. Để xác định kịch bản đó có khả thi hay không, có thể cần kiểm tra đúng bản phát hành, lần theo luồng điều khiển, tìm hiểu cách dữ liệu đến được hàm, xây dựng môi trường kiểm thử và chạy thử cách khai thác được nêu. Quy trình vẫn như vậy dù báo cáo chính xác hay không, và việc đó có thể tốn kém.

CVE giả cũng có thể gây tổn hại đến danh tiếng. Thông báo về lỗ hổng có thể nhanh chóng lan truyền qua các nguồn cấp dữ liệu của công cụ quét, cơ sở dữ liệu bảo mật và kết quả tìm kiếm. Tuy nhiên, việc đính chính sau đó có thể không lan rộng đến mức ấy. Ngay cả khi báo cáo đã bị phản bác hoặc bác bỏ, các nhà cung cấp vẫn có thể phải giải trình với những khách hàng đã nhìn thấy báo cáo ban đầu.

Ngoài ra còn có nguy cơ các lỗ hổng thực sự bị bỏ sót hoặc xử lý chậm trễ vì các đội ngũ phải dành thời gian điều tra những báo cáo không chính xác. Khi nguồn lực của những người duy trì phần mềm và các đội ngũ bảo mật có hạn, mỗi giờ bỏ ra để chứng minh một cảnh báo dương tính giả là một giờ lẽ ra có thể dùng để điều tra một vấn đề bảo mật thực sự.

Ứng phó bằng tự động hóa

Nhiều nhà điều tra vẫn phân loại báo cáo thủ công để ứng phó với làn sóng báo cáo mới đang ồ ạt đổ về, nhưng cách làm này không bền vững. Tự động hóa tỏ ra là trợ giúp đắc lực, giúp xác minh cáo buộc về lỗ hổng dựa trên đúng bản phát hành và cấu hình bị ảnh hưởng. Dưới đây là năm câu hỏi cần đặt ra:

• Các điều kiện tiên quyết để thực hiện cuộc tấn công có đáng tin cậy không, bao gồm cả cấu hình và quyền truy cập?
• Hàm được cho là có liên quan có tồn tại trong phiên bản bị ảnh hưởng không?
• Kẻ tấn công có thể tiếp cận đoạn mã dễ bị tổn thương không? Hãy xác định xem đoạn mã liên quan có thể được thực thi trong các điều kiện bị ảnh hưởng hay không, và liệu kẻ tấn công có thể cung cấp đầu vào để tiếp cận đoạn mã đó hay không.
• Người kiểm thử có thể tái hiện hành vi đó trong môi trường thử nghiệm được kiểm soát hoặc bằng một PoC không?
• Hành vi quan sát được có gây ra tác động bảo mật như mô tả trong cảnh báo hay không?

Các công cụ AI dạng tác tử có thể tạo môi trường thử nghiệm, phân tích luồng thực thi trong mã, tạo PoC và ghi lại bằng chứng thực thi để xem xét. Chúng không thể tự động xác minh mọi khẳng định. Ngay cả khi lỗ hổng là xác thực, PoC vẫn có thể thất bại nếu môi trường chưa đầy đủ hoặc điều kiện kích hoạt không chính xác. Người kiểm thử có thể tái hiện sự cố sập mà không chứng minh được khả năng khai thác như đã tuyên bố. Những điểm cần lưu ý này cho thấy phán đoán của con người vẫn đóng vai trò then chốt. Tuy nhiên, các công cụ này có thể giúp các nhóm tiến gần hơn đến một câu trả lời có thể tái hiện, trước khi một báo cáo ngốn thêm thời gian của các bộ phận kỹ thuật, quản lý lỗ hổng và hỗ trợ khách hàng.

Vượt qua tình trạng quá tải trong hệ sinh thái CVE

Không có chính sách ngắn gọn nào có thể kỳ diệu giải quyết vấn đề CVE giả. Tuy nhiên, việc yêu cầu bằng chứng mạnh hơn khi gửi báo cáo và làm rõ hơn tình trạng tái hiện sẽ hữu ích. Việc xử lý hồ sơ bị tranh chấp minh bạch hơn và sửa dữ liệu ở các hệ thống hạ nguồn nhanh hơn cũng sẽ có ích. Nên khuyến khích các nhà nghiên cứu xác thực những phát hiện có sự hỗ trợ của AI trước khi gửi báo cáo.

Các nhóm bảo mật và nhà cung cấp phải tập trung xem xét bằng chứng. Điểm CVE ở mức nghiêm trọng không cho biết liệu đường dẫn dễ bị tấn công có thể được tiếp cận trong môi trường của họ hay không. PoC thất bại không có nghĩa là mọi thứ đều ổn. Và việc nhận được mã CVE không miễn cho các nhóm khỏi trách nhiệm thực hiện công việc kỹ thuật cần thiết để hiểu rõ vấn đề.

AI đang nâng cao khả năng phát hiện lỗ hổng, đồng thời cũng tạo điều kiện đưa ra những khẳng định trông có vẻ thuyết phục nhưng không chính xác. Trong bối cảnh các báo cáo ngày càng gia tăng, các tổ chức cần đầu tư vào việc xác minh. Công việc này bao gồm xây dựng các bài kiểm thử, tái hiện kết quả, kiểm tra các giả định và giúp việc đánh giá bằng chứng trở nên dễ dàng hơn. Đây là lĩnh vực mà hoạt động kiểm thử bảo mật theo hướng tác tử có thể đóng vai trò quan trọng.