AI가 지어낸 SQLite 취약점 6건, 9.8점 받고 NVD에 올랐다가 철회

AI 요약

• 무슨 일: SQLite 취약점 CVE 6건(CVSS 9.8부터 7.5)이 미국 정부 취약점 DB인 NVD에 올랐다가 나흘 만에 철회. 지목된 함수가 해당 버전에 존재하지 않았습니다.
  • JFrog 검증: PoC 전부 크래시 없음, json.c 3555행 지목했으나 파일은 2,706행
  • SQLite 프로젝트 공식 CVE 페이지 표기: "재현되지 않는다. AI 환각으로 보인다"
• 규모: 같은 GitHub 계정이 올린 자문 55건 중 54건이 조작. SQLite 외에 libraw, ESP32-audioI2S도 대상.
• 왜 통과했나: CVE 발급·게시 절차 어느 단계에도 재현(PoC) 요구가 없습니다. NVD는 2024년 이후 심층 분석을 사실상 멈췄고 미보강 적체가 27,000건을 넘겼습니다.
• 아직 안 끝났습니다: NVD는 Rejected 처리했지만 GitHub 자문 DB의 GHSA-vrg3-8p22-cwh8은 8월 3일까지 Critical 9.8, Unreviewed로 남아 있습니다. 이 DB를 참조하는 스캐너는 여전히 경보를 냅니다.

SQLite 취약점 6건이 공용 보안 데이터베이스에 최고 등급으로 올라왔다가 나흘 만에 철회됐습니다. 보고서가 지목한 함수가 그 버전에 아예 없었기 때문입니다.

CVE는 소프트웨어 취약점에 붙는 전 세계 공용 일련번호입니다. 번호가 붙으면 기업 보안 스캐너가 의존성 목록을 훑다가 자동으로 잡아내고, 담당자는 패치 일정을 잡습니다. 개발자가 아니어도 결과는 같습니다. CVE 하나가 수천 개 조직의 작업 시간을 만들어냅니다.

문제의 6건은 2026년 7월 27일 MITRE에 접수돼 미국 정부 취약점 데이터베이스 NVD에 올랐습니다. CVSS 점수는 최고 9.8이었고, CISA의 보강 프로그램(ADP)이 점수 벡터까지 덧붙였습니다. JFrog 보안 연구원 Afek Berger가 7월 30일 검증 결과를 공개했고, MITRE는 다음 날 6건을 모두 철회했습니다.

2,706행짜리 파일의 3,555행을 지목했다

JFrog가 한 일은 단순합니다. 보고서에 적힌 대로 그냥 재현해 본 것입니다. 공식 저장소 sqlite/sqlite를 내려받아 문제로 지목된 태그 세 개(version-3.41.0, version-3.51.2, version-3.51.3)를 체크아웃하고, 메모리 오류를 잡아주는 AddressSanitizer를 켠 채로 빌드한 뒤 첨부된 공격 코드를 실행했습니다.

크래시는 한 건도 나지 않았습니다. 일부 공격 코드는 SQL 파서 단계에서 먼저 실패해 취약하다는 코드 근처에도 가지 못했습니다.

여섯 건이 공통으로 주장한 결함은 use-after-free, 즉 프로그램이 이미 반납한 메모리를 다시 읽어버리는 버그입니다. 실제로 있으면 원격 공격자가 정보를 빼내거나 코드를 실행할 수 있어 점수가 높게 나옵니다. 문제는 그 버그가 있다고 지목한 위치였습니다.

자문이 주장한 내용	JFrog가 확인한 사실
CVE-2026-51302: exprComputeOperands()에서 해제 후 참조	이 함수는 SQLite 3.41에 없습니다. 2025년 중반에 추가됐습니다
CVE-2026-51297: jsonBlobEdit() 경유	3.41.0에 존재하지 않는 함수입니다
CVE-2026-51296: json.c 3555행과 3575행	해당 파일은 전체 2,706행입니다
CVE-2026-51300: 특정 행의 해제 후 참조	지목된 행은 주석이거나 무관한 메모리 할당 호출입니다
CVE-2026-51303: 3.51.3에서 수정됨	그 릴리스 diff에 src/expr.c 변경이 없습니다

JFrog는 자문 전체를 한 파일로 합쳐 AI 탐지 도구 GPTZero에 넣으면 AI 생성 경고가 뜬다고 덧붙였습니다. 게시자는 그달에 만들어진 GitHub 저장소 programmervuln/cveadvisory-였고, 같은 계정이 올린 자문 55건 가운데 54건이 같은 방식이었습니다. 나머지 한 건은 실제 버그였지만 메타데이터는 검증되지 않은 상태였습니다. 대상도 SQLite에 그치지 않아 이미지 처리 라이브러리 libraw와 임베디드 오디오 라이브러리 ESP32-audioI2S까지 번졌습니다.

같은 CVE 번호인데 기관마다 표시가 다르다

철회로 상황이 정리되지는 않았습니다. 같은 CVE 번호를 다루는 네 곳이 지금 서로 다른 내용을 보여줍니다.

• NVD: 6건 모두 Rejected. 사유 문구는 "이 레코드는 CNA에 의해 철회되었다. 추가 조사 결과 보안 이슈가 아닌 것으로 확인되었다"입니다. 점수·CWE 분류·참조 링크가 함께 삭제됐습니다.
• SQLite 프로젝트: 공식 CVE 페이지 sqlite.org/cves.html에 6건을 한 줄로 묶고 "SQLite의 버그가 아님"으로 표기했습니다. 설명은 "재현되지 않는다. AI 환각으로 보인다. JFrog.com의 분석을 참고하라"입니다.
• Red Hat: CVE-2026-51302에 처음 10.0 Critical을 매겼다가 7.6 High로 낮췄습니다.
• GitHub 자문 DB: 8월 3일 확인 시점에 여전히 Critical 9.8, 상태 Unreviewed입니다.

이 화면 하나에 JFrog가 정리한 위험 신호가 거의 다 들어 있습니다. 영향 패키지가 "No package listed"이고, 영향 버전과 패치 버전이 둘 다 "Unknown"입니다. 참조 링크 세 개 중 메인테이너의 커밋이나 PR을 가리키는 것은 없고, 하나는 자문을 올린 그 저장소를 되가리킵니다. 그런데 오른쪽 점수는 9.8입니다.

스캐너 대부분은 NVD와 GitHub 자문 DB를 함께 읽습니다. 한쪽이 철회해도 다른 쪽이 살아 있으면 경보는 계속 나옵니다.

재현을 요구하는 단계가 아예 없다

이번 사건에서 새로 드러난 부분은 가짜 리포트를 만든 사람이 아니라 그것을 걸러낼 지점이 절차에 없다는 사실입니다. JFrog는 이렇게 적었습니다.

"오늘날의 절차 어느 단계에서도 PoC나 버그 재현을 요구하지 않기 때문에, 그럴듯하게 들리는 가짜 자문이 파이프라인을 그대로 통과해 GitHub Security Advisories, 하위 데이터베이스, 기업 스캐너까지 도달할 수 있다."

Berger는 The Register에 비용 비대칭을 지적했습니다. "생성형 AI는 그럴듯해 보이는 자문을 만드는 데 드는 노력을 거의 0으로 낮췄지만, 그것을 검증하는 노력은 그대로다."

검증 쪽 여력은 오히려 줄었습니다. NVD는 2024년 2월 이후 개별 CVE 심층 분석을 사실상 멈췄고, 보강되지 않은 CVE 적체가 2025년 말 27,000건을 넘겼습니다. CVE 제출량은 2020년부터 2025년까지 263% 늘었고 2026년 1분기는 전년 동기보다 약 33% 많습니다. NIST는 2025년에 약 42,000건을 보강해 직전 최고치보다 45% 많은 처리량을 냈지만 유입을 따라잡지 못했습니다.

그래서 NIST는 2026년 4월 15일 방침을 바꿨습니다. CISA의 실제 악용 목록(KEV), 연방정부가 쓰는 소프트웨어, 행정명령 14028이 정의한 핵심 소프트웨어에 해당하는 CVE만 즉시 분석하고 나머지는 "최저 우선순위"로 두기로 했습니다. 2026년 3월 1일 이전의 미보강 CVE는 통째로 "Not Scheduled"로 옮겼습니다. 이번 6건은 그 정책이 시행되고 석 달 뒤에 올라왔습니다.

방향은 1B 모델이 753B를 이긴 Cisco Antares 때와 정반대입니다. 그때는 AI로 취약점을 1달러에 찾아내는 쪽이 화제였습니다. 이번에는 AI로 취약점을 지어내는 쪽이 먼저 임계점을 넘었습니다. 찾는 비용과 지어내는 비용이 함께 0으로 내려가면, 남는 병목은 재현입니다.

JFrog가 제시한 위험 신호 네 가지는 사람이 5분 안에 확인할 수 있는 것들입니다.

취약점 대응을 코딩 에이전트에 맡겨 둔 팀이라면 위험이 하나 더 있습니다. 에이전트는 존재하지 않는 함수를 못 찾고 멈추는 대신, 그럴듯한 패치를 지어내는 쪽으로 갈 수 있습니다. 사람이 읽었다면 "이 함수가 없는데요"에서 끝났을 작업입니다.

지난주에 SCA 스캐너가 SQLite 3.41이나 3.51 계열에 Critical을 띄웠다면, 티켓을 만들기 전에 CVE 번호를 NVD와 sqlite.org/cves.html 두 곳에서 각각 조회하는 것으로 이번 6건은 정리됩니다. NVD가 Rejected를 보여줘도 GitHub 자문 DB를 함께 읽는 스캐너는 아직 9.8을 보고하므로, 스캐너 출력만으로 판단하면 없는 취약점에 사람을 붙이게 됩니다. 다음 배치가 또 올 것을 감안하면, 신규 계정이 게시한 Critical에 대해 메인테이너 커밋 링크가 참조에 없으면 티켓을 열지 않는다는 규칙 한 줄을 트리아지 절차에 넣어 두는 편이 매번 재현해 보는 것보다 쌉니다.