환각을 일으킨 SQLite CVE: 취약점 보고에서의 LLM Slop의 부상

LLM이 생성한 가짜 CVE가 SQLite를 표적으로 삼다

최근 SQLite에 대한 보안 권고문들이 "LLM slop"—인공지능이 생성한 조작된 취약점이지만, 그럼에도 불구하고 National Vulnerability Database (NVD)와 CISA의 Authorized Data Publishers (ADP)에 의해 심각한 수준으로 분류된 것으로 확인되었습니다. JFrog 보안 연구원들은 GitHub 저장소 (programmervuln/cveadvisory-)가 50개 이상의 CVE를 게시했으며, 그 중 대다수가 SQLite를 표적으로 하는 여러 개의 고위험 보고서를 포함하여 완전히 가짜라는 사실을 발견했습니다.

조작의 증거

JFrog는 공식 SQLite 태그의 소스 검사, Docker에서의 클린 환경 빌드, 그리고 AddressSanitizer (ASan) 하에서의 PoC 실행을 포함하는 엄격한 테스트 워크플로우를 통해 이러한 CVE의 허위성을 검증했습니다. 조사 결과 네 가지 주요 환각 패턴이 드러났습니다:

1. 존재하지 않는 코드 참조

여러 권고문은 대상 SQLite 버전에서 존재하지 않는 함수나 라인 번호를 인용했습니다. 예를 들어, CVE-2026-51302는 exprComputeOperands()의 취약점을 주장했으나, 이 함수는 보고된 버전 3.41.0 이후인 2025년 중반에 이르러서야 SQLite에 추가되었습니다. 마찬가지로, CVE-2026-51296은 src/json.c 파일의 실제 길이를 초과하는 라인 번호를 인용했습니다.

2. 조작된 패치

CVE-2026-51303은 버전 3.51.3에서 수정 사항이 구현되었다고 주장했습니다. 그러나 버전 3.51.2와 3.51.3 사이의 diff를 확인한 결과, 관련 파일 (src/expr.c)에 변경 사항이 전혀 없었으며, 이는 해당 "패치"가 완전히 날조된 것임을 증명했습니다.

3. 유효하지 않은 PoC 페이로드

권고문에 제공된 Proof-of-Concept (PoC) SQL 문은 크래시나 메모리 오류를 유발하지 못했습니다. 어떤 경우에는 PoC가 파서(parser) 단계에서 실패하는 유효하지 않은 SQL이었으며, 대상이라고 주장하는 실행 로직에 도달하지도 못했습니다.

4. 논리적 불가능성

CVE-2026-51304에서, 권고문은 리스트가 해제된 후 use-after-free (UAF)가 발생한다고 주장했습니다. 소스 코드 분석 결과, SQLite는 삭제 직후에 포인터를 명시적으로 null로 설정(pPrior->pOrderBy = 0)하므로, 설계상 이후의 역참조(dereference)는 불가능합니다.

CVE 파이프라인의 시스템적 실패

이번 사건은 글로벌 취약점 보고 인프라의 심각한 취약점을 강조합니다. 현재 시스템은 두 가지 주요 요인으로 인해 그럴듯하게 들리는 가짜 권고문을 기업용 스캐너에 도달하게 만듭니다:

  • 신원 확인 부족: MITRE 공개 제출 양식은 신원 확인을 요구하지 않으므로, 누구나 CVE와 CVSS 점수를 제안할 수 있습니다.
  • "NVD 안전망"의 붕괴: 역사적으로 NIST 전문가들이 CVE를 수동으로 검증하고 보완했습니다. 그러나 2024년 2월 이후, 보고 건수의 급증으로 인해 NIST가 심층 분석을 일시 중단하면서, 파이프라인이 파편화되고 필수적인 PoC나 재현 단계가 결여된 상태가 되었습니다.

보안 운영에 미치는 영향

조작된 CVE는 보안 팀과 유지 관리자에게 상당한 운영 부담을 줍니다:

  • 낭비되는 리소스: 조직은 존재하지 않는 버그를 조사하고 패치하는 데 시간을 낭비하며, 특히 자동화된 시스템이 CVSS 점수에 기반하여 높은 우선순위의 티켓을 생성할 때 더욱 그렇습니다.
  • 유지 관리자 번아웃: 프로젝트 유지 관리자들은 실제 버그를 수정하는 대신 환각을 반박하는 데 시간을 써야 합니다.
  • AI 트리아지(Triage) 위험: 자동화된 조 remediate(수정)를 위해 사용되는 AI 에이전트가 존재하지 않는 함수를 "패치"하려고 시도하여, 코드베이스에 실제 버그를를 도입할 수 있는 잠재적 위험이 있습니다.

커뮤니티 인사이트 및 반론

Hacker News의 업계 관찰자들은 이러한 트렌드가 신호 대 잡음비(signal-to-noise ratio)를 낮추어 합법적인 위협을 Threats를 식별하는 데 더 어렵게 만든다고 언급했습니다. 일부 기여자는 이것이 더 악리한 공격의 전조가 될 수 있다는 우려를 표했습니다:

"제출물을 검증하지 않는 것은 대규모 공격의 통로가 될 수 있는 것 같습니다. 끝없는 허위 보고로 시스템 전체를를 Flood(플러딩)하여, 시스템의 신뢰성을 현저히하게 만듭니다."

다른 이들은 AI가 생성한 콘텐츠로 AI가 생성한 slop을 보고하는 아이러니를 지적하며, 이러한 도구의 확산이 인간의 전문성이 균질화되고 확률론적 결함이 있는 상태로 대체되는 "stochasticity"를 만들어냈다고 언급했습니다.

"Slop" CVE를 식별하는 방법

조작된 취약점을 조사하는 데 리소스를 낭비하지 않기 위해, 보안 팀은 다음과 같은 적색 신호(red flags)를 찾아야 합니다:

  • 벤더의 확인 부재: 해당 이슈가 공식 유지 관리자 보안 페이지(예: sqlite.org/cves.html)에 존재하지 않습니다.
  • 미연결된 커밋 히스토리: 참조 필드에 연결된 커밋 해시나 Pull Request가 없습니다.
  • 메타데이터 모순: CPE 제품 정의가 비어 있거나 버전 범위가 권고문 내용과 충돌합니다.
  • 불가능한 참조: 권고문이 지정된 버전에서 존재하지 않는 함수나 라인 번호를 인용합니다.

Sources