Cloudflare Workers AI에서의 교차 요청 KV 캐시 노출: GLM-5.3, SGLang 및 v0.5.22에서의 수정 사항
2026년 8월 27일부터 9월 9일 사이에 GLM-5.3 Workers AI 모델(@cf/zai-org/glm-5.3)을 사용하는 소수의 고객이 동일한 모델에 대한 다른 고객의 요청 데이터가 포함된 응답을 받았습니다. 원인은 두 가지 중첩된 문제였습니다. 모델의 광고된 1,048,576 토큰 컨텍스트 윈도우와 681,280 토큰만 보유할 수 있는 프리필(prefill) KV 캐시 풀 간의 Cloudflare 구성 불일치, 그리고 분리된 프리필-디코드(prefill-to-decode) 핸드오프 과정에서 허용 범위를 초과한 요청이 거부되지 않고 통과되도록 허용한 SGLang 버그가 그것입니다. 총 155개의 응답이 영향을 받았으며, 모두 681,280 토큰보다 긴 프롬프트에 대한 것이었습니다. Cloudflare는 이 문제를 해결하고 2026년 9월 9일에 모델을 복구했으며, Workers AI에서 호스팅되는 다른 모델은 영향을 받지 않았음을 확인했습니다.
무슨 일이 일어났는가
Cloudflare는 2026년 9월 8일, Knostic의 보안 연구원 Gadi Evron으로부터 Cloudflare의 HackerOne 프로그램을 통해 Workers AI의 @cf/zai-org/glm-5.3으로 전송된 매우 긴 프롬프트가 때때로 다른 사용자의 세션에 속한 텍스트를 반환한다는 보고를 받았습니다. Cloudflare는 다음 날 아침 문제를 재현하고 보안 사고를 선언했으며, 선언 후 40분 이내에 해당 모델을 오프라인으로 전환했습니다. 이후 회사는 수정된 구성과 패치된 추론 엔진을 배포하고 같은 날 서비스를 복구했습니다.
Cloudflare는 자체 테스트와 연구원의 테스트를 제외하면, 영향을 받은 요청들이 반복적인 악용보다는 일반적인 긴 컨텍스트 사용과 타이밍 및 볼륨 면에서 일치하며, 고의적인 악용의 증거는 발견되지 않았다고 밝혔습니다.
GLM은 에이전트 코딩 워크플로우를 위해 Z.ai에서 구축한 텍스트 생성 모델이며, Workers AI를 통해 사용할 수 있는 모델 중 하나입니다. 이 노출은 2026년 8월 27일 Workers AI에서 모델이 출시된 시점부터 존재했습니다.
첫 번째 문제: 컨텍스트 윈도우보다 작았던 KV 풀
Cloudflare는 1,048,576 토큰 컨텍스트 윈도우로 GLM 5.3을 배포했지만, 프리필 GPU의 KV 캐시 풀은 681,280 토큰만 수용할 수 있었습니다. Cloudflare는 출시 전 이 불일치를 인지하고 있었습니다.
SGLang은 시작 시 모델 가중치를 로드한 후 남은 GPU 메모리에서 KV 캐시 풀 크기를 조정합니다. 풀 크기는 구성 값이 아니며, 모델의 광고된 컨텍스트 길이는 별도의 구성 값입니다. 이 둘을 강제로 일치시키는 기능은 없으며, Cloudflare의 게시물에 따르면 해당 일치를 확인하는 것은 운영자의 책임입니다. 선택된 KV 풀 크기는 SGLang 시작 로그에 출력되고 메트릭으로 노출됩니다.
Cloudflare의 출시 전 테스트에서는 벤치마킹 중에 성공적인 HTTP 상태 코드와 오류 프레임이 없는 스트리밍 본문이 관찰되었으므로, 회사는 엔진이 KV 캐시 풀과 요청된 컨텍스트 윈도우 간의 차이를 원활하게 처리하고 있다고 가정했습니다. 게시물은 이를 중요한 테스트 공백으로 식별합니다. Cloudflare는 긴 컨텍스트에서 HTTP 응답 코드와 엔진 성능은 검증했지만, 모델 출력과 일관성은 검증하지 않았습니다.
두 번째 문제: 분리 모드에서의 SGLang 거부 경로
분리된 프리필/디코드 모드에서 KV 풀이 수용할 수 있는 것보다 긴 프롬프트는 내부적으로 거부된 것으로 표시되고 1토큰 자리 표시자로 대체되었지만, 요청 자체가 중단되지는 않았습니다. 대신 프리필은 자리 표시자 프롬프트에 대한 KV 캐시를 생성하여 디코드 노드로 전송했습니다. 디코드 노드는 "전송 완료" 메시지를 수신하고 프리필이 이전 요청의 KV 캐시를 이 요청의 전체 프롬프트로 덮어썼다고 가정했지만, 실제로는 이전 상태의 대부분이 그대로 남아 있었습니다. 디코드는 이전 요청의 데이터가 여전히 남아 있는 오래된 캐시 페이지를 참조하면서 응답을 생성했습니다.
단일 노드 배포에서는 거부 경로가 올바르게 작동했습니다. 자리 표시자가 실행되고 배치가 완료되었으며 클라이언트는 오류를 수신했습니다. 분리 모드에서는 프리필과 디코드 모두의 승인 큐가 요청이 거부되었는지 여부가 아니라 완료되었는지 여부를 확인했습니다. 거부된 요청은 finished_reason이 아닌 to_finish에 거부 상태를 저장했으므로 finished()는 여전히 False를 반환했고 요청은 스스로를 활성 상태로 보고했습니다.
Cloudflare가 설명하는 시퀀스는 다음과 같습니다:
- 부트스트랩. 라우터는 디코드 노드에 프롬프트 길이(Cloudflare 다이어그램에서 8페이지)를 알렸고, 디코드는 8개의 KV 페이지를 예약했습니다.
- 프리필 승인. 프리필 승인 큐는
req.finished()가 False인 모든 요청을 승인했으므로 거부된 요청이 승인되었습니다. - 프리필 순방향 패스. 거부로 인해 프롬프트가 이미 1토큰 자리 표시자로 대체되었으므로 프리필은 해당 1토큰에 대해 사소한 순방향 패스를 실행했습니다.
- KV 전송. 프리필은 1페이지의 KV를 디코드로 보내고 전송이 완료되었음을 알렸습니다.
- 디코드 승인. 디코드의 승인 큐는 동일한
finished()확인을 사용했고 핸드오프를 수락했습니다. - 디코드 어텐션. 디코드는 생성을 시작했고 어텐션은 예약된 8페이지를 모두 읽었습니다. 이 요청에 의해 작성된 페이지는 P0뿐이었으며, P1에서 P7 페이지에는 이전 요청이 남긴 데이터가 그대로 남아 있었습니다.
- 응답. 클라이언트는 HTTP 400 대신 HTTP 200을 수신했습니다.
prompt_tokens는 긴 프롬프트와 일치했고 답변은 일관성이 있었지만, 8페이지 프리필이 걸리는 시간보다 빠르게 도착했으며 다른 사용자의 KV 페이지에서 가져온 콘텐츠가 포함되어 있었습니다.
임계값을 초과하는 모든 요청이 이런 방식으로 동작했습니다. 이 버그는 2026년 7월 6일 다른 사용자에 의해 이슈 #30233으로 SGLang에 보고되었으며, Cloudflare는 이 사건을 조사하는 과정에서 이를 발견했습니다. Cloudflare는 v0.5.10부터 SGLang에 이러한 유형의 문제를 제기해 왔다고 밝혔습니다.
GLM 5.3만이 영향을 받은 유일한 모델이었습니다. Workers AI의 다른 모든 분리 배포는 프리필과 디코드 모두에서 컨텍스트 길이보다 큰 KV 풀을 가지고 있었기 때문에 어떤 요청도 거부 경로에 도달할 수 없었습니다.
수정: 구성 수정 및 엔진 수정
Cloudflare는 공개 액세스를 복구하기 전에 두 가지 독립적인 수정을 적용했습니다.
풀이 전체 컨텍스트를 수용하도록 설정. Cloudflare는 GLM 5.3 구성을 GLM 5.2 구성과 일치하도록 조정하여 충분한 GPU 메모리를 확보했으며, 이제 프리필 KV 풀은 1,048,576 토큰 컨텍스트 길이의 약 2배인 약 204만 토큰을 수용합니다. 이제 컨텍스트 윈도우에 맞는 프롬프트는 항상 풀에 맞으므로 유효한 요청에 대해 거부 경로에 도달하지 않습니다.
거부 경로를 안전하게 만들기. Cloudflare는 풀 크기에만 의존하는 것은 취약하다고 주장합니다. 양자화, 텐서 병렬 처리, CUDA 그래프 크기 변경 또는 향후 모델 버전 변경으로 인해 풀 크기가 쉽게 변할 수 있고, 다른 상황에서도 프리필 스케줄러가 요청을 거부하고 동일한 버그를 트리거할 수 있기 때문입니다. Cloudflare는 엔진을 패치하여 보류 중인 거부를 포함하는 요청이 부트스트랩, 할당 또는 KV 전송이 발생하기 전에 원래 오류와 함께 분리 승인 큐에서 즉시 종료되도록 했습니다. 이는 업스트림에 #38704로 제안되었으며, 디코드 노드가 전송된 토큰 수가 예약한 수와 일치하는지 확인하는 기능도 포함되었습니다.
Cloudflare는 모델을 복구하기 전에 연구원의 재현 스크립트와 자체 카나리 마커 테스트를 통해 두 가지 변경 사항을 모두 검증했습니다.
사건 타임라인
모든 시간은 Cloudflare가 게시한 대로 UTC 기준입니다.
| 시점 | 내용 |
|---|---|
| 2026년 8월 27일 | GLM 5.3이 컨텍스트 윈도우보다 작은 프리필 KV 풀로 Workers AI에 출시됨. 출시 시점부터 노출 존재. |
| 2026년 9월 8일 – 23:11 | HackerOne을 통해 보고서 접수. |
| 2026년 9월 9일 – 08:00 | Cloudflare가 HackerOne 보고서 검증 시작. |
| 2026년 9월 9일 – 13:22 | 보안 사고 선언. 제품 보안팀이 25분 이내에 두 개의 독립적인 계정을 사용하여 유출 재현. |
| 2026년 9월 9일 – 14:00 | GLM 5.3을 비공개로 설정. 요청 시 HTTP 400 반환. 상태 페이지 업데이트. |
| 2026년 9월 9일 – 14:35 | 근본 원인이 컨텍스트 길이보다 작은 프리필 풀임을 식별. 더 큰 풀을 가진 카나리 프리필 노드는 영향받지 않음을 확인. |
| 2026년 9월 9일 – 14:52 | 모든 프리필 노드를 수정된 구성으로 롤아웃. |
| 2026년 9월 9일 – 19:04 | 수정된 구성과 Cloudflare가 작성한 엔진 패치를 포함하여 전체 배포 재구축. 연구원의 재현 스크립트로 검증. |
| 2026년 9월 9일 – 19:40 | 모델을 공개로 복구. |
| 2026년 9월 10일 – 23:30 | SGLang 유지 관리자(RadixArk CTO 및 핵심 엔지니어)와 업스트림 수정 사항에 합의하기 위한 회의. |
| 2026년 9월 11–19일 | 모든 프로덕션 SGLang 배포에 추가 강화 조치 롤아웃. |
| 2026년 9월 16–10월 12일 | 업스트림 SGLang이 승인 수정, 전송별 체크섬, 중단-ACK 보존을 병합하고 지연된 KV 해제를 기본값으로 설정. |
| 2026년 10월 2일 | SGLang v0.5.21 출시. |
| 2026년 10월 19일 | SGLang v0.5.22 출시. |
| 2026년 10월 26일 | 연구원 및 RadixArk와 조정된 게시. |
업스트림 SGLang 수정 사항
이 문제에 대한 패치는 SGLang v0.5.20에서 릴리스되었으며 v0.5.21 및 v0.5.22에서 후속 조치가 이루어졌습니다. Cloudflare는 모든 운영자가 SGLang 종속성을 v0.5.22 이상으로 업데이트할 것을 권장합니다. 다음 변경 사항이 SGLang main에 적용되었으며, 하나를 제외하고 모두 v0.5.22에 포함되어 있습니다.
| 카테고리 | 풀 리퀘스트 | 릴리스 | 내용 |
|---|---|---|---|
| 사고 | #36988 | v0.5.20 | 결과가 디코드에 도달하기 전에 중단된 프리필 요청을 종료. 이 사건의 노출을 중단시킴. |
| 사고 | #38935 | v0.5.21 | 부트스트랩, 할당 또는 KV 전송 전에 승인 단계에서 이러한 요청을 거부. Cloudflare의 초안 패치 #38704의 접근 방식을 따름. |
| 레이스 | #39461, #41612 | v0.5.21, v0.5.22 | sgl-router가 클라이언트 연결 해제 또는 프리필 실패 시 요청의 양쪽 절반을 모두 취소. |
| 레이스 | #37454, #41023 | v0.5.20, v0.5.21 | 이를 지원하는 백엔드에서만 지연된 KV 해제를 활성화한 다음 기본값으로 설정. |
| 레이스 | #40645, #41402 | v0.5.21 | 드레인 확인이 손실된 경우를 수정하여 타임아웃을 기다리는 대신 확인 시 해제가 발생하도록 함. |
| 레이스 | #41404 | v0.5.21 | 디코드 시작 중단뿐만 아니라 모든 전송 실패 시 페이지를 보류. |
| 레이스 | #41618 | v0.5.21 | 중단 알림 경로의 회귀를 수정. |
| 레이스 | #43719 | v0.5.22 | 실패한 Mooncake 전송은 더 이상 쓰기를 드레인된 것으로 보고하지 않음. |
| 레이스 | #37077 | v0.5.22 | 재사용된 ID가 오래된 확인을 소비하지 않도록 요청별로 중단 메시지에 태그 지정. MORI 지원 추가. |
| 레이스 | #36612 | v0.5.20 | Mooncake, NIXL 및 MORI 전반에 걸쳐 프리필-디코드 실패 알림을 공유. |
| 레이스 | #32758 | v0.5.20 | Mooncake 전송 배치 크기에 대한 선택적 제한을 두어 타임아웃된 호출 하나가 무제한의 쓰기를 비행 상태로 남기지 않도록 함. |
| 수명 | #30899 | v0.5.21 | 디코드는 요청을 철회하고 페이지를 해제하기 전에 호스트 메모리로의 진행 중인 오프로드를 기다림. Cloudflare 작성. |
| 수명 | #43562 | v0.5.22 | 호스트 메모리 캐시 복원이 실패할 때 텐서 병렬 순위가 일치하도록 유지. |
| 관측 가능성 | #39500 | v0.5.21 | --disaggregation-enable-kv-checksum 추가: 디코드는 생성 전에 전송된 KV의 체크섬을 확인. #39729에서 정리, 병합되어 릴리스 대기 중. |
| 관측 가능성 | #38596, #40642 | v0.5.20, v0.5.21 | 잠재적 손상을 감지하고 기록하는 SGLang의 KV 카나리에 대한 수정. |
| 관측 가능성 | #41128 | v0.5.22 | 지연된 해제에 대한 메트릭: 횟수, 지속 시간, 각 보류가 드레인 확인 또는 타임아웃으로 종료되었는지 여부. |
게시 시점에 여전히 진행 중인 작업: #39729(--disaggregation-enable-kv-checksum에 대한 정리, 병합되어 릴리스 대기 중), 해제 시 KV 페이지 0으로 초기화(초안 제안 #46435), 프리필-디코드 핸드오프에서 모든 디코드 단계로 KV 체크섬 검증 확장, 더 광범위한 KV 카나리 및 KV 체크섬 모델과 기능 지원.
Cloudflare가 배포한 추가 강화 조치
Cloudflare는 이 버그를 수개월 동안 작업해 온 KV 캐시 메모리 안전 버그 제품군 중 하나로 분류합니다. 각 경우에 페이지가 해제, 재사용 또는 읽히는 동안 다른 무언가가 여전히 해당 페이지에 대한 권한을 가지고 있습니다. Cloudflare는 두 가지 공통 원인을 식별합니다.
첫 번째는 단일 노드 내의 페이지 수명입니다. 디코드 노드의 여러 작업이 토큰 생성, 호스트 메모리로의 오프로드, KV 전송 수신기, 중단 및 오류 경로와 같이 동일한 페이지를 동시에 보유할 수 있습니다. 하나가 페이지를 해제하는 동안 다른 하나가 여전히 사용 중이면, 읽거나 쓰는 동안 새 요청에 해당 페이지가 할당될 수 있습니다. 디코드 오프로드(#24226, #30899) 및 문법 오류 시 이중 해제(#30937)에 대한 이전 수정 사항이 이러한 유형이었습니다.
두 번째는 노드 간의 레이스입니다. 요청이 중단되는 동안 프리필이 RDMA를 통해 디코드로 KV 캐시를 계속 쓰는 경우, 이미 전송된 쓰기는 취소할 수 없습니다. 디코드가 해당 페이지를 즉시 해제하면 해당 페이지가 다른 요청에 할당될 수 있으며, 늦은 쓰기가 해당 요청의 KV 캐시에 기록됩니다. Cloudflare는 이 레이스에 대한 제안된 수정 사항(#31357, #38961)과 재현 스크립트(#32564)를 기여했습니다. Cloudflare는 이 사건의 버그가 달랐다고 언급합니다. 거부된 요청은 타이밍 사고가 아니라 매번 핸드오프를 통과했지만, 디코드가 요청이 작성하지 않은 페이지를 읽는다는 동일한 결과를 낳았습니다.
사건 이후 Cloudflare는 다음을 수행했습니다:
- 지연된 해제를 프리필의 소스 페이지까지 확장하고, 중단뿐만 아니라 모든 실패 유형을 포괄하도록 했습니다. 업스트림에 #38961로 제안되었으며 #40645, #41402, #41404로 대체되었습니다.
- 제한된 Mooncake 전송 배치(#32758, SGLang 커뮤니티에서 제공)를 배포하여 단일 전송 호출이 해제 타임아웃보다 오래 지속되지 않도록 했습니다.
- 로드 밸런서를 변경하여 클라이언트 연결 해제가 전송 중간에 요청을 중단하지 않도록 했습니다. 프리필이 완료될 때까지 프리필 연결을 유지하고 첫 번째 토큰까지 디코드 연결을 유지한 다음 둘 다 닫습니다.
- 모든 분리 배포 변경 사항에 확인 절차를 추가했습니다: 컨텍스트 길이에 대비하여 측정된 KV 풀 크기, 양쪽 역할에서의 지연된 해제, 해제 타임아웃 내의 전송 배치 경계, 그리고 모든 필수 패치 적용.
Cloudflare가 다른 SGLang 운영자에게 권장하는 사항
분리된 프리필/디코드 모드에서 SGLang을 실행하는 모든 사람을 위한 Cloudflare의 지침은 다음과 같습니다:
- KV 풀을 측정하고 컨텍스트 길이와 비교하십시오. 모든 프리필 및 디코드 노드에서, 엔진의 시작 로그로부터, 가중치, 양자화, 병렬 처리 또는 메모리 비율 변경 후마다 수행하십시오. 풀이 더 작으면 컨텍스트 길이를 낮추어 맞추십시오. 프록시가 제한을 강제하도록 의존하지 말고, 엔진이 맞지 않는 것을 거부할 것이라고 가정하지 마십시오.
- #36988 및 #38935(v0.5.22 이상)가 포함된 빌드로 업그레이드하십시오. 그러면 풀 크기에 관계없이 핸드오프 전에 허용 범위를 초과한 요청이 거부됩니다.
- 양쪽 역할에서 지연된 KV 해제로 실행하십시오. (#41023 이후 기본값) 그리고 Mooncake 전송 배치를 제한하여 타임아웃된 호출 하나가 무제한의 쓰기 꼬리를 남기지 않도록 하십시오.
- 모델이 지원하는 경우 손상 감지를 켜십시오.
--disaggregation-enable-kv-checksum및--kv-canary는 아직 모든 모델 아키텍처를 포괄하지 않습니다. 로그를 확인하여 요청이 검증되고 있는지 확인하십시오. Cloudflare는 SGLang 팀과 협력하여 GLM 5.3, GLM 5.3 Flash 및 DeepSeek V4를 포함한 더 많은 아키텍처로 두 검사를 확장하고 있습니다. - 프록시가 불필요한 중단을 생성하지 않는지 확인하십시오. 로드 밸런서를 구성하여 요청이 첫 번째 토큰까지 진행되도록 허용함으로써 노드 간 조정이 필요한 중단을 트리거하지 않도록 하십시오.
장기적 관점: 구성에 의한 무결성 및 형식 검증
Cloudflare는 구성 확인 및 수명 주기 수정이 페이지가 오용될 수 있는 방법의 수를 줄이지만 오용을 불가능하게 만들지는 않는다고 주장합니다. Cloudflare의 프레임워크에서 지속 가능한 답변은 엔진이 읽기 시점에 요청이 소유하지 않은 페이지를 참조하려고 한다는 것을 감지하고, 다른 사람의 데이터를 반환하는 대신 해당 요청 하나를 실패시키는 것입니다.
Cloudflare는 여름 동안 이에 대한 프로토타입을 구축하고 2026년 8월에 설명했습니다. 모든 물리적 KV 페이지는 페이지가 재할당될 때 변경되는 태그를 가지고 있으며, 각 요청은 예상하는 태그를 기록하고, 디코드가 캐시를 읽기 전에 매핑이 확인됩니다. Cloudflare의 테스트에서 처리량과 테일 레이턴시에서 1% 미만의 비용이 발생했습니다. Cloudflare는 8월 중순에 GLM 5.2에서 테스트했지만 신뢰성 문제로 인해 얼마 후 비활성화했습니다. 프로토타입은 특정 어텐션 백엔드 및 모델 아키텍처에 묶여 있어 일반적인 수정이 될 수 없었습니다. Cloudflare는 SGLang 팀과 협력하여 모든 모델에서 작동하는 프로덕션 버전을 엔진에 구축하고 있다고 말합니다. #39500의 전송별 체크섬은 프리필에서 디코드로의 핸드오프를 검증하기 때문에 첫 번째 단계이며, 페이지 수준 태그는 전송 후 한참 뒤의 읽기를 포함하여 모든 읽기를 확인하기 때문에 더 나아갑니다.
Cloudflare는 또한 이 버그를 분산 시스템의 일관성 실패로 프레임화합니다. RDMA는 한 노드의 메모리에서 다른 노드로 데이터를 직접 복사하며, 두 기계는 데이터가 어디로 가는지, 크기가 얼마인지, 언제 완료되는지에 대해 동의해야 합니다. Cloudflare는 기존의 형식 검증 작업(권위 있는 DNS에서 충돌 없는 IP 선택을 위한 Topaz, 일관성 버그가 나중에 수정되었음을 입증한 Meerkat의 QuePaxa 구현 모델)을 지적하며, 이제 그 경험을 KV 캐시 전송 엔진에 집중하고 있다고 말합니다. 명시된 계획은 RDMA 기반 KV 캐시 전송 프로토콜의 안전성을 모델링하고 증명하며, Mooncake를 사용하여 프로덕션 SGLang 분산 KV 캐시 시스템을 모델링하고, 보장하고자 하는 안전 속성으로부터의 모든 발산을 추적하고 수정하는 것입니다.
Hacker News 토론에서 추가된 내용
Hacker News 스레드에서 가장 많이 반복된 비판은 제목이 버그를 모델 탓으로 너무 많이 돌린다는 것이었습니다. 댓글 작성자 jacquesm은 다음과 같이 썼습니다:
이것은 GLM-5.3과 아무런 관련이 없습니다. 이것은 사용자와 모델을 공유하고 장부를 제대로 관리하지 않을 때 발생하는 일이며, 실제 모델은 중요하지 않습니다. 이것이 보여주는 것은 사용자 세션 간에 충분한 격리가 없으며 절대 불가능해야 할 때 메모리가 겹칠 수 있다는 것입니다. 이것은 Z.AI 모델 버그이기 훨씬 전의 SGLANG 및 Cloudflare 버그이며, 그들이 무엇을 할 수 있었을지 모르겠습니다. Cloudflare는 제목에 다른(내 생각에는 무고한) 당사자를 지명하는 대신 책임을 져야 합니다.
armcat은 "공유 LLM 추론에서의 교차 테넌트 KV 캐시 노출: 분석 및 수정"이라는 대안적인 프레임을 제안하며, GLM-5.3 사용자로서 처음에는 걱정할 이유가 있다고 생각했지만 "그렇지 않다는 것을 알게 되었다"고 덧붙였습니다. sauravadhk와 adg001도 제목에서 모델 이름을 삭제하라는 유사한 제안을 했습니다.
여러 댓글 작성자는 Cloudflare가 스스로 공개한 테스트 공백에 집중했습니다. ComputerGuru는 다음과 같이 썼습니다:
"오류를 예상했지만 성공적인 응답을 받았다"는 것은 그냥 넘어가는 것이 아니라 조사할 가치가 있지 않나요?
segmondy는 Cloudflare가 681,280 토큰만 수용할 수 있는 공간을 가지면서 1,048,576 토큰 컨텍스트 윈도우를 광고했는지 여부에 대한 관련 질문을 제기했습니다.
다른 사람들은 공개 자체를 칭찬했습니다. kami23은 책임감과 버그를 테스트가 잡아내지 못한 이유에 대한 명확한 설명, 그리고 Cloudflare가 모델 제공을 비활성화한 속도를 언급하며 "대부분보다 훨씬 더" 근본 원인 분석이 마음에 들었다고 썼습니다.
스레드는 또한 문제를 이 사건 너머로 일반화했습니다. 0xbadcafebee는 공유 테넌트가 토큰을 마법처럼 격리할 수 없음을 의미하며 "민감한 데이터가 많은 기업은 비공유 호스트를 사용해야 한다"고 언급했습니다. totetsu는 서비스를 위한 단일 테넌트 추론을 제공하는 곳이 있는지 물었습니다. nitishr은 "더 많은 서버리스 제공업체가 아직 유사한 문제를 발견(또는 공개)하지 않은 것에 놀랐다"고 썼고, thehamkercat은 다른 제공업체는 "이런 일이 일어나고 있다는 사실조차 모르거나 신경 쓰지 않을 것"이라고 제안했습니다.
두 명의 댓글 작성자는 다른 곳에서 유사한 교차 테넌트 유출이라고 믿는 것을 설명했습니다. xmcqdpt2는 직장에서 Claude 응답이 "회사 내 다른 사람에게서 왔을 가능성이 매우 높은 매우 구체적이고 관련 없는 정보를 반환했다"고 이야기했으며, Anthropic은 그것이 불가능하며 AI는 때때로 실수를 한다고 말했다고 했습니다. reassess_blind는 브라우저 테스트 서비스의 iOS VM이 다른 사용자의 자격 증명을 포함하여 사용자 간에 클립보드 데이터를 유출한다는 사실을 발견했다고 설명했으며, 공급업체가 현상금을 거부했다고 말했습니다. 이것들은 Cloudflare 보고서의 결과가 아니라 댓글 작성자의 검증되지 않은 일화입니다.
한 댓글 작성자인 octoberfranklin은 이 사건을 "sglang이 Rust로 작성되었음에도 불구하고 초기화되지 않은 메모리로 인한 정의되지 않은 동작으로 인해 피해를 입은 경우"로 특징지었습니다. Cloudflare의 자체 보고서는 근본 원인을 다르게 설명합니다. 승인 큐가 거부 상태가 아닌 finished()를 확인했기 때문에 거부된 요청이 승인되었고, 따라서 디코드는 덮어쓰여지지 않은 오래된 KV 페이지를 참조했습니다.
조정된 공개
Cloudflare는 SGLang 팀의 게시물과 함께 조정된 공개의 일환으로 보고서를 게시했습니다. Cloudflare는 재현 가능한 스크립트와 함께 HackerOne 프로그램을 통해 문제를 보고한 Gadi Evron과, 이 사건을 자신의 문제로 취급하고 긴급하게 업스트림 수정을 적용한 RadixArk의 SGLang 팀에 감사를 표했습니다. Workers AI의 보안 문제는 hackerone.com/cloudflare에서 보고할 수 있습니다.