Cloudflare는 Cloudflare Containers와 Cloudflare Sandboxes에서 발생한 테넌트 간 취약점을 수정했다. Accomplish 팀의 연구원들은 Workers Paid 계정을 보유한 사용자가 동일한 호스트에서 다른 고객의 컨테이너가 이전에 사용했던 스토리지 블록의 잔여 일부를 복구할 수 있음을 입증했다. 연구원 Oren Yomtov는 2026년 9월 4일 버그 바운티 프로그램을 통해 회사에 문제를 알렸으며, Cloudflare는 고객 데이터가 침해되었다는 증거를 발견하지 못했다고 밝혔다.
문제는 어떻게 발생했나?
Containers는 Linux device mapper thin provisioning 기술을 사용해 Firecracker를 통해 실행되는 가상 머신 내부에 쓰기 가능한 루트 디스크를 제공한다. 영향을 받은 스토리지 풀은 64킬로바이트 크기의 블록을 사용했고 skip_block_zeroing 옵션이 활성화되어 있었다. 이에 따라 재할당된 블록은 새 컨테이너에 제공되기 전에 0으로 초기화되지 않았다.
새 블록의 일부에 4킬로바이트만 기록할 경우, 남은 60킬로바이트 부분에는 이전 소유자의 데이터가 남아 있을 수 있었다. 이후 원시 장치 /dev/vdc에서 읽으면 새 컨테이너가 한 번도 기록하지 않은 바이트가 노출될 수 있었다.
테스트에서 무엇이 입증되었나?
이 공격으로 특정 고객이나 컨테이너 또는 호스트를 선택할 수 있었던 것은 아니며, 데이터 잔여물이 반드시 나타나는 것도 아니었다. 그러나 연구원들은 테스트한 24개 위치 중 18곳에서, 그리고 4개 대륙에 걸친 22개 기본 노드 중 20곳에서 잔여 자료를 관찰했다고 밝혔다. 관찰된 유형에는 디렉터리 구조, 데이터베이스 페이지, 구조적으로 완전한 SQLite 데이터베이스가 포함됐다.
연구원들은 해시 테스트와 ext4 파일 시스템 메타데이터를 사용해 실험 시스템의 블록과 다른 파일 시스템에서 온 블록을 구별했다. 공개된 결과에 따르면 외부 디렉터리 노드 2,700개가 식별되었으며, 테스트 디렉터리 블록 5,614개 중 어느 것도 연구원들의 시스템에 속하는 것으로 분류되지 않았다. Cloudflare는 제출된 자료에 파일 이름, 식별자, 자격 증명 또는 복구된 콘텐츠가 포함되지 않았으며, 연구원들이 보유한 데이터를 안전하게 삭제했다고 밝혔다.
Cloudflare는 결함을 어떻게 해결했나?
회사는 dm-thin 풀 설정에서 skip_block_zeroing 옵션을 제거했고, 이에 따라 새 블록은 제공되기 전에 0으로 초기화되는 기본 동작으로 돌아갔다. 연구원들은 이 변경 이후 개념 증명이 더 이상 작동하지 않는다는 사실을 독립적으로 확인했다.
그러나 새 할당을 0으로 초기화하는 것만으로는 충분하지 않았다. 일부 블록이 여전히 실행 중인 컨테이너 디스크나 OCI 이미지 레이어의 임시 스냅샷에 연결되어 있었기 때문이다. 따라서 Cloudflare는 오래된 컨테이너 디스크를 중지하고, 수정 전에 캐시된 스냅샷을 제거했으며, 호스트를 비우고 가상 머신을 재시작한 뒤 이미지 캐시를 정리했다. 이 정리 작업은 2026년 9월 19일 완료되었고, 기본 수정 사항의 배포는 9월 7일 완료되었다.
이 소식이 중요한 이유는?
이번 사건이 중요한 이유는 클라우드 인프라에서 테넌트 격리가 가상 머신에만 의존하지 않는다는 점을 보여주기 때문이다. 스토리지 재사용의 세부 사항과 씬 프로비저닝의 동작이 비활성 데이터 유출 경로를 열 수 있다. 반면 실질적인 제약도 분명했다. 테스트는 특정 피해자를 겨냥하거나 실제로 연결된 디스크에 접근할 수 없었으며, 다른 고객의 데이터를 수정하거나 해당 고객의 워크로드 가용성에 영향을 미쳤다는 사실도 입증하지 못했다.
Cloudflare는 4킬로바이트 쓰기와 더 큰 읽기를 결합하는 특징적인 패턴을 찾기 위해 과거 디스크 입출력 측정 기록을 검토했다. 회사는 이 패턴과 일치하는 활동을 연구원들과 승인된 검증 과정에 참여한 자사 엔지니어들의 활동으로 분류했으며, 다른 주체가 공격을 악용했음을 보여주는 추가 활동은 발견하지 못했다. 회사에 따르면 Cloudflare 고객이 취해야 할 조치는 없다.