가짜 SQLite CVE: LLM 생성 취약점 슬러그의 부상

SQLite에 대한 일련의 중요한 취약점 권고가 최근 LLM 슬러그—존재하지 않는 코드를 인용하고 기능하지 않는 PoC 페이로드를 제공하는 AI가 생성한 가짜 보고서임이 밝혀졌습니다. 가짜임에도 불구하고 이러한 CVE는 inicialmente National Vulnerability Database(NVD)와 CISA의 Authorized Data Publishers(ADPs)에 의해 심각도로 플래그 지정되었으며, 현재 취약점 검증 파이프라인의 위험한 격차를 보여줍니다.

가짜 SQLite 취약점

JFrog 보안 연구원들은 GitHub 저장소(programmervuln/cveadvisory-)에서 게시된 SQLite 권고 사항 배치를 조사했습니다. 그들의 감사는 이 계정의 55개 권고 중 54개가 완전히 가짜임을 밝혀냈습니다.

환각된 CVE 분석

연구원들은 공식 SQLite 소스 검사, 깨끗한 Docker 빌드, AddressSanitizer(ASan) 계측을 포함하는 격리된 테스트 워크플로를 사용하여 주장의 진위를 확인했습니다. 결과는 AI 환각의 일관된 패턴을 보여주었습니다:

CVE 보고된 결함 발견
CVE-2026-51302 exprComputeOperands()에서의 UAF 대상 버전(3.41.0)에서 함수 exprComputeOperands()가 존재하지 않았습니다.
CVE-2026-51303 ExprListDelete()에서의 UAF 버전 3.51.3에서 보고된 "패치"는 조작되었습니다; src/expr.c에서 3.51.2와 3.51.3 사이에 변경 사항이 존재하지 않았습니다.
CVE-2026-51300 sqlite3ExprDelete()에서의 UAF 인용된 라인 번호는 주석과 메모리 할당 호출을 참조했으며, 보고된 결함과 무관했습니다.
CVE-2026-51297 jsonBlobEdit()을 통한 UAF 대상 버전(3.41.0)에서 함수 jsonBlobEdit()이 존재하지 않았습니다.
CVE-2026-51296 jsonRemoveFunc에서의 UAF 인용된 라인 번호가 소스 파일(src/json.c)의 총 길이를 초과했습니다.
CVE-2026-51304 pOrderBy->nExpr을 통한 UAF 보고된 함수 시그니처가 잘못되었으며, 코드는 삭제 후 포인터를 명시적으로 null로 설정합니다.

모든 경우에 제공된 PoC SQL 문은 파서 단계에서 실패하거나 메모리 오류를 유발하지 않고 성공적으로 실행되었습니다.

CVE 검증에서의 시스템적 실패

조작된 보고서가 심각한 심각도 점수(예: Red Hat이 inicialmente 부여한 CVE-2026-51302의 10.0 점수)를 받을 수 있었던 것은 취약점 섭취 파이프라인의 붕괴를 나타냅니다.

NVD 안전망의 붕괴

역사적으로 National Vulnerability Database(NVD)는 들어오는 CVE를 수동으로 분석하고 검증했습니다. 그러나 2024년 2월, NIST는 보고서의 급증으로 인해 깊은 분석을 중단했습니다. 이로 인해 다음과 같은 조각난 파이프라인이 발생했습니다:

  • 검증 부족: 현재 제출 프로세스에서는 기능 증명-of-concept 또는 버그 재현을 요구하는 단계가 없습니다.
  • 자동 섭취: plausible-sounding 가짜 권고는 인간 검증 없이 GHSA 및 기업 스캐너로 슬라이드할 수 있습니다.
  • 신원 익명성: MITRE 공개 제출 폼은 엄격한 신원 검증이 부족하여 누구나 CVE와 CVSS 점수를 제안할 수 있습니다.

보안 운영에 미치는 영향

가짜 CVE는 조직과 유지 관리자에게 상당한 운영 오버헤드와 보안 위험을 초래합니다:

  • 자원 낭비: 보안 팀은 존재하지 않는 취약점을 조사하고 패치하는 데 시간을 낭비합니다.
  • 오염된 데이터베이스: 취약점 데이터베이스는 "노이즈"로 포화되어 합법적인 중요한 위협을 식별하기 어렵게 만듭니다.
  • AI 기반 오복구: 자동 트라이지에 사용되는 AI 에이전트는 존재하지 않는 함수를 패치하려고 시도할 수 있으며, 이로 인해 실제 버그가 프로덕션 코드에 도입될 수 있습니다.
  • 유지 관리자 부담: 오픈소스 유지 관리자는 실제 보안 결함을 수정하는 대신 환각을 disprove하는 데 시간을 보내야 합니다.

"슬러그" CVE 식별 방법

조작된 권고에 속지 않으려면 보안 전문가는 다음과 같은 위험 신호를 찾아야 합니다:

  • 제조업체 corroboration 부족: 문제는 공식 유지 관리자 보안 페이지(예: sqlite.org/cves.html)에 언급되지 않습니다.
  • 커밋 기록 부재: 참조 필드에 연결된 커밋 해시 또는 풀 요청이 없습니다.
  • 메타데이터 모순: CPE 제품 정의가 비어 있거나 버전 범위가 권고 내러티브와 충돌합니다.
  • 존재하지 않는 코드 참조: 권고는 지정된 소프트웨어 버전에 존재하지 않는 함수 또는 라인 번호를 인용합니다.

커뮤니티 관점

산업 관찰자들은 보안 보고에서의 신호 대 잡음 비율 감소에 대해 우려를 표명했습니다. 일부 기여자는 LLMs가 실제 버그를 찾을 수 있지만, 검증 부족이 허위 보고를 통한 "대규모 공격"의 통로를 만든다고 지적했습니다.

"LLMs는 텍스트 예측 엔진입니다. 그들은 인공지능이 아니며, 어떤 형태나 방식으로도 지능을 가진 것처럼 취급되어서는 안 됩니다... 이제 우리는 수백만 달러에서 수천만 달러에 달하는 낭비된 생산성의 대가를 치르고 있습니다.

다른 사람들은 "출력 기계"가 "검증 기계"보다 먼저 구축되는 현재 추세가 소프트웨어 개발에 지속 불가능하다고 경고했습니다.

Sources

관련