Cloudflare Workers AI의 GLM-5.3에서 발생한 요청 간 KV 캐시 노출

AI 요약

Cloudflare는 2026년 8월 27일부터 9월 9일까지 Workers AI의 GLM-5.3에서 다른 고객 요청의 내용이 응답에 섞이는 문제가 있었다고 공개했습니다. 연구자 Gadi Evron이 9월 8일 신고했고, Cloudflare는 다음 날 재현한 뒤 모델을 비공개로 전환해 설정과 추론 엔진을 수정했습니다. 확인된 영향은 155개 응답이며 모두 681,280토큰보다 긴 프롬프트에서 발생했습니다. 조사에서 의도적인 악용 증거는 찾지 못했다고 밝혔습니다.

발생 원인

Workers AI는 SGLang을 분리형 prefill/decode 구조로 운영합니다. Prefill GPU가 프롬프트를 처리해 KV 캐시를 만들고, 이를 RDMA와 Mooncake으로 decode GPU에 넘깁니다. GLM-5.3의 설정상 컨텍스트 길이는 1,048,576토큰이었지만 prefill GPU의 KV 캐시 풀은 681,280토큰만 수용했습니다. Cloudflare는 이 불일치를 출시 전에 알고 있었지만, 처리할 수 없는 프롬프트라면 엔진이 오류를 반환하리라 예상했습니다.

SGLang의 거부 처리 버그가 누출을 일으켰습니다. 풀을 초과한 요청은 내부적으로 거부 상태가 된 뒤 한 토큰짜리 대체 프롬프트로 바뀌었습니다. 단일 노드에서는 오류 응답으로 끝났지만, 분리형 구성에서는 prefill과 decode 대기열이 요청의 거부 여부가 아니라 완료 여부를 확인했습니다. 따라서 거부된 요청도 살아 있는 요청으로 처리됐습니다. Decode 노드는 프롬프트 길이에 맞춰 KV 페이지를 예약했지만 prefill은 대체 토큰에 해당하는 한 페이지만 기록했습니다. 나머지 페이지에는 이전 요청의 내용이 남아 있었고, decode가 그 페이지까지 읽으며 다른 고객의 데이터가 응답에 포함됐습니다. 클라이언트에는 HTTP 400이 아니라 HTTP 200이 반환됐습니다.

조치와 검증

Cloudflare는 모델을 내린 뒤 KV 풀을 약 204만 토큰으로 늘려 유효한 컨텍스트 길이보다 크게 맞췄습니다. 동시에 거부된 요청을 bootstrap, 메모리 할당, KV 전송 이전에 종료하도록 SGLang을 수정했습니다. Decode 노드가 예약한 토큰 수와 전송된 토큰 수도 비교하도록 제안했습니다. 연구자의 재현 스크립트와 자체 canary 표시 테스트로 변경 사항을 확인한 뒤 9월 9일 모델을 복구했습니다.

Cloudflare는 출시 전 테스트에서 긴 프롬프트의 HTTP 상태와 성능만 확인하고 출력의 내용과 일관성을 검증하지 않은 점을 테스트 공백으로 들었습니다. 이후 실행 중인 엔진에서 KV 풀과 컨텍스트 길이를 직접 비교하고, 새 배포 때마다 관련 설정과 패치를 확인하도록 절차를 바꿨습니다. 다른 Workers AI 모델은 KV 풀이 컨텍스트 길이보다 커 영향을 받지 않았다고 밝혔습니다.

SGLang 운영자를 위한 권고

Cloudflare는 분리형 prefill/decode를 운영하는 사업자에게 모든 노드의 KV 풀과 컨텍스트 길이를 비교하고, 설정 변경 후 다시 측정하라고 권고합니다. SGLang v0.5.22 이상으로 업그레이드하거나 관련 수정 사항을 backport해야 합니다. 양쪽 역할에서 deferred KV release를 켜고 Mooncake 전송 배치 크기를 제한하며, 지원되는 모델에서는 KV checksum과 canary를 활성화하라고 덧붙였습니다. 프록시가 첫 토큰 생성 전에 요청을 중단해 불필요한 abort를 만들지 않도록 구성하는 방안도 제시했습니다.

추가 방어와 SGLang 수정

사건 이후 Cloudflare는 전송 중단과 페이지 해제 사이의 경쟁 조건을 줄이기 위해 prefill 원본 페이지에도 지연 해제를 적용하고, 전송 실패 유형 전반으로 적용 범위를 넓혔습니다. 클라이언트 연결이 끊겨도 prefill이 끝나고 decode가 첫 토큰을 내놓을 때까지 연결을 유지하도록 로드밸런서를 바꿨습니다. SGLang에는 거부 요청 조기 종료, 전송 checksum, 지연 해제, abort 메시지와 요청 ID 처리, 전송 상태 관측 지표 등 수정이 반영됐습니다. Cloudflare는 운영자에게 v0.5.22 이상을 권고합니다.

장기 과제로는 KV 페이지마다 재할당 때 바뀌는 태그를 붙이고 decode가 캐시를 읽을 때 요청이 기대한 태그와 대조하는 방식을 제시했습니다. Cloudflare의 기존 시제품은 테스트에서 처리량과 tail latency 비용이 1% 미만이었지만, 특정 attention backend와 모델 구조에 묶여 신뢰성 문제로 비활성화했습니다. 범용 구현을 SGLang 팀과 개발하고 있으며, 전송 checksum은 그보다 제한적인 첫 단계라고 설명합니다. 또 Mooncake을 사용하는 분산 KV 전송 프로토콜을 형식 검증해 안전성 속성을 확인하는 작업도 시작한다고 밝혔습니다.

Hacker News 반응

• @thehamkercat — 다른 제공업체들은 이런 일이 벌어지는지도 모르거나 신경 쓰지 않을 것 같습니다.
  • @kolanos — 다른 제공업체들은 KV 저장소를 더 잘 격리했을 수도 있습니다.
  • @jmalicki — 저도 ChatGPT에서 이런 일을 겪었습니다.
  • @6thbit — 작년에 ChatGPT에서 음성으로 입력한 내용이 처리된 뒤 엉뚱한 별개의 대화로 바뀐 적이 한 번 이상 있었습니다. 잘못 알아들은 정도가 아니라 같은 종류의 KV 캐시 문제로 설명하는 편이 더 자연스러웠습니다.
  • @kami23 — 지난 1년 사이에 다른 사람의 답변을 받은 것 같은 일이 한 번 있었습니다. 이상해서 대화 기록을 되돌린 뒤 다시 요청하니 기대한 답이 나왔습니다. 당시 Anthropic이 새 모델을 출시하던 시기였고 API가 불안정해 보이곤 했습니다.
  • @Orygin — ChatGPT가 셔츠를 벗은 남자 사진을 만든 일도 같은 종류의 문제였는지 궁금합니다.
• @kami23 — 대부분의 RCA보다 훨씬 좋습니다. 문제를 책임지고 테스트에서 버그를 놓친 이유를 분명히 설명한 점이 마음에 듭니다. 모델 서비스를 내린 뒤 빠르게 대응한 것도 인상적입니다. 복구 속도 자체보다 플랫폼에서 서비스를 신속히 중단할 수 있다는 점이 더 중요하게 느껴집니다.
• @8cvor6j844qw_d6 — 흥미롭네요. 특정 제공업체 API에서 몇 번이나 완전히 엉뚱한 답을 받은 이유를 설명할 수도 있겠습니다.
• @0xbadcafebee — 공유 테넌트 공격 모델을 잊고 있었습니다. 공유 테넌트에서는 소프트웨어가 토큰을 마법처럼 격리해 줄 거라고 생각하거나 바랐던 것 같습니다. 실제로는 공유 캐시 같은 것만 봐도 공격 방식이 여럿이고 LLM 특유의 기능이나 버그를 따지기 전부터 그렇습니다. 매우 민감한 데이터를 다루는 기업이라면 공유되지 않는 호스트를 써야 합니다.
• @segmondy — "GLM 5.3을 1,048,576토큰 컨텍스트 창으로 배포했지만 prefill GPU의 KV 캐시 풀은 681,280토큰만 수용했습니다. 출시 전에 이 불일치를 알고 있었습니다." 실제로는 681,280토큰밖에 처리하지 못하면서 1,048,576토큰이라고 광고했나요?
  • @weird-eye-issue — 바로 다음 문장에 이렇게 나옵니다. "엔진이 처리할 수 없는 프롬프트에는 오류를 반환할 것으로 예상했고, 긴 컨텍스트 테스트에서 성공 응답을 받아 문제라고 생각하지 않았습니다."
  • @freakynit — 앞 문장과 연결해서 세 번이나 읽었는데도 무슨 말인지 모르겠습니다.
  • @Graziano_M — 긴 프롬프트를 넣고 실패 여부만 확인했다는 뜻 같습니다. 테스트는 같은 KV 캐시 누출을 보고도 성공으로 해석했을 수 있습니다.
  • @segmondy — 그래도 100만 토큰 창이라고 광고할 수는 있었겠죠. 사용자는 60만 토큰쯤 입력한 뒤 오류를 받았을 테고, 작업을 끝내지 못한 채 60만 토큰 비용만 냈을 겁니다.
  • @jacquesm — SGLang을 탓하는 말처럼 들리지만 SGLang만의 책임도 아닙니다. 최소한 테스트 중 누군가는 사용률이 40%나 어긋난 걸 알아챘어야 합니다. 더 나은 제목은 "Cloudflare 설정 오류로 사용자 세션 간 데이터가 유출됐다"였을 겁니다.
• @paaloeye — 이건 새로운 종류의 테넌트 격리 취약점인가요?
  • @dnautics — 아닌 것 같습니다. GPU 할당이 충돌한 오래된 문제입니다.
• @jacquesm — GLM-5.3과는 별 관련이 없습니다. 사용자를 나누어 모델을 공유하면서 메모리 관리를 제대로 하지 않으면 생기는 문제입니다. 사용자 세션 사이의 격리가 부족해 메모리가 겹치면 안 되는 상황에서 겹친다는 뜻입니다. Z.AI 모델의 버그라기보다 SGLang과 Cloudflare의 버그이며, Cloudflare가 책임져야 합니다.
  • @kflansburg — 모델 버그라고 주장한 적은 없습니다. Cloudflare 설정 오류와 SGLang 버그였다고 분명히 설명했습니다. 고객이 어떤 Workers AI 엔드포인트에 영향이 있었는지 알아야 하므로 제목에 모델을 적었습니다. "GLM-5.3"이 아니라 "GLM-5.3 Workers AI model"이라고 썼습니다.
  • @jacquesm — 동의할 수 없습니다. 제목에 모델 이름을 넣으면 꼼꼼히 읽지 않는 사람에게 GLM-5.3에 특화한 문제처럼 보입니다. SGLang이 오류를 내지 않았다고 언급하면서 놀라는 모양새지만 문제는 처음부터 Cloudflare 책임이었습니다.
  • @margalabargala — 제목은 GLM 버그라는 인상을 줍니다. "Cloudflare 버그"라는 점을 흐리는 불필요한 정보가 너무 많습니다.
  • @literallyroy — 제목이 수정된 건지는 모르겠지만 지금 제목은 Cloudflare 쪽 문제라는 점이 명확합니다. Cloudflare를 통해 모델을 쓰는 기술적으로 숙련된 사람이 캐시를 언급한 제목을 오해할 이유가 없습니다.
• @totetsu — 단일 테넌트 추론을 서비스로 제공하는 곳이 있기는 한가요?
• @reassess_blind — 널리 쓰이는 브라우저 테스트 서비스의 취약점이 생각납니다. iOS 가상 기기를 띄우는 서비스였는데, 기기의 클립보드를 복사하니 다른 사용자가 자기 가상 기기에 붙여넣으려던 자격 증명이 들어 있었습니다. 기기들이 서로 클립보드를 공유하고 있었습니다. 취약점을 신고하고 포상 프로그램이 있는지 물었지만 없다고 했습니다. 대신 기여에 감사한다는 서명된 편지를 보내겠다고 했습니다. 좋다고 했지만 결국 아무 소식도 듣지 못했습니다. 실망스러운 일이었습니다.

원문: Cloudflare Blog / 번역·요약: Trawling