Cloudflare Sandbox 보안 업데이트, 패키지만 바꾸면 끝일까요?

Cloudflare Sandbox를 운영한다면 SDK 버전뿐 아니라 실제로 실행 중인 컨테이너 이미지까지 확인해야 합니다. Cloudflare는 10월 22일 eMudhra 인증서 문제에 대응한 Sandbox SDK 0.12.14 업데이트를 안내했습니다. 0.x에서는 SDK와 이미지를 함께 바꿔 재배포하고, 1.x에서는 사용하는 이미지를 새로 빌드한 뒤 기존 실행 환경을 교체해야 합니다. Cloudflare 공식 변경 기록

Cloudflare Docs / Cloudflare 및 문서 기여자, 2026년 10월 23일 실제 공지 화면 캡처. 내용은 수정하지 않았습니다. 원문 · CC BY 4.0 및 보증 부인 조건. 실제 제품 관리 화면이 아닌 공식 문서입니다.

같은 HTTPS라도 확인하는 주체가 다릅니다

이번 문제는 웹사이트를 신뢰할 수 있는지 확인하는 인증서와 관련돼 있습니다. Cloudflare는 eMudhra의 중간 인증서 8개에 연결된 개인 키가 취약해, 이를 이용한 위조 인증서로 서버를 사칭할 수 있다고 설명했습니다. 이번 안내의 초점은 통신 상대의 인증서를 신뢰하는 기준입니다.

또한 Cloudflare는 조사에서 자사 서비스의 실제 악용을 확인하지 못했다고 밝혔습니다. 특정 독자의 시스템이 침해됐다고 단정할 근거도 없습니다. 다만 영향을 받는 인증서를 계속 신뢰하는 실행 환경은 업데이트가 필요합니다. 사고 설명과 개발자 안내

패키지만 바꿔서는 부족할 수 있는 이유는 인증서를 검사하는 곳이 하나가 아니기 때문입니다. 운영체제의 인증서 목록을 쓰는 도구도 있고, 실행 프로그램이 자체 목록을 갖고 있는 경우도 있습니다. 브라우저에서 접속이 안전하다고 확인해도, 백그라운드 작업이 같은 방식으로 검사한다는 보장은 없습니다.

0.12.13 다음에 0.12.14가 필요한 이유

앞선 0.12.13 이미지는 운영체제 인증서 목록과 Node.js, cloudflared, Python 이미지의 pip를 업데이트했습니다. 하지만 Bun이 쓰는 자체 인증서 목록에는 문제가 남아 있었습니다.

0.12.14는 Bun을 1.4.4로 바꿉니다. 이에 따라 bun 명령과 createBackup()이 10 MiB 이상의 아카이브를 업로드하는 경로도 해당 인증서를 거부하게 됩니다. MiB는 파일 크기를 세는 단위로, 10 MiB는 10,485,760바이트입니다. 공식 릴리스 기록은 OpenCode용 이미지에도 Bun 1.4.4를 사용하는 OpenCode 1.19.4 이상이 포함된다고 설명합니다. 공식 SDK 변경 기록

가령 샌드박스에서 자료를 정리하는 AI가 작은 파일을 내려받고, 작업이 끝나면 큰 백업을 올린다고 가정해 보겠습니다. 작은 요청은 curl을 통과하지만 큰 백업은 Bun을 사용한다면, curl 한 번을 시험한 것으로 두 경로를 모두 확인했다고 볼 수 없습니다. 실제로 공식 수정 PR은 작은 백업과 10 MiB 이상 분할 업로드가 서로 다른 경로를 사용한다고 설명합니다. 이 예시는 이해를 돕기 위한 가정이며 실제 고객 사례가 아닙니다. 수정 PR과 테스트 설명

쓰는 버전에 따라 조치가 달라집니다

0.x 사용자는 @cloudflare/sandbox@0.12.14와 대응하는 컨테이너 이미지를 함께 적용해야 합니다. Dockerfile의 FROM도 docker.io/cloudflare/sandbox:0.12.14로 맞추되, 기존에 쓰던 -python·-opencode·-musl 접미사는 유지합니다. SDK만 올리고 예전 이미지로 실행하면 이번 변경이 실제 작업 환경에 반영되지 않습니다. next 프리릴리스 사용자는 0.13.0-next.825.1 이상이 안내돼 있습니다. 버전별 공식 조치

1.x는 SDK 자체가 TLS 연결을 만들지 않으므로 이번 문제를 이유로 SDK를 바꾸는 것이 핵심은 아닙니다. 기반 이미지와 그 안의 프로그램을 업데이트해 다시 빌드해야 합니다. 공식 안내는 기반 이미지를 새로 받고 빌드 캐시를 비운 뒤 배포하도록 설명합니다. 이미지 digest를 고정했다면 새 이미지의 digest로 설정도 바꿔야 합니다.

그다음이 중요합니다. 실행 중인 컨테이너는 시작할 때의 이미지를 계속 사용합니다. 1.x의 해당 배포 방식에서는 새 이미지를 배포해도 기존 컨테이너가 저절로 재시작되지 않으므로 교체 과정까지 확인해야 합니다. 컨테이너 이미지 교체 방식

예전 스냅샷으로 돌아오면 예전 이미지도 돌아옵니다

컨테이너를 바로 중지하기 전에 진행 중인 작업과 저장할 파일부터 살펴야 합니다. 공식 문서는 destroy()가 즉시 실행을 멈추며, 진행 작업과 시작 이후의 파일 변경을 잃을 수 있다고 경고합니다.

스냅샷도 새 이미지로 옮겨 붙이는 수단은 아닙니다. 생성 당시 이미지에 연결돼 있어 예전 스냅샷을 복원하면 예전 이미지가 다시 사용됩니다. 필요한 작업 데이터의 보존 방법을 따로 정하고, 업데이트된 환경에서 사용할 스냅샷을 새로 만들어야 합니다. 이미지 교체 시 주의사항 · 스냅샷 문서

운영 담당자는 다음 순서로 점검할 수 있습니다.

1. SDK 계열과 실제 배포 이미지, 자체 설치한 프로그램을 확인합니다.
2. 진행 중인 작업과 파일 보존 계획을 세운 뒤 해당 버전의 업데이트·재배포·교체 절차를 적용합니다.
3. 새로 시작한 환경에서 앱이 쓰는 TLS 클라이언트별로 공식 안내의 시험을 수행합니다. 단순 네트워크 장애가 아니라 해당 인증서를 거부하는지 구분해 확인합니다.
4. 정상적인 다운로드·업로드·백업이 계속 동작하는지도 함께 확인합니다.

인증서 오류를 없애려고 검증 기능을 끄는 것은 해결책이 아닙니다. 위 항목은 독자의 환경에 맞춰 운영 담당자가 검토할 점검 순서이며, 이 글에서 독자의 시스템에 업데이트나 보안 설정 변경을 수행한 것은 아닙니다. 공식 개발자 점검 안내

AI 실행 환경의 보안을 이름이나 설정 하나로 끝낼 수 없다는 관점은 샌드박스의 권한 경계를 살펴본 기존 글과도 이어집니다. 다만 그 글의 Codex 사례와 이번 Cloudflare 인증서 조치는 서로 다른 사건입니다.

자료 확인: 2026년 10월 23일. 썸네일은 AI로 제작한 개념 이미지이며 실제 Cloudflare UI가 아닙니다. Cloudflare는 해당 권리자의 상표이며, 이 기사는 제휴나 후원 없이 작성했습니다.

저는 이번 안내를 읽을 때 ‘어느 버전으로 올렸는가’와 함께 ‘지금 일을 하는 환경이 정말 바뀌었는가’를 확인하는 편이 좋다고 봅니다. 업데이트 기록보다 실행 중인 이미지와 실제 연결 경로가 완료 판단에 더 직접적인 근거가 되기 때문입니다.