출처
- source_url: https://aisparkup.com/posts/15006
- author: Spark
- published: Wed, 05 Aug 2026 04:43:07 +0000
- raw: raw source:
2026-08-05-aisparkup-post-15006-sqlite-55-54-ai-cve
개요
며칠 전 생성된 GitHub 계정이 SQLite 관련 취약점 보고서 55건을 제출했고, 그중 54건은 실제로 존재하지 않는 내용으로 JFrog Security Research가 분석했습니다. 보고서에는 대상 버전에 존재하지 않는 함수, 실제 파일보다 큰 줄 번호, 확인되지 않는 패치 기록 등이 포함돼 있었습니다. JFrog는 공식 SQLite 저장소의 해당 버전을 격리된 Docker 환경에서 빌드하고 PoC를 AddressSanitizer와 함께 실행했지만, 보고된 메모리 오류나 크래시를 재현하지 못했습니다. 이 사례는 CVE 제출과 전파 과정에서 재현성 검증이 충분하지 않을 경우, AI가 생성한 그럴듯한 허위 보고서가 하위 보안 데이터베이스와 기업 보안 도구로 유입될 수 있음을 보여줍니다.
핵심 포인트
- CVE-2026-51302는 CVSS 9.8로 평가됐지만, 취약점이 발생했다고 지목된
exprComputeOperands()함수는 대상인 SQLite 3.41.0에 존재하지 않았습니다. - 함께 언급된
sqlite3ReleaseTempReg()는 힙 메모리를 해제하는 함수가 아니어서, 보고서가 주장한 use-after-free 구조와 맞지 않았습니다. - 일부 보고서는 SQLite 버전의 실제 파일보다 큰 줄 번호를 인용했으며, 존재하지 않는 패치 변경 내역을 근거로 제시했습니다.
- JFrog가 공식 소스와 릴리스를 사용해 PoC를 실행한 결과, 크래시는 발생하지 않았고 일부 PoC는 실행 전에 문법 오류로 중단됐습니다.
- 해당 계정의 보고서 55건 중 54건이 완전한 조작으로 분석됐으며, 나머지 1건은 실제 버그였지만 검증되지 않은 메타데이터에 포함돼 있었습니다.
- MITRE의 제출 양식에는 실질적인 신원 확인 절차가 없고, 2024년 2월 이후 NVD의 심층 분석이 축소되면서 검증 공백이 커졌다고 JFrog는 설명했습니다.
왜 중요한가
취약점 심각도만을 기준으로 자동 티켓 생성이나 패치 작업을 수행하는 환경에서는 허위 보고서도 개발·보안 인력을 실제 문제처럼 움직이게 할 수 있습니다. 특히 AI 에이전트가 존재하지 않는 함수나 코드 위치를 찾도록 지시받으면, 취약점 해결 대신 정상 코드를 수정하는 잘못된 패치를 만들 가능성이 있습니다. 따라서 공식 보안 페이지 등재 여부, 커밋 해시와 PR 링크의 존재, 인용된 함수·파일·줄 번호의 실제 일치 여부, PoC 재현 결과를 확인하는 절차가 필요합니다. 다만 이 사례는 특정 CVE 전체가 허위라는 의미가 아니라, 검증되지 않은 취약점 정보가 자동화된 공급망을 통해 확산될 수 있다는 위험을 보여주는 사례입니다.
참고 링크
- 원문: https://aisparkup.com/posts/15006
- JFrog Security Research, “SQLite Critical CVEs or LLM Slop?”: https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/
- SQLite 공식 취약점 페이지: https://sqlite.org/cves.html
- NVD Program Transition Announcement: https://nvd.nist.gov/general/news/nvd-program-transition-announcement
- 관련 글, “AI 보안 리포트 폭증 뒤에 숨은 진짜 숫자, 악용률 1.3%”: https://aisparkup.com/posts/14969
관련 위키
원문 보존 위치
원문 전체는 raw source: 2026-08-05-aisparkup-post-15006-sqlite-55-54-ai-cve에 source_url 및 HTML 원문과 함께 저장되어 있습니다.