대상: Chainstack 노드나 API를 쓰는 개발자, dApp 운영자, 조직 관리자. 이 글은 회사의 공식 공지를 바탕으로 하며 공격 수법은 다루지 않습니다.
진행 중: 기관이 추가 정보를 발표하는 대로 이 글을 업데이트합니다
- 대상
Chainstack 노드나 API를 쓰는 개발자, dApp 운영자, 조직 관리자.
- 확인된 영향 범위표 보기 ↓
- 무단 접근 기간
- 운영 환경에 대한 접근
- 고객 계정 데이터베이스
1개 더 보기
- 조사
가능성이 있다고 한 항목
- 조직 이름, 계정 소유자 이름
- 조직 구성원의 이메일 주소
- 비밀번호 해시
1개 더 보기
- 노드 자격 증명
- 아직 확인되지 않은 사항
- 영향을 받은 고객 수
- 비밀번호 해시에 쓰인 알고리즘
- 제3자 구성 요소가 무엇이며 침입이 어떻게 진행되었는지
2개 더 보기
- 노드 자격 증명이 실제로 읽혔는지
- 악용(2차 피해)이 발생하는지
- 지금 할 일절차 보기 ↓
- 비밀번호를 바꾸세요
- 노드 자격 증명을 교체하세요
- 플랫폼 API 키를 재생성하세요
3개 더 보기
- 들어 있는 엔드포인트와 키를 찾아서 바꾸세요
- 예상 밖의 사용량이나 청구를 확인하세요
- Chainstack을 사칭하는 상대는 링크를 열지 말고 확인하세요
- 확인처(출처)출처 전체 ↓
- Chainstack, "Incident report: what happened and what customers need to do"(영어, 2026년 11월 3일자, 11월 4일 확인)
- 마지막 확인
- 2026년 11월 4일 기준
후속 발표 예정과 확인 기록
회사의 공지는 11월 3일자이며 새로운 정보가 있으면 업데이트하겠다고 밝혔습니다. 11월 4일 공지 본문을 확인했으며 11월 3일 버전 이후 변경은 없었습니다. 회사는 11월 2일에 조사를 마쳤다고 밝혔습니다.
Chainstack 사용자가 오늘 해야 할 일
비밀번호를 바꾸세요
회사는 고객에게 비밀번호를 바꾸라고 요청하며, 같은 비밀번호를 돌려 쓴 다른 서비스도 포함합니다.
- 이 사이트의 보충: 서비스마다 다른 비밀번호를 쓰도록 비밀번호 관리자를 쓰세요(비밀번호 관리자 고르기)
- 이 사이트의 보충: 사용할 수 있다면 2단계 인증을 켜세요. 공지는 이를 언급하지 않습니다
노드 자격 증명을 교체하세요
회사는 고객에게 노드 자격 증명을 교체하라고 요청합니다. 콘솔에서 직접 할 수 있고, 교체를 마칠 때까지 현재 엔드포인트가 계속 작동하므로 가동 중단이 없다고 합니다. 절차는 회사 문서에 설명되어 있습니다.
- 이 사이트의 보충: 새 자격 증명을 먼저 앱에 넣고 작동을 확인한 다음 이전 것을 무효화하세요
플랫폼 API 키를 재생성하세요
플랫폼 API를 쓴다면 회사는 API 키를 재생성하라고 요청합니다. 이를 쓰는 CI/CD, 자동화 스크립트, 운영 도구도 함께 업데이트하세요. 더 이상 쓰지 않는 키는 다시 만들지 말고 삭제하세요(이 사이트의 보충, 환경 변수와 API 키 기본).
들어 있는 엔드포인트와 키를 찾아서 바꾸세요
노드 엔드포인트는 자격 증명이 담긴 URL 형태인 경우가 많으며 앱 코드, 설정 파일, CI 변수, 프런트엔드에 있을 수 있습니다. 이 사이트의 견해: 프런트엔드에 들어 있는 URL은 모든 방문자가 볼 수 있으므로, 교체 후 다시 빌드해 배포하기 전까지는 이전 자격 증명이 공개 결과물에 남아 있습니다.
- 설정, CI 비밀 변수, 컨테이너 환경 변수, 저장소 이력에서 이전 URL을 검색하세요
- 공개된 프런트엔드(빌드 결과물과 소스 맵)를 다시 빌드해 배포하세요
- 자체 서버를 거쳐 요청을 보낼 수 있다면 브라우저에 자격 증명을 넘기지 마세요
예상 밖의 사용량이나 청구를 확인하세요
회사는 노드, 콘솔, API가 변경되지 않았고 서비스는 계속되었다고 밝혔습니다. 자격 증명이 쓰였을 경우에 대비해 이 사이트는 다음을 확인하라고 제안합니다.
- 노드의 요청 수, 호출자, 사용된 메서드가 이상하지 않은지
- 청구서가 갑자기 늘지 않았는지
- 모르는 구성원이나 권한이 조직에 없는지
Chainstack을 사칭하는 상대는 링크를 열지 말고 확인하세요
회사는 고객에게 피싱을 주의하라고 요청하며 비밀번호, 토큰, 키를 절대 요구하지 않는다고 합니다. 이메일의 링크를 쓰지 말고 공식 콘솔이나 공지 페이지를 직접 여세요. 피싱이란?
① 콘솔에서 자격 증명을 교체
마칠 때까지 현재 엔드포인트는 계속 작동(회사)
↓
② 앱, CI, 프런트엔드를 새것으로 바꾸고 작동 확인
↓
③ 이전 자격 증명이 더 이상 쓰이지 않는지 확인
공개된 프런트엔드에 이전 URL이 남아 있지 않을 것
무슨 일이 있었나요 (Chainstack 공지 기준)
아래는 회사가 게시한 2026년 11월 3일자 사고 보고서를 바탕으로 합니다.
2026년 10월 26일
외부 공격자가 개발 환경에 접근(회사 설명)10월 29일
공격자가 운영 환경 일부에 접근(회사 설명)10월 31일
회사가 침입을 감지하고 같은 날 접근 경로를 차단(회사 설명)11월 2일
회사가 조사를 확정하고 사건을 종결(회사 설명)11월 3일
공지 게시. 회사는 모든 고객에게 이메일을 보내고 있다고 밝힘11월 4일
이 사이트가 공지 본문을 확인. 11월 3일 버전 이후 변경은 찾지 못함
- 침입 경로
- 외부 공격자가 제3자 구성 요소를 통해 인프라 일부에 접근. 공지는 그 구성 요소가 무엇인지 밝히지 않음
- 배경
- 회사는 이 사건이 10월 하순에 보고된 더 넓은 AI 기반 공격 캠페인의 일부라고 평가함. 그렇다고 자사 환경에서 일어난 일에 대한 책임이 달라지지 않는다고도 씀
- 노출되었을 수 있는 정보
- 조직 이름, 계정 소유자 이름, 조직 구성원의 이메일 주소, 비밀번호 해시(고객 계정 데이터베이스). 해시 알고리즘은 밝히지 않음
- 노드 자격 증명
- 보관하는 시스템에 접근이 있었음. 읽었다는 증거는 없으나 노출된 것으로 취급
- 포함되지 않음
- 결제 수단 정보(회사가 저장하지 않음). 노드, 콘솔, API의 변경 없음, 서비스는 계속됨
- 회사 대응
- 접근 경로 차단, 시스템 강화, 모든 고객에게 이메일 발송. 사용자에게 비밀번호 변경, 노드 자격 증명 교체, 플랫폼 API 키 재생성, 피싱 주의를 요청
확인된 것과 아직 알려지지 않은 것
2026년 11월 4일 기준 상태입니다. 후속 공지가 나오면 이 표를 고쳐 씁니다.
| 항목 | 공지 내용 | 상태 |
|---|---|---|
| 무단 접근 기간 | 2026년 10월 26일(개발 환경)부터 10월 31일(감지 및 차단)까지 | 확인됨(회사) |
| 운영 환경에 대한 접근 | 10월 29일 운영 환경 일부에 접근 | 확인됨(회사) |
| 고객 계정 데이터베이스 | 공격자가 접근 | 확인됨(회사) |
| 조직 이름, 계정 소유자 이름 | 노출되었을 수 있음 | 가능성 있음(회사) |
| 조직 구성원의 이메일 주소 | 노출되었을 수 있음 | 가능성 있음(회사) |
| 비밀번호 해시 | 노출되었을 수 있음. 알고리즘은 밝히지 않음 | 가능성 있음(회사) |
| 노드 자격 증명 | 보관하는 시스템에 접근이 있었음. 읽었다는 증거는 없으나 노출된 것으로 취급 | 가능성 있음(회사) |
| 결제 수단 정보 | 회사가 저장하지 않으므로 노출되지 않음 | 포함되지 않음(회사) |
| 노드, 콘솔, API의 변경 | 없음. 서비스는 계속됨 | 없음(회사) |
| 영향을 받은 고객 수 | 밝히지 않음. 회사는 모든 고객에게 이메일을 보내고 있다고 함 | 밝히지 않음 |
| 침입 경로 | 제3자 구성 요소. 무엇인지는 밝히지 않음 | 조사 중 |
| 악용(2차 피해) | 밝히지 않음 | 밝히지 않음 |
| 조사 | 11월 2일 확정하고 사건 종결. 새 정보가 나오면 업데이트 | 확인됨(회사) |
왜 ‘가능성 있음’이라고 쓰는가
회사는 고객 계정 정보가 "노출되었을 수 있다"고 쓰고, 노드 자격 증명은 읽었다는 증거가 없지만 노출된 것으로 취급한다고 씁니다. 이 사이트는 상태를 회사 자신의 표현으로 유지합니다. 공지로는 실제로 무엇이 반출되었는지 알 수 없습니다.
계정 데이터와 노드 자격 증명이 무엇으로 이어질 수 있나
아래는 이 조합의 항목으로 일반적으로 생길 수 있는 일이며, 이번에 그런 일이 있었다고 회사가 밝힌 것은 아닙니다.
- 조직 이름 + 계정 소유자 이름 + 구성원 이메일 주소: 회사나 협력사를 사칭한 설득력 있는 메시지의 재료
- 비밀번호 해시: 해시는 비밀번호 자체가 아니지만, 약하거나 돌려 쓴 비밀번호는 나중에 추측될 수 있습니다. 알고리즘이 밝혀지지 않아 강도를 판단할 수 없습니다. 비밀번호를 바꾸는 것이 먼저입니다(비밀번호 해싱이란?)
- 노드 자격 증명: 엔드포인트에 접속하는 데 쓰는 자격 증명으로, 가진 사람은 고객 행세로 요청을 보낼 수 있어 사용량과 청구에 영향을 줄 수 있습니다. 프런트엔드에 들어 있었다면 어차피 방문자에게 보였습니다
- 돌려 쓴 비밀번호: 다른 서비스에서 같은 비밀번호를 쓴다면 그곳도 바꾸세요. 비밀번호 유출 여부 확인 방법
개발자와 운영자가 점검할 것
침입 경로로 공개된 것은 "제3자 구성 요소"뿐입니다. 공개된 사실(자격 증명을 보관하는 시스템에 접근이 있었음, 가동 중단 없이 교체 가능)에서 따라 나오는 것은 일반적인 점검 사항뿐입니다.
- 교체하기 쉽게 만드세요: 코드에 자격 증명을 쓰지 말고 환경 변수나 비밀 관리자로 전달하세요. 바꿀 곳이 한 군데면 이런 공지가 온 날 바로 대응할 수 있습니다
- 브라우저에 넘기는 자격 증명을 줄이세요: 프런트엔드에 들어 있는 URL은 공개 결과물에 남습니다. 자체 서버를 거치거나, 공급사가 제공한다면 자격 증명을 쓸 수 있는 곳을 제한하는 기능을 쓰세요(공급사 문서를 확인)
- 용도별로 키를 나누세요: 환경(개발, 운영)별, 앱별로 자격 증명을 나누면 교체의 영향이 작아집니다(환경 변수와 API 키 기본)
- 공급사 콘솔을 보호하세요: 사용할 수 있다면 2단계 인증을 필수로 하고 로그인과 키 생성 알림을 켜세요(다중 인증 고르기)
이는 일반적인 점검 사항이며, 회사나 그 사용자가 이를 하지 않았다는 뜻이 아닙니다.
출처 (공개 기록)
이 글의 사실은 아래 공개 정보를 바탕으로 합니다. 공개되지 않은 침입 경로와 반출된 데이터 범위는 추측하지 않습니다.
- Chainstack, "Incident report: what happened and what customers need to do"(영어, 2026년 11월 3일자, 11월 4일 확인) — chainstack.com
업데이트 기록
2026-11-04: 첫 버전. 회사의 2026년 11월 3일자 사고 보고서를 바탕으로 함(11월 4일 확인, 더 새로운 업데이트는 찾지 못함).
다음으로 읽을 글
- 더 최근의 개발자 서비스 사례: DigiCert 내부 시스템 무단 접근
- 더 최근의 개발자 플랫폼 사례: WorkOS 내부 영업 앱 무단 접근
- API 키와 비밀 정보 관리: 환경 변수와 API 키 기본 / 유출된 뒤에도 유효한 자격 증명
- 관련 사건: PingCAP(TiDB Cloud) 무단 접근, Railway 환경 변수 노출 가능성, Northflank 사건과 API 키
- 사기 메시지 대비: 피싱이란?
- 계정 보호: 다중 인증 고르기
- 2026년 기타 사건: 데이터 유출 및 사이버 공격(일본과 해외)