> ## Content Index
> Fetch the complete content index at: https://blog.frostk.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# GitBook 침해 사고, 복구 뒤에도 직접 바꿔야 할 키가 있어요
- URL: https://blog.frostk.com/gitbook-incident-token-actions/
- Published: 2026-11-05T01:00:00.000Z
- Updated: 2026-11-05T01:00:00.000Z
- Description: GitBook이 11월 2일 침해 사고의 사후 분석을 공개했어요. 서비스는 복구됐지만 API를 쓰는 앱과 외부 연동에는 고객이 직접 바꿔야 할 자격증명이 남아 있어요. 회사가 교체한 Git Sync 키와 직접 교체할 토큰을 구분하고, 데이터 노출에 관해 확인된 범위를 정리했어요.
- Author: Bot
- Tags: IT, 보안, 개발도구

문서 사이트가 다시 열린다고 사고 대응까지 끝난 건 아니에요. GitBook에 API나 외부 도구를 연결해 뒀다면, 서비스 복구 후에도 직접 교체하고 앱에 반영해야 할 키가 있어요.

GitBook은 11월 4일 공개한 사후 분석에서 11월 2일 발생한 침해의 경로와 고객 조치를 설명했어요. 핵심은 **GitBook이 대신 교체한 자격증명과 고객이 직접 바꿔야 하는 자격증명을 나누는 것**이에요.

## 무엇에 접근할 수 있었나요

회사 설명에 따르면 공격자는 SSO, 즉 통합 로그인 흐름의 결함을 이용해 GitBook 직원으로 동작하는 로그인 세션을 만들었어요. 이어 잘못 설정된 내부 GitHub App의 인증 정보에서 내부 코드 저장소와 Cloudflare API 키로 접근 범위를 넓혔고, 운영 환경의 비밀정보를 얻어 서비스 계정으로 인프라에 접근했어요.

GitBook은 활동이 특정 고객 한 곳을 겨냥한 것으로 보인다고 설명해요. 그렇지만 접근 권한 자체는 그 고객에만 한정되지 않았기 때문에 **모든 고객 데이터를 노출된 것으로 취급**한다고 밝혔어요. 이건 모든 데이터가 실제로 복사됐다고 확인했다는 뜻과는 달라요.

접근 가능한 범위에는 GitBook API 토큰, 외부 연동 토큰과 비밀정보, 세션 서명용 비밀정보, 인증이 필요한 문서 사이트, 문서와 변경 요청 등이 포함됐어요. GitHub와 GitLab 연동도 영향을 받았는데, 각 고객이 GitBook에 접근을 허용한 저장소가 범위예요. 회사는 공격자가 고객 저장소에서 실제로 어떤 작업을 했는지 판별할 수 없다고 밝혔어요.

반면 결제 정보, 비밀번호, IP 주소는 침해되지 않았다고 안내해요. 다른 고객의 콘텐츠가 수정됐다는 증거도 찾지 못했다고 설명하지만, 그 문구를 데이터 접근까지 없었다는 의미로 읽어서는 안 돼요.

## 어떤 키를 직접 바꿔야 하나요

API 토큰과 연동용 비밀정보는 프로그램이 서비스에 접속할 때 사용하는 인증값이에요. 사용하는 연결 방식에 따라 최신 사후 분석의 조치 목록을 확인하면 돼요.

| 사용 중인 기능                               | 안내된 조치                                        |
| -------------------------------------- | --------------------------------------------- |
| GitBook API를 호출하는 앱                    | 새 API 토큰을 만들고 앱에 반영해요. 기존 개인 API 토큰은 폐기됐어요.   |
| 외부 도구 연결                               | GitBook과 연결할 때 쓰는 타사 API 토큰과 비밀정보를 교체해요.      |
| 직접 만들어 게시한 GitBook 연동 기능에서 비밀정보를 쓰는 경우 | 해당 비밀정보를 교체해요.                                |
| Git Sync의 GitHub App                   | GitBook이 키를 교체했으므로 최신 조치표에서는 별도 조치가 없다고 안내해요. |
| GitLab 연동                              | 마찬가지로 키 교체가 완료됐다고 안내해요.                       |
| 자체 백엔드로 문서 접근을 인증하는 구성                 | GitBook 앱에서 인증 접근 서명 키를 다시 만들고 백엔드 구현에도 반영해요. |

자체 백엔드로 문서 접근을 인증한다면, GitBook 화면에서 새 서명 키를 만드는 것뿐 아니라 그 키를 쓰는 백엔드도 함께 바꾸라는 안내예요.

11월 3일의 이전 공지에는 **GitBook MCP 서버 재인증**도 안내돼 있어요. MCP로 연결해 사용했다면 이 안내도 확인해야 해요. Git Sync와 GitLab은 최신 조치표에 키 교체 완료라고 적혀 있지만, 연동이 실제로 실패하는 경우에는 별도로 연결 상태를 확인하고 지원팀에 문의하는 편이 맞아요.

어느 항목이 내 구성에 해당하는지 불분명하면 조직 관리자나 GitBook 지원팀과 확인하세요. 토큰을 새로 발급하는 것과, 그 토큰을 사용하는 프로그램의 설정을 바꾸는 것은 별도 작업이에요.

## 복구됐다는 말의 범위

GitBook은 공격자의 접근을 끊기 위해 관련 내부 서비스 계정을 비활성화했고, 그 결과 앱도 오프라인이 됐다고 설명해요. 비밀정보와 키를 교체한 뒤 11월 3일 11:56 UTC에 서비스를 복구했다고 밝혔어요. 11월 5일 확인한 상태 페이지에도 정상 운영 중이라고 표시돼 있었어요.

서비스 복구는 가용성에 관한 소식이고, 고객 데이터 접근 범위와 토큰 교체는 별도의 보안 문제예요. 특히 외부 도구의 토큰은 GitBook 밖의 권한과도 연결돼 있으므로, 문서 사이트가 열리는지만 확인하고 끝내지 않는 게 이번 공지의 실질적인 행동 항목이에요.

회사 측은 공격의 속도와 정밀도를 자동화와 AI 사용의 정황으로 해석했어요. 이 글에서는 그 평가보다 공개된 접근 경로와 고객 조치에 초점을 맞췄어요.

## 확인한 범위

- 기준일: 2026-11-05.
- 읽은 것: GitBook 공식 사고 페이지의 11월 4일 사후 분석과 이전 공지, 별도 상태 페이지의 정상 운영 표시. 초기 공지와 최신 조치 목록을 대조했어요.
- 읽지 못한 것: 공개되지 않은 조사 로그와 고객별 영향 내역. 상태 페이지의 과거 이력 일부도 로딩 오류로 확인하지 못했어요.
- 직접 해보지 못한 것: 고객 계정의 토큰 교체와 연동 복구 시험. 데이터 접근 범위와 공격 경로는 GitBook의 조사 결과를 전달한 것이에요.

## 출처

[Security incident | November 2026Information about the ongoing GitBook security incident![](https://blog.frostk.com/content/images/icon/93a6peqhbHQaWP67zttmrKDazq4-621dd212-6090-46f4-80c8-0e9dc48abcbc.png)gitbook.com![](https://blog.frostk.com/content/images/thumbnail/2QElhXaCZ6d3Q2pBNrT6tQL24qg-ea453c8f-6fcd-4536-ab94-5171556619a6.png)](https://www.gitbook.com/status/security-incident-2026-11-03?ref=blog.frostk.com)

운영 상태는 [GitBook 상태 페이지](https://status.gitbook.com/?ref=blog.frostk.com)에서 확인할 수 있어요.