브레보 CDN 엣지 조작으로 10만 개 이상 사이트에 악성 스크립트 주입
2026년 9월 14일과 9월 16일, 불과 이틀 간격으로 발생한 두 건의 공급망 공격은 평범한 웹 접속 환경과 기업 개발 파이프라인이 얼마나 쉽게 무너질 수 있는지를 여실히 드러냈다. 첫 번째 사건에서 공격자는 마케팅 자동화 플랫폼 브레보(Brevo)의 소스 코드에 하드코딩된 클라우드플레어(Cloudflare) API 키를 탈취해 약 10만 개 이상의 고객 사이트에 악성 'ClickFix' 소셜 엔지니어링 스크립트를 주입했다. 두 번째 사건에서는 과거 'Mini Shai-Hulud' 캠페인으로 이미 손상되었던 두 개의 깃허브 액션(GitHub Actions) 워크플로우 저장소가 격리 이후에도 살아남아 재활성화됐다.
두 사건이 공통으로 가리키는 결론은 하나다. 엣지 단에서의 조작과 이미 감염된 CI/CD 구성 요소의 재활성화만으로도 대규모 공급망 사고가 얼마든지 재현된다. 브레보 사건은 구조적 보안 결함이 어떻게 대규모 피해로 이어지는지를 단계별로 보여준다.
공격자는 브레보 애플리케이션 소스에 포함된 클라우드플레어 API 키를 탈취했다. 이 키는 전체 계정 권한을 보유한 것으로 확인됐으며(Rescana, 2026년 9월 보도), 공격자는 이를 이용해 악성 워커(Worker)를 배포하고 CDN 엣지 응답을 재작성했다. 원본 서버와 파일 자체는 수정되지 않았다.
조작은 오직 CDN 엣지에서만 이루어졌다. 워커가 활성화된 시간은 약 5시간 29분이었으며, 고객 삽입 자바스크립트와 sibforms.com은 UTC 기준 16시 07분부터 20시 30분까지 영향을 받았다(Rescana, 2026년 9월 보도).
브레보 측은 앱·API·이메일 발송·고객 계정 데이터는 영향받지 않았다고 사후 발표했지만, CDN 엣지 수준에서 삽입된 악성 스크립트는 수십만 건의 사용자 접속을 오염시켰을 가능성이 크다.
광고
영향 규모와 노출 시간을 고려하면 단순 기술 사고로 치부하기 어렵다. 이 사건은 세 가지 구조적 논점을 선명하게 부각시킨다.
CDN 엣지는 콘텐츠 제공과 보안이 겹치는 지점으로, 엣지 단에 권한을 가진 키 하나가 탈취되면 하위 수십만 사이트 전체가 위협에 놓인다. CI/CD 파이프라인의 손상된 구성 요소는 격리 이후에도 '잠재적 시한폭탄'으로 남을 수 있다. 그리고 현재의 업계 관행과 규제 체계는 이러한 재발성 위험을 충분히 통제하지 못한다.
2026년 9월 16일 재발한 깃허브 액션 저장소 사건은 이 두 번째 논점을 구체적으로 증명했다. 이미 5월 'Mini Shai-Hulud' 캠페인에서 손상된 두 개의 저장소가 격리 조치 이후에도 온라인 상태로 남아 있다가, UTC+2 기준 오전 11시 9분부터 오후 6시 16분 사이에 다시 활성화되어 악성 코드를 실행했다(The Hacker News, 2026년 9월 보도).
해당 워크플로우는 CI/CD 환경에서 민감한 자격증명을 수집해 공격자 제어 서버로 유출하도록 설계되어 있었다. 공격자는 새로운 인프라를 전혀 구축하지 않았다.
기존 저장소의 태그 또는 워크플로우 활성화만으로 동일한 피해를 재현할 수 있다는 점이 이 사건의 핵심 위험이다. 전문가들은 변동 가능한 태그(mutable tag) 대신 SHA 고정(SHA pinning)을 적용해 상위 저장소의 상태 변화에 대한 의존성을 제거할 것을 권고했다.
이 권고는 단순한 설정 변경을 넘어 코드 재사용 관행과 패키지 관리 방식 전반의 재검토를 요구한다.
재활성화된 GitHub Actions가 CI/CD 자격증명 유출을 다시 촉발
일반 사용자의 관점에서 브레보 사건의 영향은 '신뢰하던 웹사이트에서 위험한 경험을 하게 된다'는 점이다. 마케팅 자동화 플랫폼에 의존하는 소규모 사업자는 자신도 모르는 사이에 고객 페이지를 통해 악성 링크나 피싱 시나리오를 전파하는 경로가 될 수 있다.
광고
기업 보안 담당자는 CDN 엣지에서의 위협을 기존 웹서버·데이터베이스 중심 위협 모델에 반드시 추가해야 한다. 개발팀은 CI/CD 파이프라인 설정을 점검해야 하며, 특히 9월 16일 사례처럼 이미 손상된 워크플로우가 격리 이후 재활성화되는 시나리오에 대비해야 한다. 한국 중소기업 상당수가 외부 마케팅 플랫폼과 공유형 CI/CD 도구에 의존하는 현실에서, 이들 구성 요소 중 하나가 침해되면 연쇄 피해가 발생할 수 있다는 점은 국내 기업들이 외면해서는 안 될 과제다.
일부에서는 이번 사건을 특정 업체의 운영 미숙으로 한정하고, 공급망 전체 문제로 일반화하는 것을 경계하기도 한다. 그러나 이 반론은 구조적 요인을 간과한다.
브레보 사건의 핵심은 하드코딩된 전체 권한 API 키가 소스 코드에 존재했다는 설계상 오류이며, 깃허브 액션 재활성화는 소프트웨어 배포·태그 관리 관행 자체의 취약점을 파고든 것이다. 개별 사례의 기술적 세부 사항을 문제 삼는 것은 필요하지만, 하드코딩·변동 태그·광범위 권한 부여라는 현재 업계 관행이 동일한 사고를 반복적으로 유발할 수 있다는 점을 외면해서는 안 된다.
본지 확인 결과 일부 기업은 여전히 장기 토큰을 코드 저장소에 남겨두는 관행을 유지하고 있어, 동일 유형의 사고가 재발할 위험이 실질적으로 존재한다. 이번 사건은 세 가지 정책적 변화를 요구한다.
첫째, 클라우드 API 키와 같은 민감 정보의 하드코딩을 금지하고 자동 탐지 규정을 도입해야 한다. 둘째, 저장소 태그 관리 기준을 표준화하고 SHA 고정(SHA pinning)을 의무화해야 한다.
셋째, CDN 제공자와 마케팅 플랫폼을 포함한 제3자 서비스에 대한 공급망 보안 감사를 의무화하고 사고 보고 체계를 강화해야 한다.
광고
국제적으로 소프트웨어 공급망 안전성에 관한 규제가 빠르게 확산되는 상황에서, 한국은 관련 가이드라인과 신고 체계를 조속히 정비해야 한다. 기술적 대응으로는 키 수명 단축, 권한 분리, 워크플로우 비활성화 시 자동 격리, CI/CD 시크릿 스캐닝 도구 도입 등을 고려할 수 있다. 이들 조치는 비용과 조직적 변화를 수반하지만, 반복적 재발을 막는 데 필수적이다.
일상 서비스·기업 보안과 정책이 바뀌어야 하는 이유
2026년 9월 14일과 9월 16일의 사건은 단순한 해킹 뉴스를 넘어 한국의 디지털 일상과 개발 관행을 재검토할 기회를 제공한다. CDN 엣지에서의 조작과 이미 감염된 워크플로우의 재활성화는 기술적 약점이 곧 사회적 위험으로 연결된다는 점을 분명히 보여줬다.
기업과 정책 당국은 이 사건을 계기로 외부 의존성 관리, 태그·토큰 정책, 사고 보고 체계를 실질적으로 재설계해야 한다. 우리가 일상적으로 접속하는 웹과 기업의 개발 파이프라인 어디에 보이지 않는 '잠재적 취약점'이 숨어 있는지, 지금 당장 점검을 시작해야 한다. ※ 이 기사는 Rescana의 2026년 9월 보도 및 The Hacker News의 2026년 9월 보도를 참조하여 작성하였다.
FAQ
Q. 일반 사용자는 이번 사건으로 어떤 피해를 입을 수 있는가
A. 일반 사용자는 평소 신뢰하던 사이트에 접속했다가 피싱이나 소셜 엔지니어링을 통해 개인 정보 또는 로그인 자격증명을 탈취당할 수 있다. 브레보 사건에서는 약 10만 개 이상의 고객 사이트에 악성 스크립트가 삽입되어, 방문자가 의도치 않게 악성 행위에 노출됐다. 피해는 원본 서버가 아닌 CDN 엣지에서 발생했기 때문에 사이트 운영자조차 이상을 즉각 감지하기 어렵다. 개인 사용자는 브라우저와 보안 솔루션을 최신 상태로 유지하고, 팝업이나 예상치 못한 링크를 클릭하지 않는 기본 수칙을 준수해야 한다. 의심스러운 화면이 나타나면 즉시 해당 사이트를 이탈하고 비밀번호 변경 여부를 검토하는 것이 바람직하다.
Q. 개발자나 보안 담당자는 당장 무엇을 점검해야 하는가
A. 개발자는 코드 저장소 전반에 걸쳐 하드코딩된 API 키·토큰의 존재 여부를 우선적으로 점검해야 한다. CI/CD 파이프라인에서는 변동 가능한 태그 대신 SHA 고정(SHA pinning)을 적용해 상위 저장소 상태 변화에 대한 의존성을 제거하는 것이 효과적이다. 깃허브 액션 등 워크플로우의 활성화 로그를 주기적으로 검토하고, 더 이상 사용하지 않는 저장소는 즉시 비공개 또는 삭제 처리해야 한다. 시크릿 스캐닝 도구 도입, 단기 토큰 사용, 최소 권한 원칙 적용은 재발 위험을 실질적으로 낮추는 조치다. 보안 감사를 정기화하고, 제3자 서비스에 부여된 권한 범위도 주기적으로 재검토해야 한다.
Q. 브레보 같은 마케팅 플랫폼을 사용하는 기업은 어떤 조치를 취해야 하는가
A. 외부 마케팅 플랫폼에 의존하는 기업은 해당 플랫폼이 배포하는 자바스크립트 파일의 무결성을 주기적으로 검증해야 한다. 서브리소스 무결성(SRI, Subresource Integrity) 속성을 활용하면 외부 스크립트가 변조되었을 때 브라우저 단에서 실행을 차단할 수 있다. 제3자 서비스와의 계약 시 보안 사고 발생 시 통보 의무와 대응 절차를 명문화하고, 공급망 보안 감사를 정기 감사 항목에 포함해야 한다. 특히 소규모 기업일수록 외부 플랫폼 침해가 자사 고객에게 직접 영향을 미친다는 점을 인식하고, 플랫폼 선택 단계부터 보안 역량을 검토 기준에 반영해야 한다.
광고
){kind=small}
){kind=small}
){kind=small}
){kind=small}