SQLite 취약점 6건 공식 거부…JFrog, 'AI 슬롭' 가능성 경고

JFrog 보안 연구팀의 공식 기술 분석에 따르면 SQLite 취약점으로 등록됐던 CVE 6건이 실제 소스 코드와 재현 시험에 맞지 않는 것으로 나타났다. CVE 공식 기록도 CVE-2026-51296, CVE-2026-51297, CVE-2026-51300, CVE-2026-51302, CVE-2026-51303, CVE-2026-51304를 모두 ‘REJECTED’ 상태로 전환했다. 각 기록은 CNA가 항목을 철회했으며 추가 조사 결과 보안 문제가 아니었다고 밝힌다.

문제가 된 항목들은 7월 27일 공개된 뒤 한때 높은 위험도의 SQLite 메모리 안전성 취약점으로 유통됐다. CVE 공식 데이터상 거부 처리는 7월 31일 이뤄졌다. 실제 취약점이 확인돼 패치가 필요한 상황이 아니라, 등록된 취약점 설명 자체가 검증을 통과하지 못한 사례다.

JFrog은 SQLite 3.41.0과 3.51.2, 3.51.3의 공식 소스 코드를 확인하고 격리된 환경에서 빌드한 뒤, 보고서에 제시된 개념증명 코드를 AddressSanitizer와 함께 실행했다고 설명했다. 그 결과 일부 보고서는 해당 버전에 존재하지 않는 함수를 인용했고, 실제 파일 길이를 넘어선 줄 번호를 가리켰다. 제시된 SQL이 파서 단계에서 실패하거나 정상 실행돼 메모리 오류가 발생하지 않은 경우도 있었다.

CVE-2026-51302는 SQLite 3.41에 없던 함수를 취약점 경로로 지목했다. CVE-2026-51296은 당시 2706줄이었던 소스 파일의 3555번째 줄과 3575번째 줄을 근거로 제시했다. CVE-2026-51303이 언급한 수정 사항은 해당 버전 사이 실제 소스 변경에서 확인되지 않았다는 것이 JFrog의 분석이다.

연구팀은 같은 GitHub 계정이 공개한 권고 55건을 넓혀 살핀 결과 54건은 조작된 내용이었고, 나머지 한 건은 실제 버그에 검증되지 않은 CVE 정보가 덧씌워진 사례였다고 밝혔다. JFrog은 이 권고들의 문체와 AI 콘텐츠 탐지 결과 등을 근거로 ‘LLM 슬롭’ 가능성을 제기했다. 다만 탐지기 결과만으로 작성 도구를 확정할 수는 없어, 누가 어떤 방식으로 문서를 만들었는지는 확인되지 않았다.

이번 사례는 취약점 식별자가 발급됐다는 사실과 취약점이 기술적으로 검증됐다는 사실을 구분해야 한다는 점을 보여준다. 신규 CVE를 자동 수집해 티켓을 만들거나 패치를 권고하는 조직에서는 공급업체 확인, 수정 커밋, 재현 가능한 개념증명, 영향 버전의 일치 여부를 함께 점검할 필요가 있다. AI 기반 분류·대응 시스템이 검증되지 않은 기록을 그대로 받아들이면 존재하지 않는 함수를 찾거나 불필요한 코드를 수정하는 2차 오류로 이어질 수 있다.

출처: JFrog 보안 연구팀 기술 분석 https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/
출처: CVE 공식 기록 CVE-2026-51296 https://cveawg.mitre.org/api/cve/CVE-2026-51296
출처: CVE 공식 기록 CVE-2026-51297 https://cveawg.mitre.org/api/cve/CVE-2026-51297
출처: CVE 공식 기록 CVE-2026-51300 https://cveawg.mitre.org/api/cve/CVE-2026-51300
출처: CVE 공식 기록 CVE-2026-51302 https://cveawg.mitre.org/api/cve/CVE-2026-51302
출처: CVE 공식 기록 CVE-2026-51303 https://cveawg.mitre.org/api/cve/CVE-2026-51303
출처: CVE 공식 기록 CVE-2026-51304 https://cveawg.mitre.org/api/cve/CVE-2026-51304
출처: SQLite 공식 CVE 안내 https://sqlite.org/cves.html