AI 추론 플랫폼 Fireworks AI가 10월 초 첫 침해에 이어 추가 침해를 공개했습니다. 10월 23일 Fireworks의 R&D 머신을 호스팅하던 외부 클라우드 공급사가 뚫렸고, 공격자는 다음 날 그 경로로 Fireworks 개발 머신에 들어가 무단 작업을 돌렸습니다. Fireworks는 이와 함께 10월 사고의 영향 범위를 넓혀 공개했고, 일부 고객의 결제 정보와 미완성 모델 가중치·데이터셋이 영향을 받았다고 밝혔습니다. 확보한 증거는 훔친 AI 사용권을 되파는 'LLMJacking' 범죄 조직과 연결된다고 합니다.
무엇이 일어났나
BleepingComputer가 11월 10일 이 사고를 보도했습니다. Fireworks는 보안 공지에 경과를 정리해 11월 9일 갱신했습니다. Fireworks는 Mistral, Llama, Gemma 같은 공개 모델을 실행해 주는 추론·학습 플랫폼입니다. 고객사는 이곳의 API 키로 모델을 호출하고, 자체 데이터셋을 올려 모델을 미세조정합니다.
1차 사고: 평가 작업에 넣어 둔 비밀값
- 10월 6일 오전(미국 태평양 시간) Fireworks가 이상 활동을 확인하고 차단을 시작했습니다.
- 공격자가 Fireworks 내부 자격증명을 무단으로 썼습니다. 일부 고객 계정에서는 평가(evaluation) 작업의 환경 변수, 즉 비밀값으로 저장한 API 키와 토큰이 수집됐을 가능성이 있다고 공지했습니다.
- Fireworks는 직원 API 키와 서비스 계정 토큰을 교체하고 공격자가 만든 키도 폐기했습니다.
- 공지의 핵심 경고는 이것입니다. 플랫폼에 저장한 비밀값을 지워도 그 자격증명은 무효가 되지 않으므로, 처음 발급한 곳에서 교체해야 합니다.
2차 사고: 클라우드 공급사를 거쳐 개발 머신으로
- 10월 23일: Fireworks R&D 머신을 호스팅하던 외부 클라우드 공급사에서 보안 사고가 났습니다. 공급사 이름은 공개되지 않았습니다.
- 10월 24일: 공격자가 그 접근 권한으로 Fireworks 개발 머신에 들어가 무단 워크로드를 실행했고, 고객 데이터에 추가 영향이 생겼습니다. Fireworks는 같은 날 탐지했다고 밝혔습니다.
- 10월 25일 이후: 고객이 쓰는 플랫폼에 추가로 무단 접근한 증거는 없다고 했습니다.
Fireworks는 기존 조사에서 확인된 추가 영향과 후속 침해를 함께 설명했고, 데이터별로 어느 침해에서 나왔는지는 나누지 않았습니다. 공지에 적힌 영향 데이터는 세 종류입니다.
- 리소스 메타데이터: 리소스 식별자, 표시 이름, 설명, 생성 시각
- 결제 정보: 청구·배송 주소, 인보이스와 결제 이력, 계정 잔액, 크레딧 사용량(카드 번호는 저장하지 않아 영향이 없었다고 밝힘)
- 일부 고객의 미완성 모델 가중치와 데이터셋 일부
추론, Training SDK, Nexus는 기본 설정이 데이터 무보존(ZDR)이고 영향이 탐지되지 않았다고 합니다. 영향을 받은 고객 수는 공개하지 않았습니다. Fireworks는 사법기관에 알리고 팔로알토 네트웍스 Unit 42에 포렌식을 맡겼습니다. 조사 기간에는 배치 추론과 데이터셋 기반 학습에서 셀프서비스 데이터셋 업로드·다운로드를 막았습니다.
직접 계약하지 않은 고객에게까지 번졌다
Notion은 보안 공지에서 Insights 기능의 분류 작업과 공개 가중치(open-weight) 모델 제공에 Fireworks를 써 왔다고 밝혔습니다. 경과는 다음과 같습니다.
- 11월 2일: Fireworks에서 합성 테스트 데이터가 접근됐다는 통보를 받았습니다.
- 11월 3일: Fireworks와의 연결을 끊고 그곳에 있던 데이터를 지웠습니다.
- 11월 6일: 고객 데이터도 접근됐을 수 있다는 추가 통보를 받았습니다.
- 11월 8일: 최종 확정된 데이터셋에 Insights용 Notion AI 대화 기록이 들어 있었습니다. 영향 범위는 전체 워크스페이스의 1% 미만입니다.
Notion에 따르면 영향을 받은 워크스페이스 대다수의 기록에는 작성자·워크스페이스 표식과 도구 호출 결과가 없었습니다. 다만 대화 본문 자체에 식별 정보나 비밀값이 있을 수 있습니다.
Notion은 Insights를 끄고 Fireworks를 통한 모델 제공도 중단했습니다. 영향을 받은 워크스페이스에는 그 기간 AI 대화에 입력한 비밀번호나 API 키를 발급처에서 교체하라고 권고했습니다. Notion 이용자는 Fireworks와 직접 계약한 관계가 아닙니다. 그런데도 자기 대화 기록이 그곳에 있었습니다. 이번 사고에서 기업이 가장 눈여겨볼 지점이 바로 이것입니다.
공격자는 왜 AI 플랫폼을 노리나
Fireworks는 배후로 금전 목적의 범죄 조직을 지목했습니다. 이 조직은 LLM에 무단으로 접근해 얻은 토큰을 불법 라우팅 게이트웨이에 파는데, 이를 LLMJacking이라고 부릅니다. 구글 위협 인텔리전스 그룹(GTIG)과 Mandiant가 11월 초 낸 보고서에 따르면, 개별 사고에서 하루 10만 달러가 넘는 부정 과금이 나왔습니다. 접근을 끊기 전까지 누적 과금이 100만 달러에 이른 조직도 있었습니다. 주된 침투 경로는 노출되거나 탈취된 클라우드 자격증명(서비스 계정 키, GitHub 개인 액세스 토큰, 세션 토큰)이었습니다. AI 서비스를 켠 적 없는 조직에서 공격자가 직접 서비스를 활성화한 사례도 여러 건 있었습니다. 훔친 키가 아직 유효한지 max_tokens=1 같은 최소 요청으로 조용히 확인하는 수법도 보고됐습니다.
Wiz는 10월 30일 공개한 'Black October' 분석에서 10월 한 달 동안 사고가 난 AI 개발 플랫폼을 처음 9곳으로 정리했고, 이후 갱신하며 목록을 늘렸습니다. 첫 사례가 Fireworks였습니다. Wiz 정리에 따르면 Fireworks와 OpenCode, Warp는 '에이전트 스웜(agent swarm)' 공격 징후를 보고했습니다. 다만 공격에 AI 에이전트가 구체적으로 어떻게 쓰였는지는 공개 자료로 확인되지 않습니다. 같은 시기 Northflank·Trigger.dev 사고와 비밀값 교체 순서는 WorkOS·Northflank·Trigger.dev 침해 대응 글에서 다뤘습니다. 이 글은 비밀값보다 넓게 데이터셋, 모델 가중치, 결제 정보, 그리고 '공급사의 공급사'를 다룹니다.
우리 회사가 해당하는지 확인하는 법
세 경우로 나눠 보면 빠릅니다.
- 직접 고객: Fireworks 계정이 있거나, 카드·법인 결제 내역에 Fireworks 청구가 있거나, 코드와 환경 변수에 Fireworks API 키가 있는 경우입니다. Fireworks는 1차 공지에서 통지를 받지 않은 계정은 영향 대상으로 확인되지 않았다고 안내했습니다. 통지 메일부터 찾으세요.
- 간접 이용자: 쓰고 있는 SaaS의 AI 기능이 뒤에서 외부 추론 공급사를 쓰는 경우입니다. 공급사가 통지하지 않으면 알기 어렵기 때문에, 주요 SaaS의 하위 처리자(sub-processor) 목록과 보안 공지를 직접 확인해야 합니다.
- 같은 구조의 회사: 개발·실험 머신을 외부 GPU 클라우드나 임대 서버에 두고, 그 머신에서 운영 데이터나 학습 데이터에 접근할 수 있다면 Fireworks 2차 사고와 같은 구조의 위험을 안고 있습니다.
판단할 때는 다음 질문에 답해 보세요.
- 외부 AI 플랫폼에 올린 데이터셋에 고객 대화, 개인정보, 소스코드, 내부 문서가 들어 있었나
- 미세조정한 모델이 그 데이터로 학습했나
- 평가·학습 작업에 다른 서비스의 키를 비밀값으로 넣어 두었나
- 우리 서비스의 AI 기능이 고객 데이터를 외부 공급사로 보내고 있고, 그 사실을 고객에게 알리고 있나
대응 순서
오늘
- Fireworks나 이용 중인 SaaS에서 온 사고 통지 메일을 찾고, 통지에 적힌 영향 데이터 종류를 기록합니다. 문의는 통지 메일에 회신하거나 공지에 안내된 공식 창구로만 합니다.
- 아래 키 교체는 통지나 조사에서 노출 대상으로 확인됐거나 의심되는 자격증명에 적용합니다. 통지에서 폐기됐다고 지정한 Fireworks 키는 새로 발급해 애플리케이션 설정을 갱신합니다. Fireworks는 폐기된 키를 쓰는 애플리케이션이 교체 전까지 인증에 실패한다고 안내했으니, 배포 순서를 먼저 정하세요.
- Fireworks 평가·학습 작업에 저장했던 다른 서비스의 키는 각 발급처에서 직접 교체합니다. 저장값을 지우는 것만으로는 부족합니다.
- 노출 대상 자격증명마다 그 키로 접근할 수 있는 데이터와 발급처의 접속 기록을 확인해 무단 열람·다운로드·변경이 있었는지 조사합니다. 의심 기록이 없어도 지정된 자격증명은 교체합니다.
- 계정 안에 모르는 API 키, 사용자, 평가기, 학습 작업, 데이터셋이 있는지 확인합니다. Fireworks가 1차 공지에서 고객에게 요청한 항목입니다.
- 사내에서 쓰는 AI·클라우드 서비스의 사용량과 청구액을 모두 확인합니다. LLMJacking 비용은 키 주인에게 청구되므로 청구 추이가 빠른 신호가 될 수 있습니다.
- 영향 데이터에 개인정보가 있었다면 바로 개인정보 담당자와 함께 영향 데이터, 인지 시점, 통지·신고 의무가 적용되는지와 그 기한을 검토합니다. 개인정보보호법은 유출 통지·신고에 원칙적으로 알게 된 때부터 72시간의 기한을 두고 있고, 신고 대상인지는 유출 규모·정보 종류·원인에 따라 달라집니다. 상세 조사가 끝날 때까지 초기 판단을 미루지 않습니다.
이번 주
- 노출된 데이터셋과 모델 가중치에 무엇이 들어 있었는지 영향을 평가합니다.
- 재무·구매 담당자에게 결제 정보 노출 사실을 공유합니다. 청구 주소와 결제 이력은 그럴듯한 청구서 사칭이나 입금 계좌 변경 요청 메일의 재료가 될 수 있습니다.
- 클라우드 감사 로그에 생성형 AI 서비스 활성화 알림을 겁니다. GTIG는 승인하지 않은 LLM 서비스 활성화를 중대한 보안 이벤트로 다루라고 권고합니다. 예로 든 이벤트는 AWS Bedrock의
PutUseCaseForModelAccess·CreateFoundationModelAgreement입니다. Google Cloud는google.api.serviceusage.v1.ServiceUsage.EnableService, Azure는Microsoft.CognitiveServices/accounts/deployments/write를 감시하면 됩니다. Google Cloud의 서비스 활성화는 관리 활동(Admin Activity) 감사 로그에 남지만, AI 서비스의 실제 호출까지 조사하려면 대부분의 서비스에서 기본으로 꺼져 있는 데이터 접근(Data Access) 감사 로그를 따로 켜야 합니다. - AI API 키를 모델·환경(개발·운영)·사용 한도별로 나누고, 프로젝트마다 예산 상한과 알림을 설정합니다.
- 코드 저장소와 CI 설정에 하드코딩된 키가 있는지 찾습니다. 점검 방법은 API 키 노출 점검 글에 정리돼 있습니다.
이번 달
- 사내 AI 공급망 지도를 만듭니다. 직접 계약한 AI 공급사와, 우리가 쓰는 SaaS가 다시 쓰는 AI 공급사를 모두 적고 각 공급사로 가는 데이터를 표시합니다.
- AI 공급사 평가 기준에 다음 항목을 넣습니다: 데이터 무보존이 기본인지, 학습 데이터를 얼마나 보관하고 어떻게 지우는지, 사고를 언제 통지하는지, 하위 처리자가 바뀌면 알려 주는지.
- 개발·실험 머신과 운영 데이터를 분리합니다. Fireworks가 사후 조치로 꼽은 항목을 우리 환경 점검표로 그대로 쓸 수 있습니다. 불필요한 상위 권한 제거, 자격증명 발급 통제, 무단 네트워크 경로 차단, 저장소·분석 시스템의 공개 접근 차단, 로깅 강화입니다.
- 모델 게이트웨이도 취약점 관리 대상에 넣습니다. GTIG 보고서는 LiteLLM의 키 재발급 경로를 이용한 권한 상승 사례를 보고했습니다. 다만 보고서가 붙인 CVE 번호는 LiteLLM 제작사 권고의 설명과 맞지 않아 여기서는 번호를 연결하지 않습니다. 쓰는 버전의 영향과 수정 여부는 LiteLLM 보안 권고에서 직접 확인하세요. LiteLLM 관련 공급망 사고는 LiteLLM 공급망 공격 대응 글을 참고하세요.
- AI 공급사에서 사고 통지를 받았을 때의 절차를 한 장으로 정리합니다. 누가 판단하는지, 어떤 키를 먼저 바꾸는지, 고객에게 무엇을 알리는지까지 담습니다.
자가점검
- 우리 회사가 직접 쓰는 AI 추론·학습 공급사 목록이 있다
- 주요 SaaS의 AI 기능이 어떤 외부 공급사를 쓰는지 안다
- 외부 AI 플랫폼에 올린 데이터셋과 미세조정 모델의 목록, 그 안에 담긴 데이터 종류를 안다
- 외부 플랫폼에 비밀값으로 넣은 키의 목록이 있고, 발급처에서 교체하는 절차가 있다
- AI API 키의 사용 범위가 모델·환경·한도별로 나뉘어 있다
- AI·클라우드 서비스마다 예산 상한과 이상 사용 알림이 있다
- 쓰지 않는 생성형 AI 서비스가 클라우드 계정에서 켜지면 알림이 온다
- 외부에 둔 개발 머신에서 운영 데이터 저장소로 바로 이어지는 경로가 없다
- 재무팀에 청구서·결제 계좌 변경 요청을 별도 경로로 재확인하는 규칙이 있다
외부 AI 연결 경로를 검증하려면
이번 사고가 주는 교훈은 키 하나나 공급사 하나가 뚫렸을 때 그 연결이 어디까지 이어지는지 미리 알아 둬야 한다는 점입니다. 보안 전문 기업 SENTRIX의 AI 심화 취약점 진단은 LLM 애플리케이션과 에이전트가 어떤 권한과 키로 외부 AI 공급사와 내부 데이터에 연결되는지 살핍니다. AI로 공격 경로 후보를 찾고, 합의한 범위에서 레드팀이 직접 검증한 뒤 재현 근거와 수정 방향을 드립니다. 진단으로 모든 위험이 사라지지는 않지만, 어느 연결부터 줄일지 근거를 가지고 정할 수 있습니다. 사내 AI 기능이 어떤 공급사와 어떤 키로 이어져 있는지 정리했다면, 그 경로를 실제로 검증할지 SENTRIX와 상담해 보시기 바랍니다.
참고 자료
- Fireworks 보안 공지 'October 2026 security incident' 및 후속 업데이트(11월 9일 갱신본, Fireworks 웹사이트 보안 공지 페이지)
- Notion 보안 권고 'Fireworks AI incident'(Notion 웹사이트 보안 권고 페이지)
- Google Cloud 블로그: The Rise of LLMJacking (GTIG·Mandiant)
- Wiz: "Black October" for AI Developer Platforms
- BleepingComputer: Fireworks AI discloses new breach after cloud provider hack