Tóm tắt
JFrog phân tích một batch advisory về SQLite từ repo GitHub programmervuln/cveadvisory-. Các advisory này được NVD và CISA ADP gắn severity cao, nhưng khi đối chiếu source và chạy PoC, nhiều claim không đứng vững. Một số function được nêu không tồn tại trong version SQLite bị cáo buộc; có line number trỏ vào comment hoặc vượt quá độ dài file; có patch được nói là tồn tại nhưng diff giữa version liên quan không đổi; PoC không gây crash hoặc thậm chí không parse được.
JFrog nói audit rộng hơn trên 55 advisory của cùng tài khoản cho thấy 54 advisory hoàn toàn bịa, còn một advisory chứa bug thật nhưng metadata CVE chưa được kiểm chứng.
Phát hiện chính
Các red flag lặp lại gồm: không có xác nhận từ maintainer SQLite, không có commit hoặc pull request làm bằng chứng, CPE metadata mâu thuẫn, function không tồn tại trong target version, line number sai và PoC không tái hiện lỗi. Một ví dụ là CVE-2026-51302 viện dẫn exprComputeOperands trong SQLite 3.41, trong khi function đó được thêm vào giữa năm 2025. Một ví dụ khác nói json.c có line 3555/3575 trong version 3.41, nhưng file thực tế chỉ có 2706 dòng.
Bài viết cũng chỉ ra bối cảnh hệ thống: form CVE công khai của MITRE không yêu cầu xác minh danh tính mạnh; NVD sau khủng hoảng backlog từ tháng 2/2024 không còn luôn đóng vai trò bộ lọc sâu như trước; các ADP cố bổ sung enrichment nhưng pipeline bị phân mảnh.
Ý nghĩa với Dev
Dev và security team không nên tự động tin một CVE mới chỉ vì score là Critical. Việc cần làm là kiểm tra vendor advisory chính thức, đối chiếu source/version, tìm commit hoặc patch thật, và tái hiện PoC trong môi trường an toàn khi có thể.
Điểm nguy hiểm riêng của LLM slop là nó có thể tạo ra văn bản rất giống advisory thật. Nếu scanner hoặc ticketing system ưu tiên mù theo CVSS, team sẽ mất thời gian điều tra lỗi không tồn tại. Trong môi trường đã dùng AI để triage hoặc đề xuất patch, rủi ro còn tăng thêm: agent có thể đi tìm function không tồn tại và tạo thay đổi vô ích vào codebase.