CVE ร้ายแรงของ SQLite หรือแค่ขยะที่ LLM แต่งขึ้น? JFrog พบช่องโหว่ปลอม 6 รายการ

ทีมวิจัยความปลอดภัยของ JFrog เผยแพร่รายงานตรวจสอบช่องโหว่ SQLite จำนวน 6 รายการที่ถูกส่งเข้าระบบ CVE จากรีโป GitHub ชื่อ programmervuln/cveadvisory- ซึ่งอ้างว่าเป็นช่องโหว่ประเภท use-after-free ได้แก่ CVE-2026-51302 และ CVE-2026-51303 (คะแนน 9.8 Critical), CVE-2026-51300 (9.1 Critical), CVE-2026-51297 (8.8 High) และ CVE-2026-51296 กับ CVE-2026-51304 (7.5 High)

ผลการตรวจสอบพบปัญหาเชิงระบบในทุกรายการ ฟังก์ชันที่ถูกอ้างถึงไม่มีอยู่ในเวอร์ชัน SQLite ที่ระบุ หรือเพิ่งถูกเพิ่มเข้ามาหลังจากนั้นหลายปี เลขบรรทัดที่อ้างเกินความยาวจริงของไฟล์ เช่น อ้างถึงบรรทัด 3555–3575 ในไฟล์ที่มีเพียง 2,706 บรรทัด และเมื่อรัน proof-of-concept ทั้งหมดกับไบนารี SQLite ที่คอมไพล์ด้วย AddressSanitizer ก็ไม่มี payload ใดทำให้เกิด crash เลย นอกจากนี้เครื่องมือ GPTZero ยังชี้ว่า advisory ทั้งหมดในรีโปนี้ดูเหมือนถูกสร้างด้วย AI และไม่มีรายการใดปรากฏบนหน้า CVE advisory อย่างเป็นทางการของ SQLite

รายงานชี้ให้เห็นจุดอ่อนเชิงโครงสร้างของระบบ CVE เอง กระบวนการส่ง CVE ผ่านฟอร์มสาธารณะของ MITRE แทบไม่มีการตรวจสอบตัวตน ทำให้ใครก็ตามส่งคำอธิบายช่องโหว่เข้ามาได้ ก่อนเดือนกุมภาพันธ์ 2024 NVD ยังทำการตรวจสอบด้วยมนุษย์อยู่ แต่ต้องยกเลิกไปเพราะปริมาณที่พุ่งสูง เหลือเพียง Authorized Data Publishers และ CISA ที่บริหารกระบวนการซึ่งกระจัดกระจายและไม่บังคับให้มี PoC ที่พิสูจน์ได้

ผลกระทบมีสองชั้น ชั้นแรกคือองค์กรเสียทรัพยากรไล่ตามช่องโหว่ที่ไม่มีอยู่จริง โดยเฉพาะเมื่อคะแนน Critical ไปกระตุ้น workflow แพตช์อัตโนมัติ ชั้นที่สองน่ากังวลกว่า รายงานเตือนว่า "AI agent ที่เจอ CVE ปลอมอาจพยายามค้นหาฟังก์ชันที่มีช่องโหว่ สร้างแพตช์ หรือแนะนำให้แก้โค้ดที่ไม่มีอยู่จริงด้วยซ้ำ" โดยผู้ไม่ประสงค์ดีรายเดียวสร้าง advisory ปลอมได้ถึง 55 รายการ (ปลอม 54 จริง 1) ปนเปื้อนทั้ง GHSA, NVD และเครื่องมือสแกนช่องโหว่ระดับองค์กร

ข้อแนะนำของ JFrog คือ ตรวจสอบ CVE กับหน้าความปลอดภัยอย่างเป็นทางการของผู้ดูแลโปรเจกต์ บังคับให้มี commit hash หรืออ้าง pull request รัน PoC ในสภาพแวดล้อมทดสอบแยกก่อนแพตช์ ตรวจสอบ metadata ที่ขัดแย้งกัน และอย่าเชื่อ CVE ใหม่ที่มาจากแหล่งที่ยังไม่ผ่านการตรวจสอบ