KV 캐시 노출이란? 클라우드플레어 GLM-5.3 사고와 AI API 점검법
클라우드플레어 Workers AI GLM-5.3에서 다른 고객 요청 데이터가 응답 155건에 섞인 KV 캐시 노출 사고의 원인, 영향 기간, API 사용자가 로그와 민감정보를 점검하는 순서를 정리했어요.
목차8개 섹션
핵심 요약
- 클라우드플레어는 2026년 10월 26일, Workers AI의 GLM-5.3(@cf/zai-org/glm-5.3)에서 2026년 8월 27일~9월 9일 응답 155건에 다른 고객 요청 데이터가 섞였다고 공개했어요.
- 영향받은 응답은 모두 68만 1,280토큰을 넘는 프롬프트에 대한 것이었고, 회사는 의도적 악용 증거를 찾지 못했으며 다른 모델은 영향이 없었다고 밝혔어요.
- 원인은 프리필 GPU의 KV 캐시 풀(68만 1,280토큰)이 광고한 컨텍스트 길이(104만 8,576토큰)보다 작았던 설정과, 거절된 요청을 오류 없이 넘긴 SGLang 버그가 겹친 것이에요.
- 해당 기간 GLM-5.3을 쓴 개발자는 호출 로그의 모델 이름·시각·prompt_tokens를 확인하고, 저장된 응답에 내 요청과 무관한 내용이 있는지 살펴보는 것이 출발점이에요.
- 직접 SGLang을 운영한다면 공식 권고대로 v0.5.22 이상으로 올리고 노드별 KV 풀 크기를 컨텍스트 길이와 비교해야 해요.
KV 캐시 노출은 AI 추론 서버가 이전 요청이 남긴 GPU 메모리(KV 캐시)를 지우지 않은 채 다음 요청의 응답 생성에 읽어 들여, 다른 사용자의 프롬프트나 응답 조각이 섞여 나오는 사고예요. 2026년 10월 26일 클라우드플레어는 공식 블로그에서 Workers AI의 GLM-5.3 모델(@cf/zai-org/glm-5.3)에서 2026년 8월 27일부터 9월 9일까지 응답 155건에 다른 고객 요청의 데이터가 들어갔다고 밝혔어요. 이 글은 2026년 10월 기준 클라우드플레어와 SGLang 팀의 공식 공개 자료만 근거로, 무슨 일이 있었는지와 API 사용자가 지금 확인할 점을 정리해요.
이 글의 시각은 모두 협정 세계시(UTC) 기준이에요. 한국 시각은 9시간을 더하면 돼요. 영향 범위는 공식 공지에 적힌 내용만 다루며, 고객별 영향 여부는 클라우드플레어가 공개하지 않았어요.
클라우드플레어 GLM-5.3 KV 캐시 노출, 무슨 일이 있었나
보안 연구자 Gadi Evron(Knostic)이 2026년 9월 8일 클라우드플레어의 HackerOne 프로그램으로 "아주 긴 프롬프트를 GLM-5.3에 보내면 가끔 다른 사용자 세션의 텍스트가 돌아온다"고 제보했어요. 클라우드플레어는 다음 날 서로 다른 두 계정으로 유출을 재현했고, 사고 선언 약 40분 만에 모델을 비공개로 돌려 요청이 HTTP 400을 받게 했어요. 같은 날 설정과 엔진을 고친 뒤 서비스를 복구했어요.
| 시각(UTC) | 내용 |
|---|---|
| 2026-08-27 | GLM-5.3이 KV 풀이 컨텍스트보다 작은 상태로 출시, 노출이 출시 시점부터 존재 |
| 2026-09-08 23:11 | HackerOne으로 제보 접수 |
| 2026-09-09 13:22 | 보안 사고 선언, 25분 안에 두 계정으로 재현 |
| 2026-09-09 14:00 | GLM-5.3 비공개 전환(요청에 HTTP 400), 상태 페이지 갱신 |
| 2026-09-09 14:52 | 모든 프리필 노드에 수정된 설정 적용 |
| 2026-09-09 19:40 | 엔진 패치까지 적용한 뒤 공개 복구 |
| 2026-10-26 | 연구자·SGLang 팀(RadixArk)과 공동 공개 |
공식 글에 따르면 영향받은 응답은 총 155건이고, 모두 68만 1,280토큰을 넘는 프롬프트에 대한 응답이었어요. 클라우드플레어는 자체 테스트와 연구자의 요청을 빼면 확인된 요청의 시점과 양이 평범한 긴 컨텍스트 사용과 비슷하며 의도적 악용 증거는 찾지 못했다고 했어요. Workers AI의 다른 모델은 영향이 없었다고 확인했어요. 당시 상태 페이지에는 9월 9일 14:25~20:09(UTC) 'GLM 5.3 오류 증가'로만 표시됐어요.
KV 캐시란? 공유 추론 서버에서 데이터가 섞인 원리
대형 언어 모델은 답을 한 토큰씩 만들 때마다 앞선 모든 토큰을 다시 계산하지 않도록, 각 토큰의 중간 계산값(키·값 벡터)을 GPU 메모리에 저장해 둬요. 이것이 KV 캐시예요. 클라우드플레어 설명에 따르면 GPU의 KV 캐시는 고정 크기 페이지로 나뉜 공유 풀이고, 요청이 들어오면 페이지를 배정했다가 끝나면 반납해요. 성능 때문에 페이지는 요청 사이에 0으로 지우지 않고 다음 요청이 덮어써요. 그래서 엔진이 "이 페이지는 누구 것인지"를 정확히 추적하는 것이 격리의 핵심이에요.
두 가지 문제가 겹쳤어요
- 설정 불일치: GLM-5.3은 104만 8,576토큰 컨텍스트로 배포됐지만, 프롬프트를 처리하는 프리필 GPU의 KV 풀은 68만 1,280토큰만 담을 수 있었어요. 클라우드플레어는 이 차이를 출시 전에 알았지만 엔진이 처리 못 하는 요청은 오류를 낼 것이라 예상했고, 긴 컨텍스트 테스트는 HTTP 상태 코드만 확인해 성공으로 판단했어요.
- SGLang 버그: 프롬프트 처리(프리필)와 답 생성(디코드)을 다른 GPU에서 나눠 하는 분리형 모드에서, 풀에 안 들어가는 요청은 내부적으로 '거절' 표시와 함께 1토큰짜리 자리표시로 바뀌었어요. 그런데 대기열은 '끝났는지'만 확인하고 '거절됐는지'는 보지 않아 요청이 계속 진행됐어요.
- 결과: 디코드 쪽은 긴 프롬프트 길이만큼 페이지를 예약했지만 실제로 새로 채워진 건 첫 페이지뿐이었어요. 나머지 페이지에 남아 있던 이전 요청의 프롬프트와 생성 중간값을 그대로 읽어 답을 만들었고, 사용자에게는 HTTP 400 대신 HTTP 200과 그럴듯한 응답이 돌아갔어요.
눈여겨볼 점은 오류가 전혀 나지 않았다는 거예요. 응답의 prompt_tokens는 긴 프롬프트와 맞았고 답도 문장으로서 자연스러웠어요. 클라우드플레어가 밝힌 이상 신호는 8페이지 분량을 처리했어야 할 요청치고 응답이 너무 빨랐다는 정도예요. 이런 결함은 서비스 모니터링이 상태 코드만 보면 놓치기 쉬워요.
내 서비스가 영향을 받았는지 확인하는 순서
클라우드플레어 공지에는 고객별 조치 목록이나 영향받은 요청 목록이 따로 실려 있지 않아요. 그래서 사용자 쪽 로그로 노출 가능성을 좁히는 것이 현실적인 방법이에요.
- 1
모델과 기간 확인
애플리케이션 로그나 AI Gateway 기록에서 2026년 8월 27일~9월 9일(UTC) 사이
@cf/zai-org/glm-5.3호출이 있었는지 찾아요. 이 모델을 쓰지 않았다면 이 사고의 직접 영향은 없어요. - 2
긴 프롬프트 호출 추리기
같은 기간 호출 중 입력 토큰 수(
prompt_tokens)가 68만 1,280을 넘는 요청을 골라요. 공식 설명상 다른 고객 데이터를 받은 응답은 모두 이 조건에 해당해요. - 3
저장된 응답 내용 검토
해당 응답을 저장해 뒀다면 내 요청과 무관한 이름·코드·문서 조각이 있는지 확인해요. 남의 데이터로 보이는 내용은 다른 시스템에 재사용하거나 학습 데이터로 쓰지 말고 내부 정책에 따라 격리·삭제해요.
- 4
내 데이터가 원천이었을 가능성 평가
섞인 데이터는 같은 모델에 직전 들어온 요청에서 나왔어요. 그 기간 GLM-5.3에 API 키·비밀번호·개인정보를 넣은 적이 있다면, 해당 자격증명을 바꾸고 개인정보 담당자와 신고 의무가 있는지 검토하는 게 안전해요.
- 5
궁금한 점은 공식 경로로 문의
영향 여부를 확정할 수 없으면 클라우드플레어 지원 창구로 계정 단위 확인을 요청해요. 새 취약점을 발견했다면 공지가 안내한 HackerOne 프로그램으로 제보해요.
AI API 보안 점검: 민감정보 입력과 로그 관리
이번 사고는 제공자가 "입력을 저장하지 않는다"고 약속해도, 처리 중인 메모리 단계에서는 격리 결함이 생길 수 있다는 점을 보여 줬어요. 클라우드플레어 Data usage 문서(2026년 10월 16일 갱신)는 상태를 쓰지 않는 일반 추론 요청의 입력·출력을 처리 후 보관하지 않고 학습에도 쓰지 않는다고 설명해요. 다만 AI Gateway 로깅·캐싱을 켜거나 앱 로그에 프롬프트를 쓰면 그 설정에 따라 저장된다고 적고 있어요.
프롬프트 최소화
- 왜 필요한가
- 처리 중 노출되면 넣은 만큼 새어 나감
- 실행 예
- API 키·주민번호·카드번호는 보내기 전 마스킹
응답 이상 탐지
- 왜 필요한가
- 이번 사고는 오류 없이 HTTP 200으로 왔음
- 실행 예
- 입력과 무관한 고유명사·코드 등장 시 경고
로그 보관 범위
- 왜 필요한가
- 내 로그도 민감정보 저장소가 됨
- 실행 예
- 원문 대신 토큰 수·시각·모델만 남기기
모델·버전 기록
- 왜 필요한가
- 공지가 특정 모델·기간 단위로 나옴
- 실행 예
- 요청마다 모델 ID와 시각 저장
대체 경로
- 왜 필요한가
- 문제 모델이 비공개로 바뀔 수 있음
- 실행 예
- 다른 모델로 넘기는 폴백 설정
AI 보안 사고와 업계 반응은 빠르게 퍼지므로, 관련 논의를 따라가려면 AI 텔레그램 채널 트렌드에서 채널들이 같은 사고를 어떻게 다루는지 볼 수 있어요. 국내 개발 블로그의 대응 정리는 블로그 트렌드에서 모아 볼 수 있어요.
자체 추론 서버를 운영한다면: SGLang 권고 사항
SGLang은 클라우드플레어가 쓰는 오픈소스 추론 엔진이에요. SGLang 팀 공개 글은 이 버그가 프리필·디코드를 분리한 배포에서만 생겼고, 단일 노드 배포에서는 거절 경로가 정상적으로 오류를 돌려줬다고 설명해요. 같은 글은 요청이 전송 도중 중단될 때 늦게 도착한 RDMA 쓰기가 다른 요청의 KV 캐시에 들어가는 별도의 경쟁 조건 계열도 함께 고쳤다고 밝혔어요.
- 버전 올리기: 클라우드플레어는 SGLang에 의존하는 모든 운영자에게 v0.5.22 이상으로 업데이트할 것을 강하게 권고했어요. 이번 사고를 막는 핵심 수정은 #36988(v0.5.20)과 #38935(v0.5.21)이에요.
- KV 풀과 컨텍스트 길이 비교: 가중치·양자화·병렬화·메모리 비율을 바꿀 때마다 모든 프리필·디코드 노드의 시작 로그에서 KV 풀 크기를 확인하고, 풀이 더 작으면 컨텍스트 길이를 낮춰요. 프록시가 한도를 막아 줄 거라 가정하지 말라고 했어요.
- 지연 반납(deferred KV release): 양쪽 역할 모두에서 켜고, Mooncake 전송 배치 크기에 상한을 둬요.
- 손상 탐지 켜기:
--disaggregation-enable-kv-checksum과 KV 카나리는 아직 모든 모델 구조를 지원하지 않으므로 로그에서 실제로 검증되는지 확인해요. - 출력 내용까지 테스트: 클라우드플레어는 상태 코드와 성능만 검증하고 출력의 일관성은 보지 않은 것을 테스트의 결정적 빈틈으로 꼽았어요.
SGLang 팀은 경쟁 조건 계열의 손상은 오류나 로그를 남기지 않아 이미 노출이 있었는지 운영자가 확실히 알 방법이 없다고 밝혔어요. 업그레이드 후에는 v0.5.22의 지연 반납 지표로 보호가 작동하는지 확인하라고 권고했어요.
공식 발표로 알 수 있는 것과 없는 것
공지로 확인되는 사실은 영향 모델(GLM-5.3 하나), 기간(2026년 8월 27일~9월 9일), 응답 수(155건), 조건(68만 1,280토큰 초과 프롬프트), 악용 증거 없음, 수정 내용이에요. 수정 후 프리필 KV 풀은 약 204만 토큰으로 컨텍스트 길이의 약 두 배가 됐다고 해요.
반대로 섞인 데이터가 어떤 종류였는지, 개인정보가 포함됐는지, 어느 고객의 요청이 원천이었는지는 공개되지 않았어요. 그러니 "내 데이터는 확실히 안전하다"거나 "대규모 유출"이라는 단정은 모두 근거가 부족해요. 공유 GPU에서 여러 고객의 요청을 처리하는 멀티테넌트 추론은 비용을 낮추지만, 메모리 격리는 엔진 코드의 정확성에 달려 있다는 점을 기억하고 민감한 업무는 입력 최소화와 내부 로그 관리부터 점검하는 것이 현실적인 대응이에요.
