SQLite 보안 취약점 논쟁, 진짜 문제는 무엇인가?

SQLite 보안 취약점 논쟁: 진짜 문제는 무엇인가?

최근 며칠 동안 새롭게 생성된 GitHub 저장소( programmervuln/cveadvisory- )에서 SQLite의 취약점에 대한 여러 권고사항이 게시되었습니다. 이 권고사항들은 다른 50개 이상의 CVE와 함께 게시되었으며, JFrog 보안 연구팀은 이 중 하나를 제외하고는 모두 LLM 슬롭(LLM Slop)이라고 믿고 있습니다. NVD는 이들을 즉시 심각한 것으로 표시했고, CISA의 ADP도 이에 동의했습니다. 그러나 JFrog 보안 연구원들이 검증을 위해 조사했을 때, 이 주장들은 무너졌습니다. 인용된 코드는 해당 버전에서 존재하지 않거나 관련 없는 로직을 참조하고 있었으며, PoC 페이로드를 테스트했을 때도 작동하지 않았습니다. 이러한 CVE는 SQLite의 공식 권고 페이지에 나열되지 않았으며, 이 저장소의 모든 권고사항은 AI로 생성된 것으로 보입니다. Gptzero로 테스트한 결과, 모든 권고사항을 하나의 파일로 결합하면 AI 생성 콘텐츠 경고가 발생했습니다. 이는 이러한 CVE의 신뢰성을 의심하게 만들었으며, 이러한 CVE가 LLM 슬롭일 수 있음을 이해하게 되었습니다.

주요 CVE 분석

CVE-2026-51302: 존재하지 않는 로직 (9.8 Critical)
- 보고된 취약점: sqlite3ReleaseTempReg()가 regFree1에 남긴 포인터가 exprComputeOperands()에 의해 참조되면서 힙 사용 후 해제(UAF)가 발생한다고 주장.
- 발견 사항: exprComputeOperands()는 SQLite 3.41에 존재하지 않으며, sqlite3ReleaseTempReg()의 메커니즘은 힙 할당 해제를 포함하지 않음.
- PoC 테스트: 쿼리가 성공적으로 실행되었으며, 버그가 존재하지 않음.
CVE-2026-51303: 유령 수정 (9.8 Critical)
- 보고된 취약점: ExprListDelete()가 자식 노드를 해제할 때 부모 구조의 참조를 지우지 않는다고 주장.
- 발견 사항: Expr, Select, Window 구조에 그러한 상태를 초래할 수 있는 참조 포인터가 없음.
- PoC 테스트: PoC는 잘못된 SQL이며, 파서 단계에서 실패.
CVE-2026-51300: 잘못된 호출 사이트 (9.1 Critical)
- 보고된 취약점: sqlite3ExprDelete()에서 왼쪽 표현식 포인터가 지워지지 않아 UAF가 발생한다고 주장.
- 발견 사항: 인용된 줄 번호는 주석과 메모리 할당 호출로, 삭제 로직과 관련 없음.
- PoC 테스트: 유효한 SQL 쿼리로 실행되어 예상 출력 반환.
CVE-2026-51297 (8.8 High)
- 보고된 취약점: jsonParseFree()가 jsonBlobEdit()에 의해 참조되는 포인터를 남긴다고 주장.
- 발견 사항: jsonBlobEdit()는 보고된 대상 버전에 존재하지 않음.
- PoC 테스트: 잘못된 JSON 오류 발생.
CVE-2026-51296: 불가능한 줄 번호 (7.5 High)
- 보고된 취약점: jsonRemoveFunc에서 특정 줄 번호에서 UAF가 발생한다고 주장.
- 발견 사항: 인용된 줄 번호는 존재하지 않음.
- PoC 테스트: JSON 파싱 중 실패.
CVE-2026-51304 (7.5 High)
- 보고된 취약점: sqlite3ExprListDelete(pOrderBy)가 정렬 목록을 해제한 후 pOrderBy->nExpr을 읽는다고 주장.
- 발견 사항: 보고된 단일 인수 서명은 존재하지 않음.
- PoC 테스트: 정상적으로 정렬된 결과 반환.

AI 슬롭 CVE가 발생할 수 있는 이유

MITRE의 공개 양식을 통한 CVE 제출 과정은 신원 확인이 없어, 누구나 취약점 설명을 제출하고 CVSS 점수를 제안할 수 있습니다. 과거에는 NIST가 이 시스템의 안전망 역할을 했으나, 2024년 2월에 대량의 취약점 보고로 인해 깊은 분석이 중단되었습니다. CISA 및 기타 ADP가 자체 보강 노력을 시도했지만, 글로벌 파이프라인은 현재 단편화되어 있으며 대량의 백로그에 빠져 있습니다. 현재 시스템에서는 개념 증명이나 버그 재현이 요구되지 않기 때문에, 그럴듯한 가짜 권고사항이 파이프라인을 통과하여 GHSA, 하위 데이터베이스 및 기업 스캐너에 도달할 수 있습니다.

주요 시사점

이 사건은 자동화된 취약점 수집의 체계적 문제를 보여줍니다. 동일한 GitHub 계정에서 게시된 55개의 권고사항을 광범위하게 감사한 결과, 54개는 완전히 조작된 것이었고, 하나는 검증되지 않은 CVE 메타데이터로 포장된 실제 버그를 포함하고 있었습니다.

슬롭 CVE를 식별하는 경고 신호:
- 공식 유지보수자 보안 페이지에 문제에 대한 언급이 없음.
- 참조 필드에 커밋 해시나 풀 요청이 없음.
- 메타데이터 모순: 비어 있는 CPE 제품 정의 또는 권고 내러티브와 충돌하는 버전 범위.
- 존재하지 않는 코드 참조: 주장된 대상 버전에 존재하지 않는 함수나 EOF를 초과하는 줄 번호.

이러한 LLM 슬롭 CVE는 실제로 존재하지 않는 취약점을 조사하고 패치하는 데 시간을 낭비하게 하며, 취약점 데이터베이스를 오염시킬 수 있습니다. AI를 사용하여 취약점 분류 및 수정 작업을 자동화하는 환경에서는 더욱 우려됩니다. AI 에이전트가 조작된 CVE를 만나면 취약한 함수를 찾으려 하거나, 존재하지 않는 코드에 기반한 패치를 생성하거나 변경을 권장할 수 있습니다. 보안 팀이 실제 취약점을 수정하는 데 도움을 주는 대신, 잘못된 경로로 이끌어 불필요한 변경을 도입하고 시간을 낭비할 수 있습니다.

보고된 발견 사항

이러한 발견 사항을 GHSA, Redhat 및 NVD에 공식적으로 보고하여 이러한 기록의 수정을 지원했습니다.

파이랩 정리