Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
GLM-5.3 모델에서 요청 간 KV 캐시가 노출되는 보안 취약점이 발견되어 시스템 아키텍처 수정이 이루어졌습니다. 이 문제는 사용자 세션 격리 부족으로 인해 발생하며, Prefill 풀 확장 및 메모리 안전성 강화 조치를 통해 해결되었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기GLM-5.3 구성을 GLM-5.2와 맞춰 GPU 메모리를 확보하고, prefill 풀을 약 204만 토큰으로 늘림
이는 컨텍스트 길이의 약 두 배로, 유효한 요청은 항상 풀에 들어가 해당 거부 경로에 진입하지 않음
풀 크기만으로는 충분하지 않아 거부 경로도 안전하게 수정함
양자화, 텐서 병렬화, CUDA 그래프 크기, 모델 버전 변경으로 풀 크기가 달라질 수 있고, 다른 사유로 prefill 스케줄러가 요청을 거부할 수도 있음
거부 대기 상태의 요청은 부트스트랩, 메모리 할당, KV 전송 전에 분리형 진입 큐에서 원래 오류와 함께 종료하도록 변경함
Cloudflare의 제안 #38704에는 전송 토큰 수와 예약 토큰 수를 decode에서 대조하는 검사도 포함됐음
관련 실패 경로를 고친 #36988은 9월 6일 SGLang main에 이미 병합됐지만 당시에는 미출시 상태였음
유지관리자는 Cloudflare 방식에 따라 더 이른 단계에서 요청을 거부하는 #38935도 병합함
제보자의 재현 스크립트와 자체 카나리 마커 테스트로 두 변경을 검증한 후 모델을 복구함
엔진 수정과 후속 강화 조치는 SGLang으로 제공하는 모든 모델에 적용했으며, 신규 배포 검사에서도 필수로 요구함
대응 일정
모든 시각은 UTC 기준임
8월 27일: 컨텍스트보다 작은 prefill KV 풀로 GLM-5.3을 출시하며 노출이 시작됨
9월 8일 23:11: HackerOne 신고를 접수함
9월 9일: 검증, 차단, 수정, 복구를 진행함
08:00에 신고 검증을 시작함
13:22에 보안 사고를 선언하고, 제품 보안팀이 독립된 계정 2개로 25분 안에 유출을 재현함
14:00에 모델을 비공개로 전환해 HTTP 400을 반환하도록 하고 상태 페이지를 갱신함
14:35에 풀 용량 부족을 원인으로 확인하고, 확대한 카나리 prefill 노드에서 문제가 재현되지 않음을 검증함
14:52에 모든 prefill 노드의 구성을 수정함
19:04에 수정 구성과 자체 엔진 패치로 전체 배포를 재구축하고 재현 스크립트로 검증함
19:40에 모델을 다시 공개함
9월 10일 23:30: RadixArk CTO와 핵심 엔지니어 등 SGLang 유지관리자와 업스트림 수정에 합의함
9월 11~19일: 모든 프로덕션 SGLang 배포에 추가 강화 조치를 적용함
9월 16일~10월 12일: 업스트림에 진입 처리 수정, 전송별 체크섬, 중단 확인 보존, KV 지연 해제 기본 활성화가 병합됨
10월 2일과 19일: 각각 SGLang v0.5.21과 v0.5.22가 출시됨
10월 26일: 연구자 및 RadixArk와 조율해 공개함
KV 캐시 메모리 안전성 강화
관련 버그는 다른 작업이 아직 사용하는 페이지를 해제하거나 재사용하거나 읽는 문제로 이어지며, 크게 두 유형이 있음
노드 내부 수명 관리: 토큰 생성, 호스트 메모리 오프로딩, KV 수신, 중단/오류 처리가 같은 페이지를 공유하다가 한 작업이 너무 일찍 해제할 수 있음. 기존 decode 오프로딩 수정 #24226, #30899과 문법 오류 시 이중 해제 수정 #30937이 이에 해당함
노드 간 경쟁 상태: 중단 전에 이미 발송한 RDMA 쓰기는 회수할 수 없으므로, decode가 페이지를 즉시 재사용하면 늦게 도착한 쓰기가 다른 요청의 캐시를 덮어씀. Cloudflare는 #31357, #38961과 재현 스크립트 #32564로 수정에 기여함
두 유형 모두 오류 없이 출력이 손상되거나 다른 사용자 데이터가 노출될 수 있음
이번 사고는 타이밍에 따른 경쟁 상태가 아니라 거부된 요청이 매번 인계되는 문제였음
기존 수정은 prefill의 거부 사실을 decode가 알지 못하는 이번 경로를 막지 못했음
이건 GLM-5.3 자체와는 무관함. 여러 사용자가 모델을 공유하는 환경에서 상태 관리를 제대로 하지 않으면 발생하는 일이며, 어떤 모델인지는 상관없음. 사용자 세션 간 격리가 부족해, 절대 겹쳐서는 안 되는 메모리가 겹칠 수 있다는 뜻임.
Z.AI 모델의 버그라기보다는 SGLang과 Cloudflare의 버그이며, 모델 제작사가 무엇을 할 수 있었을지 모르겠음. Cloudflare가 제목에 무관해 보이는 다른 당사자를 넣기보다 책임을 져야 함.
어디에서도 모델의 버그라고 하지 않았음. Cloudflare의 잘못된 설정과 SGLang의 버그였음을 구체적으로 밝혔음. 고객이 어느 엔드포인트가 영향을 받았는지 알아야 하므로 제목에 모델명을 넣은 것임. 실제 표현도 “GLM-5.3”이 아니라 “GLM-5.3 Workers AI 모델”임.
캐싱 관련 문제라면 모델 자체와는 거의 무관하다는 게 명확해 보임. 제목만 보고도 해당 모델을 사용한 경우에만 영향받을 수 있음을 알 수 있어 좋음.
GLM-5.3과 관련은 있지만, 모델 자체와 무관하다는 말은 맞음. 영향을 받은 것은 GLM-5.3을 제공하는 엔드포인트임. GLM-5.3이라는 이름 없이 그 엔드포인트를 어떻게 지칭할지 모르겠음. 다만 제목의 “모델”이라는 단어는 오해를 부른다고 봄.
모델 제작자의 국적 때문에 의도적으로 편향된 제목을 붙였다는 뜻으로 들림. 하지만 글의 첫 문장은 “2026년 9월 8일, Knostic의 보안 연구원 Gadi Evron으로부터 2026년 8월 27일부터 GLM-5.3 Workers AI 모델(@cf/zai-org/glm-5.3)에 영향을 준 테넌트 격리 문제를 전달받았다”는 내용임.
즉, GLM-5.3 Workers AI의 캐시 노출 문제임. 제목이 단순히 “GLM-5.3의 캐시 노출 문제”였다면 모호하고 의도적으로 해로울 수도 있다는 데 동의하겠지만, 실제로는 Cloudflare 제품임이 분명한 “Workers AI 모델”이라고 적혀 있음.
대부분의 글보다 이번 근본 원인 분석(RCA) 이 훨씬 마음에 듦. 책임을 인정하고 테스트가 왜 버그를 잡지 못했는지 명확히 설명한 점이 좋음.
모델 제공을 신속히 중단하고 비교적 빠르게 수정한 것도 인상적임. 수정 속도보다도, 자체 플랫폼에서 모델 제공을 즉시 차단할 수 있는 대응력을 확인한 것이 더 중요하게 느껴짐.
“GLM 5.3을 1,048,576토큰 문맥 창으로 배포했지만, 프리필 GPU의 KV 캐시 풀에는 681,280토큰만 담을 수 있었고, 출시 전부터 이 불일치를 알고 있었다”고 함. 실제로는 681,280토큰만 수용할 수 있는데 1,048,576토큰이라고 광고한 것인가?
바로 다음 문장은 “처리할 수 없는 프롬프트에는 엔진이 오류를 반환할 것으로 예상했고, 긴 문맥 테스트에서도 성공 응답이 반환돼 문제라고 여기지 않았다”임.
결국 오버플로 위험을 알면서도 배포한 셈이며, 버퍼 오버플로 공격이 가능한 코드를 작성한 것과 비슷함. 그런 상황을 직접 만들어 놓고도 “아마 스마트 포인터를 쓰겠지, 괜찮을 것”이라는 식으로 안전하다고 가정한 것으로 읽힘.
캐시 적중이나 생성과는 별개로, 한 번의 프리필이 최대 68만 1천 토큰까지 가능하다는 뜻으로 읽힘. 그렇게 긴 세션에서는 캐시 미스를 피하려 애쓰고, 그만큼 큰 단독 요청도 드물어 해당 조건이 잘 발생하지 않을 듯함. 여러 차례 대화하는 일반적인 코딩 세션이라면 100만 토큰까지 도달할 수 있다고 봄.
사고가 나는 건 있을 수 있는 일이지만, 출시 전부터 불일치를 알고 있었다는 건 정상이 아님. 내가 잘못 이해한 것인가, 아니면 품질을 전혀 신경 쓰지 않게 됐다고 공개적으로 인정하는 것인가? 잘못됐다는 걸 알면서 왜 출시하는가?
제목을 “AI 모델 워커의 요청 간 KV 캐시 노출”로 바꾸는 것을 고려해 주면 좋겠음.
다른 제공업체들은 이런 일이 벌어지는지 모르거나 신경조차 쓰지 않을 수도 있음.
지난해 ChatGPT 음성 입력이 처리 후 완전히 다른 메시지로 바뀐 적이 여러 번 있음. 잘못 알아들은 수준이 아니라 아예 별개의 대화였고, 여기서 발생한 것과 같은 KV 캐시 문제라면 더 쉽게 설명됨.
다른 제공업체들은 KV 저장소를 더 잘 격리하고 있을 수도 있지 않을까?
ChatGPT의 상의 벗은 남자 건도 같은 종류의 문제인지 궁금함.
걱정되는 것은 유출된 프롬프트의 실제 내용임. 100만 토큰 문맥을 지원하는 모델인 만큼, 저장소 전체나 설정 파일을 .env 파일까지 포함해 붙여 넣는 경우가 있음. 현실적인 최악의 상황은 단순한 채팅 내용이 아니라 API 키 유출임.
글은 근본 원인을 잘 설명하지만, 자신의 프롬프트가 다른 사람의 응답에 섞여 들어간 고객에게 통지했는지는 밝히지 않음.
Cloudflare조차 제대로 배포하지 못한다는 걸 보면, 이론 연구자와 실무자 사이 어딘가에서 지식 전달이 심각하게 실패하고 있는 듯함.
Cloudflare는 원래 안정적인 소프트웨어 배포로 유명한 곳이 아니며, 특히 출시 초기 기능은 더 그러함.
“공유 LLM 추론 환경의 테넌트 간 KV 캐시 노출: 분석과 해결” 정도가 훨씬 나은 제목임. 다른 지적처럼 제목에 GLM-5.3을 넣을 필요는 없음. GLM-5.3 사용자라 처음에는 걱정할 일이 생긴 줄 알았지만, 읽어 보니 내게 해당하는 우려는 아니었음.
어젯밤 읽다가 “처리할 수 없는 프롬프트에는 오류가 날 것으로 예상했지만, 긴 문맥 테스트가 성공해 문제라고 보지 않았다”는 대목에서 당황함. 오류를 예상했는데 성공 응답이 왔다면, 그냥 넘어갈 게 아니라 조사해야 하는 것 아닌가?
실제 기기 테스트용 iOS 가상 머신이나 기기를 띄워 주던 유명 브라우저 테스트 서비스에서 발견한 버그가 떠오름. 기기의 클립보드를 복사했더니, 다른 사용자가 자기 가상 머신에 붙여 넣으려던 것으로 보이는 인증 정보가 가득했음. 기기끼리 클립보드 데이터가 유출되고 있었던 것임.
취약점을 신고하면서 버그 바운티가 있는지도 물어봤음. 일부러 취약점을 찾던 것은 아니지만 물어볼 만하다고 생각했음. 보상 프로그램은 없지만 기여에 감사하는 서명된 편지를 보내 줄 수 있다고 해서 좋다고 했는데, 이후 아무 연락도 받지 못함. 여러모로 실망스러웠음.