며칠 전 만들어진 깃허브 계정이 SQLite 취약점 보고서를 무더기로 올렸고, NVD는 곧바로 최고 등급인 ‘심각’을 붙였습니다. CISA까지 동의했지만, 그 취약점들은 애초에 존재하지 않았습니다.
JFrog 보안 연구팀이 이 보고서들을 하나씩 뜯어봤습니다. 인용된 코드가 해당 버전에 없거나 엉뚱한 로직을 가리켰고, 첨부된 PoC를 그대로 실행해도 크래시가 나지 않았죠. SQLite 공식 취약점 페이지에는 이 중 어느 것도 올라 있지 않았습니다.
출처: SQLite Critical CVEs or LLM Slop? – JFrog Security Research
존재하지 않는 함수, 파일 끝을 넘는 줄 번호
가장 높은 점수를 받은 CVE-2026-51302는 CVSS 9.8이었습니다. 보고서는 exprComputeOperands()라는 함수에서 use-after-free가 일어난다고 주장했죠. 문제는 이 함수가 대상 버전인 SQLite 3.41.0에 아예 없었다는 겁니다. 2025년 중반에야 추가된 함수였으니까요.
같이 지목된 sqlite3ReleaseTempReg()도 마찬가지입니다. 이 함수는 힙 메모리를 해제하지 않습니다. 레지스터 번호를 배열에 넣어 재사용하는 게 전부라, 구조상 use-after-free가 나올 수 없죠.
줄 번호를 인용한 건도 있습니다. 어떤 보고서는 json.c의 3,555번째 줄과 3,575번째 줄을 문제 지점으로 지목했습니다. 그 버전의 json.c는 2,706줄짜리 파일입니다. 존재하지 않는 줄을 가리킨 셈이죠.
패치 기록을 지어낸 사례도 나왔습니다. 한 보고서는 3.51.3에서 수정됐다고 적었는데, 3.51.2와 3.51.3 사이의 diff에는 src/expr.c 변경이 단 한 줄도 없었습니다.
격리 환경에서 하나씩 돌려봤다
JFrog는 추정으로 판단하지 않고 검증 절차를 세웠습니다. 공식 sqlite/sqlite 저장소를 클론해 문제가 된 태그들을 각각 체크아웃하고, 도커 컨테이너 안에서 공식 릴리스를 직접 빌드했죠. 환경이 섞이는 걸 막기 위해서입니다.
그다음 각 보고서의 PoC SQL을 그대로 집어넣었습니다. 메모리 오류를 잡아내는 AddressSanitizer를 붙인 상태로요. 결과는 일관됐습니다. 크래시는 나오지 않았고, 일부 PoC는 실행 로직에 닿기도 전에 문법 오류로 파서 단계에서 멈췄습니다.
한편 이 보고서들을 하나로 합쳐 GPTZero에 넣자 AI 생성 콘텐츠 경고가 떴습니다. 레드햇이 CVE-2026-51302에 처음 부여했던 10.0점이 다음 날 7.6으로 내려간 것도 JFrog가 포착한 정황이고요.
어쩌다 이게 통과했을까
MITRE의 공개 제출 폼에는 실질적인 신원 확인이 없습니다. 사실상 누구나 취약점 설명을 올리고 CVSS 점수까지 제안할 수 있죠.
원래 이 구멍을 메우던 게 NIST였습니다. NVD 전문가들이 들어오는 CVE를 직접 분석하고 검증한 뒤 승인 도장을 찍었으니까요. 그 안전망이 2024년 2월에 끊겼습니다. 보고 건수가 폭증하면서 NIST가 심층 분석을 사실상 중단했거든요.
CISA를 비롯한 승인 데이터 발행기관들이 빈자리를 메우려 했지만, 파이프라인은 파편화됐고 백로그에 잠겼습니다. 지금 이 과정의 어느 단계도 PoC나 재현을 요구하지 않습니다. 그럴듯하게 쓰인 가짜 하나가 GHSA와 하위 데이터베이스를 거쳐 기업 스캐너까지 그대로 흘러갈 수 있다는 뜻이죠.
같은 계정을 전수 조사한 결과가 규모를 보여줍니다. 55건 중 54건이 완전한 조작이었고, 나머지 하나는 실제 버그이긴 하지만 검증되지 않은 메타데이터에 싸여 있었습니다.
AI가 AI 슬롭을 고치려 들 때
여기서 한 겹이 더 붙습니다. 취약점 분류와 수정을 AI에게 맡긴 환경이라면 어떻게 될까요.
에이전트는 존재하지도 않는 함수를 코드베이스에서 찾으려 들 겁니다. 못 찾으면 비슷해 보이는 자리를 골라 패치를 만들어낼 수도 있죠. 실제 취약점을 고치는 대신 멀쩡한 코드를 건드리며 시간을 쓰는 방향으로 흘러갑니다.
JFrog가 꼽은 식별 신호는 단순합니다. 메인테이너 공식 보안 페이지에 언급이 없는 경우, 참조 필드에 커밋 해시나 PR 링크가 비어 있는 경우, 그리고 존재하지 않는 함수나 파일 끝을 넘는 줄 번호를 인용한 경우.
이번 건이 드러낸 건 특정 계정의 장난이 아닙니다. AI로 그럴듯한 문서를 대량 생산하는 비용이 거의 0에 가까워졌는데, 그걸 걸러내는 쪽은 여전히 사람 손과 시간에 묶여 있다는 비대칭이죠. 심각 등급 하나에 자동으로 티켓이 열리는 환경일수록 그 비대칭의 값은 비싸집니다.
JFrog는 이 결과를 GHSA와 레드햇, NVD에 공식 보고했습니다.
참고자료:
답글 남기기