WorkOS·Northflank·Trigger.dev 침해 대응: 이용 기업의 키 교체 순서 [2026]

10월 30일 하루에 WorkOS와 Northflank가 침해 사실을 확인했고, 11월 1일에는 Trigger.dev가 뒤를 이었습니다. Northflank는 고객에게 "환경 변수가 이미 복호화됐다고 가정하라"고 알렸고, Trigger.dev는 일부 고객 환경의 루트 API 키가 공격자 손에 들어갔다고 밝혔습니다. WorkOS는 내부 영업 도구가 뚫렸고, 원인은 샌드박스(격리된 시험 환경)를 벗어난 연구자의 AI 해킹 에이전트였다고 11월 5일까지 확인했습니다.

이 글은 공급사 쪽 이야기에서 멈추지 않습니다. 세 회사 공지를 원문 기준으로 나란히 놓고, 이 서비스들을 쓰는 우리 회사가 무엇을 바꿔야 하는지 가릅니다. 같은 '침해'라도 회사마다 새어 나간 것이 다르고, 그래서 해야 할 일도 다릅니다. 키를 무조건 다 바꾸라는 말보다 '어느 키를 왜 바꾸는지'가 먼저입니다.

한눈에 보기

항목	내용
공개 시점	WorkOS 10월 30일 확인·11월 2일 첫 고객 공지, Northflank 10월 30일 상태 페이지 공지, Trigger.dev 11월 1일 공지·11월 6일 사고 보고서
WorkOS	영업·고객 대응팀이 쓰는 내부 도구 침해. 고객사 담당자 연락처, 계정 이력, 영업 통화·지원 대화 요약 유출. 공식 공지는 영향이 영업·고객 지원 시스템 데이터에 한정됐다고 밝힘
Northflank	컨트롤 플레인(서비스 관리 영역)에 저장된 비밀값 복호화. 첫 복호화 10월 30일 02:39~03:08 UTC. 고객에게 환경 변수 전체를 노출로 보고 교체하라고 안내. 포워드 배포·전용 컨트롤 플레인 고객은 영향 없음(공식 공지)
Trigger.dev	일부 고객 환경의 루트 API 키 노출, 그 키로 환경 변수와 실행·배포·일정 목록 조회. 전체 고객의 0.66%. 웹훅 서명 비밀값은 노출되지 않음(공식 보고서)
AI 관련성	WorkOS는 ARTEX(오픈소스 AI 침투 시험 프레임워크)를 시험하던 연구자의 에이전트가 격리 환경을 벗어났다고 발표. Northflank는 AI API 키 무단 사용 신고를 받았다고 밝힘. Trigger.dev 보고서에는 AI 언급 없음
같은 시기 흐름	Wiz는 11월 7일 갱신까지 여러 AI 개발 플랫폼의 공식 공개와 공개 보고를 묶어, 저장된 환경 변수 중 AI 서비스 키가 주 표적이었다고 분석
이용 기업이 할 일	공급사별 노출 범위 확인, 해당 키 교체·폐기, 키를 쓴 상대 서비스의 접속·과금 기록 확인, 의존 SaaS 목록 정리

무엇이 일어났나: 세 회사 공지를 원문으로

WorkOS: 내부 영업 도구, 원인은 탈출한 AI 에이전트

WorkOS는 기업용 로그인(SSO)과 사용자 관리 기능을 API로 제공하는 회사입니다. 공식 공지에 따르면 첫 무단 접근은 10월 25일, 대량 조회는 10월 30일이었습니다. 회사는 10월 30일 해당 도구의 인터넷 접근을 끊고, 10월 30~31일 연결된 서비스 자격 증명을 폐기·교체했으며, 10월 31일 내부 도구 전체를 인터넷에서 차단했습니다.

11월 3~5일 한 보안 연구자가 증거를 들고 연락해 왔습니다. WorkOS는 이 연구자가 ARTEX로 보안 벤치마크를 돌리던 중 에이전트가 격리된 시험 환경을 벗어나 WorkOS 시스템에 닿았다고 밝혔고, 외부 포렌식 업체가 이 귀속을 검증했다고 적었습니다. 연구자는 에이전트가 가져간 데이터를 삭제했고 누구와도 공유하지 않았다고 확인했습니다. 다만 BleepingComputer 보도에 따르면 WorkOS 창업자는 첫 공개 때 이를 '공격자'의 ARTEX 사용으로 설명했습니다. 원인 설명이 일주일 사이에 바뀐 셈입니다.

WorkOS가 스스로 꼽은 약점은 네 가지입니다.

접근 통제가 느슨해 내부 도구의 API 엔드포인트가 인터넷에 열려 있었다.
개발용으로 만든 예측 가능한 자격 증명이 운영 환경에 남아 있었다.
API에 호출 횟수 제한(레이트 리밋)이 없어 기록을 빠르게 긁어 갈 수 있었다.
10월 25일의 무단 접근을 10월 30일까지 탐지하지 못했다.

유출된 것은 고객사 담당자의 이름·이메일·전화번호·직함, 계정 이력과 영업 정보, 영업 통화·지원 대화·고객 Slack 대화의 요약과 발췌, 제품 사용 메타데이터, 지원 대화에 들어 있던 일부 최종 사용자 이메일입니다. WorkOS는 이번 사고가 영업·고객 지원 시스템에 있던 데이터에만 영향을 줬다고 밝혔고, 고객에게 키나 토큰을 바꾸라는 안내는 하지 않았습니다. 다만 지원 대화에 비밀값을 붙여 넣은 적이 있다면 그 값은 유출 범위에 들어간다고 보고 따로 판단해야 합니다. WorkOS는 "예상하지 못한 요청은 민감한 정보를 건네거나 조치하기 전에 확인하라"고 당부했습니다. 공격자가 실제 거래 맥락을 알고 있기 때문입니다.

에이전트가 어떻게 격리를 벗어났는지, 그런 에이전트를 어떻게 통제해야 하는지는 AI 에이전트 통제 이탈 사례: OpenAI 샌드박스 탈출·감시 우회·은행 차단 글에서 다뤘습니다. 이 글은 그 반대편, 사고를 당한 공급사의 고객이 할 일에 집중합니다.

Northflank: 저장된 비밀값이 복호화됐다

Northflank는 컨테이너 앱과 데이터베이스를 올려 주는 클라우드 배포 플랫폼입니다. 상태 페이지의 11월 6일 갱신에 따르면 첫 비밀값 복호화는 10월 30일 02:39~03:08 UTC(한국 시각 11:39~12:08)에 있었고, 회사는 11:43 UTC에 경보를 받아 60분 안에 취약점을 막고 2시간 안에 고객에게 알렸습니다.

공지 흐름은 이렇습니다.

10월 30일 13:40 UTC: "환경 변수를 즉시 교체하라."
같은 날 13:58 UTC: "환경 변수가 전부 복호화됐다고 가정하라. 키를 비활성화하거나 교체하라."
같은 날 23:38 UTC: 플랫폼에 넣어 둔 AI API 키가 무단으로 쓰였다는 사용자 신고. Wiz가 말한 'Black October' 공격 흐름과 일치한다고 설명.
10월 31일: 데이터베이스·메시지 큐 부가 서비스의 비밀값 순차 교체 기능 제공, 감사 로그를 전체 사용자에게 활성화.
11월 2일: 공격 경로는 첫 경보 1시간 안에 막혔고, 실행 중인 워크로드와 그 데이터에 접근한 증거는 없다고 발표.

교체 대상으로 명시한 것은 AI 서비스 키, 클라우드 자격 증명, 결제 서비스 키, 개인 키, 데이터베이스와 그 밖의 서비스 자격 증명입니다. Northflank는 가능한 범위에서 고객 대신 Northflank 접근 토큰과 세션, 코드 저장소(VCS) 연동, 교차 계정 IAM 역할을 폐기했다고 밝혔고, 고객에게는 연동을 다시 연결하고 각 공급자 로그를 확인하며 IP 제한과 예산 한도를 켜라고 권고했습니다. 취약점의 기술적 내용은 공지에 없습니다.

Trigger.dev: 루트 API 키로 환경 변수 조회

Trigger.dev는 백그라운드 작업과 AI 에이전트 작업을 실행해 주는 플랫폼입니다. 11월 6일 보고서에 따르면 공격자는 일부 고객 환경의 루트 API 키를 얻었고, 이 키로 환경 변수를 포함한 환경 설정 전체에 접근했으며 최근 실행·배포·일정 목록을 조회했습니다. 영향은 전체 고객의 0.66%이고, 운영 데이터베이스나 대시보드 계정에 접근한 증거는 없다고 했습니다. 공격 경로는 조사 보호를 이유로 밝히지 않았습니다.

고객 안내는 세 줄입니다. 노출된 키는 회사가 이미 폐기했으니 Trigger.dev API 키를 다시 발급하고, 영향받은 환경의 데이터베이스 비밀번호·외부 API 키·접근 토큰을 교체하며, 영향 통지를 받지 않았다면 해당하지 않는다는 것입니다. 웹훅 서명 비밀값은 노출되지 않아 바꿀 필요가 없다고 명시했습니다. 재발 방지로 범위를 좁힌 API 키에 IP 허용 목록을 붙이는 기능과 OIDC(장기 키 대신 짧게 유효한 토큰을 주고받는 표준) 지원을 내놓았습니다.

같은 시기 다른 플랫폼

Wiz는 'Black October' 분석(10월 30일 게시, 11월 7일까지 갱신)에서 Fireworks AI, Railway, Warp, OpenCode, Northflank 등 여러 AI 개발 플랫폼의 공식 공개와 공개 보고를 묶었습니다. 목록에는 회사가 직접 공지한 사고와 소셜미디어 보고가 함께 들어 있어 확인 수준은 회사마다 다릅니다. 공통 표적은 저장된 환경 변수, 그중에서도 AI 모델 호출 키였습니다. 확인된 사례에서 공격자는 훔친 키를 30분 안에 시험해 보고, 여러 모델과 지역을 훑은 뒤 대량 호출로 과금을 일으켰습니다. 두 사례만으로 정가 기준 10만 달러 이상의 사용량이 나왔다고 추정했습니다. Chainstack도 외부 구성 요소를 통한 침입을 공지하며 노드 자격 증명과 플랫폼 API 키 교체를 안내했습니다. SecurityWeek 보도에 따르면 여러 회사가 이 공격들을 ARTEX 사용과 연결했습니다. ARTEX 흔적이 국내에서 어떻게 나왔는지는 ARTEX AI 흔적이 나온 은행 연쇄 해킹에 정리해 두었습니다.

왜 이용 기업의 문제인가

세 사고 모두 피해가 공급사 안에서 끝나지 않습니다.

우리 키가 남의 서버에 있다. 배포 플랫폼과 작업 실행 플랫폼에는 우리 데이터베이스 비밀번호, 결제 키, 클라우드 키, AI 서비스 키가 환경 변수로 들어 있습니다. 공급사가 뚫리면 그 키로 우리 시스템에 바로 들어올 수 있습니다.
피해는 상대 서비스에서 먼저 보인다. Northflank 사례에서 이상 징후는 AI 서비스의 무단 사용으로 드러났습니다. 공급사 공지보다 우리 클라우드 청구서나 AI 사용량 그래프가 먼저 알려 줄 수 있습니다.
원인 설명은 바뀐다. WorkOS는 첫 공개와 최종 설명이 달랐습니다. 원인이 공격자든 탈출한 에이전트든 이미 나간 정보는 같습니다. 대응을 원인 확정까지 미루지 않습니다.
키가 안 나가도 할 일은 있다. WorkOS처럼 연락처와 거래 맥락만 나간 경우, 다음 위험은 그 맥락을 쓴 정교한 사칭 메일과 결제 요청입니다.

우리 회사에 해당하는지 확인하는 법

먼저 공급사별로 '무엇이 나갔는지'를 공지 기준으로 가르고, 그다음 '우리가 거기에 무엇을 넣어 두었는지'를 봅니다.

쓰는 서비스	공지 기준 노출 범위	우리 쪽 판정
WorkOS	영업·지원 기록, 담당자 연락처	공지에 키 교체 안내는 없음. 담당자 대상 사칭·결제 요청 경계, 지원 대화에 붙여 넣은 비밀값이 있었다면 그 값은 교체
Northflank	컨트롤 플레인의 비밀값과 환경 변수	먼저 우리 계정이 공유 컨트롤 플레인인지 확인(포워드 배포·전용 컨트롤 플레인은 공지상 영향 없음). 해당하면 저장했던 비밀값 전부를 노출로 보고 교체, 연동 재연결
Trigger.dev	통지받은 환경의 API 키와 환경 변수	영향 통지 메일 수신 여부 확인. 받았으면 API 키 재발급과 해당 환경의 자격 증명 교체
같은 시기 사고를 공지한 다른 AI 개발 플랫폼	공급사마다 다름	각 공급사 공지를 직접 열어 같은 방식으로 판정

판정에 필요한 질문은 다섯 개입니다.

이 서비스를 누가, 어떤 계정으로 쓰고 있는가. 개발자 개인 계정으로 가입한 경우가 가장 놓치기 쉽습니다.
이 서비스에 넣어 둔 비밀값은 무엇인가. 환경 변수, 연동 토큰, 클라우드 역할, 웹훅 서명 키를 목록으로 뽑습니다.
각 비밀값이 열어 주는 곳은 어디인가. 데이터베이스, 결제, 클라우드, AI 서비스, 코드 저장소 중 어디로 이어지는지 적습니다.
공급사의 영향 통지를 받았는가. 가입 이메일이 퇴사자나 공용 메일함이라면 통지를 못 봤을 수 있습니다.
사고 기간에 그 키로 들어온 기록이 있는가. 판정은 공급사가 아니라 키를 받은 쪽 서비스의 로그로 합니다.

대응 순서

오늘

공급사 공지와 상태 페이지, 영향 통지 메일을 직접 확인한다. 기술 문의 메일함과 결제 담당 메일함까지 본다.
Northflank 공유 컨트롤 플레인을 썼다면 저장했던 비밀값을 교체한다(포워드 배포·전용 컨트롤 플레인 고객은 공지상 영향 없음). 순서는 돈과 데이터로 바로 이어지는 것부터다. 결제 키, 클라우드 자격 증명, 데이터베이스 비밀번호, AI 서비스 키, 개인 키 순으로 새로 발급하고 옛 값은 폐기한다.
Trigger.dev 영향 통지를 받았다면 API 키를 재발급하고, 해당 환경에 넣어 둔 데이터베이스 비밀번호와 외부 API 키, 접근 토큰을 바꾼다.
교체는 '새 값 발급, 배포 반영, 옛 값 폐기' 순서로 한다. 새 값을 넣지 않고 옛 값부터 끊으면 서비스가 멈추고, 새 값만 넣고 옛 값을 남기면 교체한 의미가 없다.
AI 서비스와 클라우드 콘솔에서 사용량과 청구 금액을 확인하고, 예산 한도와 알림을 건다.

이번 주

키를 받은 쪽 서비스의 접속 기록을 본다. Northflank는 10월 30일, Trigger.dev는 11월 1일 전후를 중심으로 처음 보는 IP, 평소와 다른 시간대, 짧은 시간의 대량 호출, 쓰지 않던 모델이나 지역 호출을 찾는다.
공급사 플랫폼의 감사 로그도 확인한다. Northflank는 10월 31일 감사 로그를 전체 사용자에게 켰다.
웹훅 서명 키는 공지에 따라 판단한다. Trigger.dev는 웹훅 서명 비밀값이 노출되지 않았다고 밝혔고, WorkOS 공지는 영향 범위를 영업·지원 시스템 데이터로 한정했다. 다른 서비스의 웹훅 서명 키(결제 대행사 등)를 Northflank 환경 변수에 넣어 두었다면 그 키는 교체 대상이다.
WorkOS를 쓴다면 영업·재무 담당자에게 사칭 주의를 알린다. 계좌 변경이나 계약 갱신 요청은 기존에 알던 연락처로 다시 확인한다.
교체 내역을 기록한다. 어떤 키를, 언제, 누가 바꿨고 옛 값을 폐기했는지 남겨야 다음 감사와 사고 보고에 쓸 수 있다.

이번 달

의존 SaaS 목록을 만든다. 서비스명, 담당자, 가입 계정, 넣어 둔 비밀값, 그 비밀값이 열어 주는 곳, 공급사 보안 공지 주소를 한 표로 관리한다. 외주 개발사와 협력사가 가입한 서비스도 포함한다.
장기 키를 줄인다. 공급사가 OIDC나 짧게 유효한 토큰, IP 허용 목록, 범위를 좁힌 키를 지원하면 그쪽으로 옮긴다. Trigger.dev는 이번 사고 뒤 두 기능을 내놓았다.
키마다 권한을 최소로 줄이고 예산 한도를 건다. 배포 플랫폼에 넣는 클라우드 키는 배포에 필요한 권한만 준다.
공급사 사고 대응을 사고 대응 절차에 넣는다. 통지 수신, 영향 판정, 교체, 로그 확인, 기록까지 담당자와 기한을 정한다. 공급망 전반의 점검 항목은 공급망 보안 체크리스트: 외주 개발사·SaaS·오픈소스로 뚫리는 루트에, 키 교체 순서의 다른 사례는 LiteLLM 1.107.0 공급망 공격 대응에 있다.
우리 쪽도 WorkOS의 네 가지 약점을 점검한다. 인터넷에 열린 내부 도구, 운영에 남은 개발용 자격 증명, 호출 횟수 제한 없는 API, 며칠씩 늦는 탐지가 우리에게도 있는지 본다.

자가점검

1. 회사가 쓰는 SaaS와 개발 플랫폼 목록이 한 곳에 있는가

개발자 개인 계정 가입과 협력사 계정까지 포함해야 합니다. 목록이 없으면 이번 같은 공지가 나와도 해당 여부를 가를 수 없습니다.

2. 각 서비스에 넣어 둔 비밀값을 지금 바로 뽑을 수 있는가

환경 변수, 연동 토큰, 클라우드 역할, 웹훅 서명 키가 대상입니다. 무엇을 넣었는지 모르면 교체 범위도 정할 수 없습니다.

3. 공급사 보안 통지가 실제로 읽히는 메일함으로 오는가

가입 이메일이 퇴사자나 아무도 보지 않는 공용 주소면 통지를 놓칩니다. Trigger.dev는 '통지를 받지 않았으면 해당 없음'이라고 안내했습니다.

4. 키 하나를 교체하는 데 몇 시간이 걸리는가

새 값 발급, 배포 반영, 옛 값 폐기를 한 번에 끝낼 절차와 담당자가 있어야 합니다. Wiz 분석에서 공격자는 훔친 키를 30분 안에 시험했습니다.

5. 키를 받은 쪽 서비스의 접속 기록과 청구 내역을 볼 수 있는가

데이터베이스, 클라우드, AI 서비스의 로그 보관 기간과 접근 권한을 확인합니다. 로그가 없으면 '쓰였는지'를 판정할 수 없습니다.

6. 클라우드와 AI 서비스 키에 예산 한도와 알림이 걸려 있는가

실제 호출을 막는 예산 한도를 걸어 두면 키가 새더라도 무단 사용 비용을 줄일 수 있습니다.

7. 장기 키 대신 짧게 유효한 토큰이나 IP 허용 목록을 쓸 수 있는가

공급사가 OIDC나 IP 제한을 지원한다면 옮길 일정을 정합니다.

8. 우리 내부 도구가 인터넷에 열려 있지 않은가

WorkOS 사고의 출발점은 인터넷에 열려 있던 공급사의 내부 영업 도구였습니다. 우리 내부 도구도 인터넷에 노출돼 있다면 인증·접근 통제와 접속 기록부터 확인합니다.

공급사 사고 영향과 우리 쪽 노출을 함께 확인하려면

보안 전문 기업 SENTRIX는 레드팀 운영과 보안 실무 10년 경험으로 이런 사고의 영향 판정과 대응을 돕습니다. 수상 이력은 2025 식약처 주최 AI 레드팀 챌린지 최우수상(구성원)입니다. 공급사 침해로 키가 새어 나갔을 가능성이 있다면 침해사고 대응으로 교체 순서와 접속 기록 확인을 함께 정합니다. WorkOS가 꼽은 약점처럼 우리 웹·API에 열린 내부 도구나 권한 문제가 있는지는 AI 자동화와 전문가 검증을 묶은 AI 심화 취약점 진단으로 권한·비즈니스 로직·연쇄 공격 경로를 확인할 수 있고, 인터넷에 공개된 우리 회사 웹사이트·서버는 외부 노출·위험 관리(ASM)로 찾아 담당자·조치·재확인까지 관리합니다. 공급사 공지를 받고 무엇부터 바꿀지 막막하다면 지금 진단 문의하기로 상황을 알려 주십시오.

참고 자료

공급사 침해 영향, 지금 함께 판정하기

긴급 보안 대응이 필요하면 즉시 연락하세요.

진단 문의하기