Cảnh báo: Hàng loạt lỗ hổng bảo mật 'Critical' trên SQLite thực chất là tin giả do AI tạo ra

Trong vài ngày qua, một kho lưu trữ GitHub mới được tạo (programmervuln/cveadvisory-) đã công bố một loạt các thông báo lỗ hổng SQLite (nằm trong số hơn 50 CVE mà chúng tôi tin rằng cũng là "LLM slop" - nội dung rác do LLM tạo ra - ngoại trừ một trường hợp). NVD đã nhanh chóng gắn cờ các lỗ hổng này là nghiêm trọng (critical), và ADP của CISA cũng đồng ý. Tuy nhiên, khi các nhà nghiên cứu bảo mật của JFrog đào sâu để xác minh, các tuyên bố này hoàn toàn không có cơ sở:

Việc kết hợp tất cả các thông báo vào một tệp tin đã kích hoạt các cảnh báo về nội dung do AI tạo ra.

Điều này khiến chúng tôi đặt câu hỏi về độ tin cậy của các CVE này, cũng như nhận ra rằng chúng có khả năng là sản phẩm rác từ LLM.

Trong khi điều tra một trong các CVE vào ngày hôm qua, CVE-2026-51302, chúng tôi thấy rằng Red Hat ban đầu đã gán cho nó điểm mức độ nghiêm trọng 10.0 (Critical):

Khi xem xét lại CVE này vào hôm nay, chúng tôi nhận thấy điểm số đã bị hạ xuống mức 7.6 (High).

Để xác minh kỹ lưỡng các báo cáo này, chúng tôi đã thiết lập một quy trình kiểm thử cô lập:

Lỗ hổng được báo cáo: Thông báo tuyên bố rằng lỗi heap use-after-free (UAF) xảy ra khi sqlite3ReleaseTempReg để lại một con trỏ treo (dangling pointer) trong regFree1, sau đó bị tham chiếu bởi exprComputeOperands.

Kết quả tìm thấy: Vấn đề chính ở đây là exprComputeOperands không tồn tại trong SQLite 3.41. Nó chỉ được thêm vào giữa năm 2025 (các commit e24f20a, 280559b). Hơn nữa, cơ chế của sqlite3ReleaseTempReg không liên quan đến việc giải phóng heap. Hàm này chỉ đơn giản là tái chế các chỉ số thanh ghi vào một mảng để sử dụng lại, khiến cho lỗi UAF là điều không thể xảy ra về mặt thiết kế.

Kiểm thử PoC: Truy vấn chạy thành công mà không gây ra lỗi crash vì lỗi này không tồn tại.

Lỗ hổng được báo cáo: Tuyên bố rằng ExprListDelete không xóa các tham chiếu ngược (back-references) trong các cấu trúc cha khi giải phóng các nút con, được cho là đã được vá trong phiên bản 3.51.3.

Kết quả tìm thấy: Không có bằng chứng nào về các con trỏ tham chiếu ngược trong các cấu trúc Expr, Select hoặc Window có thể dẫn đến trạng thái như vậy. Điều đáng nói nhất là sự khác biệt (diff) giữa phiên bản 3.51.2 và 3.51.3 cho thấy hoàn toàn không có thay đổi nào đối với src/expr.c. "Bản vá" này hoàn toàn là bịa đặt.

Kiểm thử PoC: PoC là mã SQL không hợp lệ và thất bại ngay tại giai đoạn phân tích cú pháp (parser), không bao giờ thực sự chạm đến logic thực thi.

Lỗ hổng được báo cáo: Tuyên bố rằng lỗi UAF xảy ra trong sqlite3ExprDelete vì một con trỏ biểu thức bên trái (left-hand expression pointer) không được xóa, tham chiếu đến các dòng cụ thể trong expr.c.

Kết quả tìm thấy: Các số dòng được trích dẫn (1012 và 1026) lần lượt là một dòng chú thích và một lệnh gọi cấp phát bộ nhớ, cả hai đều không liên quan gì đến pLeft hay logic xóa. Mặc dù hàm này được gọi trong quá trình xử lý lỗi OOM, nó xảy ra ở cuối phạm vi nơi con trỏ không bao giờ được sử dụng lại, ngăn chặn mọi khả năng xảy ra UAF.

Kiểm thử PoC: Thực thi thành công như một truy vấn SQL hợp lệ, trả về kết quả mong đợi mà không có lỗi rò rỉ bộ nhớ hay bất kỳ lỗi nào khác.

Lỗ hổng được báo cáo: Tuyên bố rằng jsonParseFree để lại các tham chiếu treo mà sau đó được truy cập bởi jsonBlobEdit.

Kết quả tìm thấy: Tương tự như trường hợp đầu tiên, jsonBlobEdit không có mặt trong phiên bản mục tiêu được báo cáo (3.41.0). Nó chỉ được giới thiệu sau đó như một phần của quá trình triển khai JSONB. Trong phiên bản mục tiêu, jsonParseFree chỉ được sử dụng trong các hàm hủy (destructors) nơi cấu trúc bao quanh bị loại bỏ ngay lập tức.

Kiểm thử PoC: PoC gặp lỗi JSON không hợp lệ ngay lập tức, nghĩa là mã không bao giờ chạm đến logic sửa đổi JSON nơi lỗ hổng được cho là tồn tại.

Lỗ hổng được báo cáo: Báo cáo lỗi UAF trong jsonRemoveFunc cụ thể tại các dòng 3555 và 3575 của json.c.

Kết quả tìm thấy: Trong phiên bản 3.41.0, src/json.c chỉ dài 2706 dòng. Các số dòng được trích dẫn không tồn tại. Việc triển khai thực tế của hàm này được tìm thấy sớm hơn khoảng 2000 dòng, và quá trình kiểm tra mã đó cho thấy không có lỗ hổng quản lý bộ nhớ nào.

Kiểm thử PoC: Payload thất bại trong quá trình phân tích cú pháp JSON, để lại bộ nhớ không bị ảnh hưởng.

Lỗ hổng được báo cáo: Tuyên bố rằng sqlite3ExprListDelete(pOrderBy) giải phóng danh sách sắp xếp trong khi mã tiếp theo đọc pOrderBy->nExpr.

Kết quả tìm thấy: Chữ ký hàm một đối số được báo cáo trong thông báo không tồn tại. Chữ ký thực tế yêu cầu một con trỏ đến ngữ cảnh cơ sở dữ liệu (sqlite3 *db). Hơn nữa, SQLite chủ động gán giá trị null cho các con trỏ ngay sau khi xóa:

Kiểm thử PoC: Payload PoC được thực thi với truy vấn ORDER BY 20 cột và xử lý bình thường, trả về kết quả đã sắp xếp mà không gặp vấn đề gì.

Quy trình gửi CVE thông qua biểu mẫu công khai của MITRE thiếu sự xác minh danh tính thực sự, nghĩa là hầu như bất kỳ ai cũng có thể gửi mô tả lỗ hổng và đề xuất điểm CVSS.

Trước đây, NIST đóng vai trò là lưới an toàn đáng tin cậy cho hệ thống này, các chuyên gia tại Cơ sở dữ liệu lỗ hổng quốc gia (NVD) đã phân tích, xác thực và làm phong phú các CVE gửi đến theo cách thủ công trước khi phê duyệt. Nhưng lưới an toàn đó đã bị phá vỡ vào tháng 2 năm 2024.

Do bị quá tải bởi làn sóng báo cáo lỗ hổng khổng lồ, NIST đã tạm dừng việc phân tích chuyên sâu. CISA và các Nhà xuất bản dữ liệu được ủy quyền (ADP) khác đã cố gắng can thiệp bằng các nỗ lực làm phong phú dữ liệu của riêng họ, nhưng quy trình toàn cầu hiện đang bị phân mảnh và chìm trong một lượng tồn đọng khổng lồ. Vì không có bước nào trong hệ thống hiện nay thực sự yêu cầu bằng chứng khái niệm (PoC) hoặc tái hiện lỗi, một thông báo giả mạo nghe có vẻ hợp lý có thể dễ dàng lọt qua quy trình và xuất hiện trên GHSA, các cơ sở dữ liệu hạ nguồn và các trình quét doanh nghiệp.

Sự cố này cho thấy một vấn đề mang tính hệ thống với việc tiếp nhận lỗ hổng tự động. Một cuộc kiểm tra rộng hơn trên 55 thông báo được công bố bởi cùng một tài khoản GitHub cho thấy 54 thông báo hoàn toàn bị bịa đặt, trong khi một thông báo chứa lỗi thực sự nhưng lại đi kèm với siêu dữ liệu CVE chưa được xác minh.

Các dấu hiệu cảnh báo để nhận diện CVE rác (Slop CVEs):

Những CVE rác do LLM tạo ra này có thể khiến các tổ chức lãng phí thời gian điều tra và vá các lỗ hổng không thực sự tồn tại, cũng như làm ô nhiễm các cơ sở dữ liệu lỗ hổng. Trong các môi trường mà các lỗ hổng nghiêm trọng (Critical) được tự động ưu tiên hoặc các phiếu hỗ trợ (tickets) được mở dựa trên điểm số lỗ hổng, những CVE bịa đặt như vậy có thể trở thành một gánh nặng thực sự.

Trong các môi trường sử dụng AI để tự động hóa việc phân loại và khắc phục lỗ hổng, điều này trở nên đáng lo ngại hơn nữa. Một tác nhân AI khi gặp phải một CVE bịa đặt có thể cố gắng định vị hàm bị lỗi, tạo bản vá hoặc đề xuất các thay đổi dựa trên mã thậm chí không tồn tại. Thay vì giúp các nhóm bảo mật khắc phục các lỗ hổng thực sự, nó có thể dẫn họ đi sai hướng hoàn toàn, có khả năng gây ra các thay đổi không cần thiết và lãng phí thời gian.

Để tránh bị ảnh hưởng bởi loại nhiễu lỗ hổng này:

Chúng tôi cũng đã chính thức báo cáo những phát hiện này cho GHSA, Red Hat và NVD để hỗ trợ việc khắc phục các bản ghi này.