단일 git push로 도달한 GitHub 백엔드, 그리고 폐쇄형 바이너리를 48시간 만에 깬 AI X-Stat 헤더 인젝션 · 크로스 테넌트 코드 실행 · IDA MCP 기반 블랙박스 분석 · GHES 88%의 패치 지연

문서 정보

항목 내용
리포트 ID CTI-2026-0503-GITHUB
분류 (Classification) TLP:GREEN — 대외 공유 가능
유형 (Type) Column / Threat Brief
심각도 (Severity) 🔴HIGH — 글로벌 개발자 생태계 단일 점 실패 위험
대상 산업 (Target Sector) 클라우드 코드 호스팅 · DevSecOps · 소프트웨어 공급망
CVE CVE-2026-3854 (CVSS v3.1: 8.7 / High)
취약점 분류 (CWE) CWE-77 — Improper Neutralization of Special Elements
제보 일자 2026-03-04 (Wiz Research → GitHub)
공개 일자 2026-04-28 (Coordinated Disclosure)
작성일 (Publication) 2026년 5월 3일
발행 (Publisher) Dennis Kim — CYBER-THREAT-INTELLIGENCE-REPORT

목차

  1. 경영진 요약
  2. 사건 개요
  3. 공격 체인의 기술적 해부
  4. AI가 바꾼 취약점 탐지의 패러다임
  5. 영향 범위와 잔존 리스크 — GHES 88%의 의미
  6. 침해 지표 및 감사 권고
  7. 대응 권고사항
  8. Web3·국내 산업 관점
  9. 결론 — 인간과 AI의 비대칭이 시작됐다
  10. 참고 문헌

1.요약 (Executive Summary)

2026년 4월 28일, 클라우드 보안 기업 Wiz가 GitHub의 내부 git 인프라에서 발견한 임계 취약점 CVE-2026-3854가 공식 공개되었다. 이 결함은 저장소에 push 권한을 가진 인증된 사용자라면 누구든 단 한 번의 git push -o 명령으로 GitHub 백엔드 서버에서 임의의 명령을 실행(RCE)할 수 있게 했다. CVSS 8.7점(High)을 기록한 이 취약점의 공격 표면은 모든 git 클라이언트로 확장되며, 별도의 멀웨어·피싱·권한 토큰을 필요로 하지 않았다.

본 사건은 두 가지 측면에서 단순한 RCE 취약점 이상의 의미를 지닌다.

첫째, 취약점의 본질이 GitHub 내부 서비스 간 신뢰 경계의 구조적 결함에 있었다는 점이다. 사용자 입력값이 단 한 차례의 정제 없이 내부 메타데이터 헤더(X-Stat)에 삽입되었고, 세미콜론(;)이라는 단일 구분 문자가 권한 상승·샌드박스 우회·임의 명령 실행으로 이어지는 3단계 인젝션 체인을 가능케 했다.

둘째, 본 취약점이 AI 기반 리버스 엔지니어링으로 발견된 최초의 임계 취약점 중 하나라는 점이다. Wiz Research는 IDA MCP를 활용하여 GitHub의 폐쇄형 바이너리를 자동 분석했고, 통상 수개월이 소요되는 분석을 단 48시간 만에 완료했다. 이는 취약점 탐지의 경제성을 근본적으로 재정의하는 사건이다.

핵심 판단 (Key Judgments)

# 판단 신뢰도
KJ-1 본 취약점은 멀티서비스 아키텍처에서 '신뢰된 내부 프로토콜'이 사용자 입력의 변형 경로가 될 때 발생하는 전형적 구조 결함이다. 높음(High)
KJ-2 GitHub.com은 6시간 이내 패치되어 사실상 영향이 차단되었으나, 자체 호스팅(GHES) 환경의 88%가 공개 시점에 여전히 취약 상태였다. 이 골든 타임은 공격자에게 매력적이다. 높음
KJ-3 AI 기반 폐쇄형 바이너리 분석은 더 이상 실험 단계가 아니다. 본 사건 이후 동일 기법이 Vercel·Cloudflare·기타 폐쇄형 SaaS 인프라로 확산할 가능성이 높다. 중간(Medium)
KJ-4 취약점 발견 자체는 방어자에게 유리한 결과로 끝났으나, 공격자 진영도 동일 도구를 보유하고 있다는 점에서 '비대칭성'은 양방향이 아닌공격자 우위로 기울고 있다. 중간
KJ-5 한국 정부·기업의 GHES 사용 비율을 고려할 때, 국내 자체 호스팅 인스턴스에 대한 즉각 패치 점검이 필요하다. 특히 방산·금융·공공 코드 저장 환경이 우선순위다. 높음

2. 사건 개요

2.1 취약점 메타데이터

항목 값
CVE ID CVE-2026-3854
CVSS v3.1 8.7 (High)
CWE CWE-77 (Improper Neutralization of Special Elements)
영향 컴포넌트 babeld (GitHub 내부 git 프록시)
공격 전제 조건 저장소에 push 권한을 가진 인증된 사용자
공격 복잡도 Low — 단일 git push 명령으로 트리거
영향 GitHub.com: 공유 스토리지 노드 RCE, 크로스 테넌트 데이터 노출 / GHES: 풀 서버 컴프로마이즈

2.2 핵심 타임라인

일시 (UTC) 이벤트
2026-03-04 Wiz Research, X-Stat 푸시 옵션 인젝션 취약점 발견 및 GHES 3.19.1에서 RCE 검증. 같은 날 GitHub에 제보.
2026-03-04 (당일) GitHub, 제보 접수 후 검증 완료. GitHub.com에 긴급 패치 배포(보고에 따라 75분 ~ 6시간 사이).
2026-03-10 CVE-2026-3854 할당 (CVSS 8.7). GHES용 패치 릴리스.
2026-04-28 Wiz의 공식 블로그 및 GitHub 자문 동시 공개. The Hacker News·Dark Reading 등 주요 매체 보도.
2026-04-28 시점 Wiz 스캔 결과 인터넷 노출 GHES 인스턴스의88%가 미패치 상태.

3. 공격 체인의 기술적 해부

3.1 X-Stat 헤더 — 신뢰 경계의 균열

GitHub의 git 처리 파이프라인은 다중 서비스로 구성되어 있다. 사용자가 git push를 실행하면 요청은 SSH 데몬을 거쳐 내부 프록시 babeld로 전달되며, babeld는 X-Stat라는 내부 헤더를 구성하여 다운스트림 서비스에 전달한다. 이 헤더는 보안 정책 결정에 사용되는 메타데이터(저장소 유형, 처리 환경, 훅 디렉터리 경로 등)를 세미콜론(;)으로 구분된 키-값 쌍으로 직렬화한다.

문제의 본질은 단순했다. 사용자가 git push -o key=value 형태로 전달한 push option 값이 세미콜론 정제 없이 X-Stat 헤더에 그대로 삽입되었다. 게다가 헤더 파서는 동일 키가 중복될 경우 last-write-wins(마지막 값 우선) 로직을 사용했다. 즉 사용자가 직접 보안 결정 필드를 덮어쓸 수 있었다.

3.2 3단계 인젝션 체인

Wiz Research는 다음과 같은 세 단계의 필드 주입을 체이닝하여 RCE를 달성했다.

단계 인젝션 대상 필드 효과
① 샌드박스 우회 rails_env 프로덕션 샌드박스 제약을 무력화. 정상적으로는 hook 실행이 제한된 환경.
② 훅 디렉토리 리디렉션 custom_hooks_dir 공격자가 제어 가능한 경로로 훅 디렉토리 변경.
③ 임의 바이너리 실행 repo_pre_receive_hooks + 경로 탐색 git 서비스 사용자 권한으로 공격자 바이너리 실행. RCE 달성.

3.3 폭발 반경(Blast Radius)

  • GHES (자체 호스팅)— git 사용자로서 샌드박스 외부 코드 실행. 파일시스템 읽기/쓰기, 내부 서비스 구성 가시성 확보.풀 서버 컴프로마이즈.-GitHub.com (클라우드)— enterprise 플래그가 X-Stat에 함께 전달되는 구조였기에, 동일한 인젝션 메커니즘으로 클라우드 환경에서도 RCE 달성. 게다가 GitHub의 멀티 테넌트 아키텍처와 공유 백엔드 인프라 특성상,공유 스토리지 노드 점거를 통해 다른 조직·사용자의 수백만 개 저장소에 접근 가능한 상태에 도달했다(Wiz 측은 제3자 데이터에 일절 접근하지 않았음을 명시).

본질적 교훈: 본 취약점은 어느 한 컴포넌트의 단독 결함이 아니다. babeld는 사용자 입력을 그대로 임베드해도 안전하다고 가정했고, 다운스트림 파서는 헤더의 모든 필드가 합법적 출처에서 왔다고 가정했으며, pre-receive 훅은 특정 환경 변수가 프로덕션에서 단일 값만 가진다고 가정했다. 개별로는 합리적인 가정들이 합쳐져 시스템 전체의 신뢰 경계를 무너뜨렸다.

4. AI가 바꾼 취약점 탐지의 패러다임

4.1 폐쇄형 바이너리 + AI = 새로운 공격 표면 가시화

본 취약점 발견에서 가장 주목할 부분은 기술적 결함 자체가 아니라 발견 방법론이다. Wiz Research는 GitHub의 컴파일된 폐쇄형 바이너리(특히 babeld)를 분석하기 위해 IDA MCP기반 자동 리버스 엔지니어링을 활용했다. 통상적으로 이 정도 규모의 폐쇄형 멀티서비스 프로토콜을 인간 분석가가 재구축하려면 수개월~1년 단위의 작업이 필요하다. Wiz는 이를단 48시간에 완료했다고 공개했다.

이 사건은 본 CTI 아카이브가 CTI-2026-0422-MCP 리포트에서 다룬 MCP 기반 도구의 양면성과 정확히 같은 축에 위치한다. MCP는 방어자에게는 폐쇄형 시스템의 가시성을 열어주는 강력한 도구이지만, 공격자에게도 동일한 가시성을 제공한다.

4.2 Anthropic Mythos와의 시점적 일치

본 공개(2026-04-28)는 Anthropic이 Claude Mythos Preview를 공개한 시점(2026-04-07)과 약 3주의 시차를 둔다. Mythos는 자체 평가에서 OS·웹 브라우저 전반에 걸친 수천 건의 미공개 제로데이를 식별했으며, FreeBSD NFS의 17년 묵은 RCE 결함(CVE-2026-4747)을 자율적으로 발견·익스플로잇한 것으로 알려져 있다. Anthropic은 일반 공개를 보류하고 산업 컨소시엄 'Project Glasswing'을 통해 제한적으로 운영 중이다.

항목 CVE-2026-3854 (GitHub) Mythos 공개 시점
분석 대상 폐쇄형 멀티서비스 바이너리 OS·브라우저 코드베이스
AI 활용 IDA MCP + AI 보조 리버스 엔지니어링 범용 LLM의 자율 취약점 탐지
결과 단일 임계 취약점 식별 다수 제로데이 식별
공통점 AI가 인간 분석가의 시간 비용을 한 자릿수로 압축

이 두 사건이 같은 달에 공개된 것은 우연이 아니다. 2026년 2분기는 'AI 보조 취약점 발견'이 실증된 분기로 기록될 것이다.

4.3 비대칭성의 새로운 균형

방어자의 관점에서 AI 기반 취약점 탐지는 이중적 함의를 가진다.

측면 방어자에게 공격자에게
속도 사전 예방적 감사 가능, 패치 사이클 단축 익스플로잇 개발 시간 압축
접근성 인하우스 보안팀이 폐쇄형 의존성 검증 가능 진입 장벽 하락, n-day 익스플로잇 양산
규모 코드베이스 전수 스캐닝 자동화 무차별 표적 탐색
귀결 발견 → 보고 → 패치 (책임 공시 모델) 발견 → 비축 → 판매 (제로데이 시장)

표면적으로는 양측 모두 같은 도구를 갖는 것처럼 보이지만, 공격자는 단 하나의 익스플로잇만 성공시키면 되고, 방어자는 모든 가능성을 차단해야 한다는 비대칭은 그대로 유지된다. AI는 이 비대칭의 양 측면을 동시에 증폭시킨다.

5. 영향 범위와 잔존 리스크 — GHES 88%의 의미

GitHub.com은 제보 접수 후 수 시간 내에 패치되어 클라우드 사용자 측에서는 추가 조치가 필요 없다. 그러나 자체 호스팅 GitHub Enterprise Server(GHES)환경은 전혀 다른 이야기다. Wiz의 공개 시점 스캔에 따르면 인터넷 노출 GHES 인스턴스의약 88%가 여전히 취약 버전을 운영 중이었다.

5.1 패치 적용 버전

Wiz 공식 블로그 기준 패치된 GHES 버전은 다음과 같다. 이 이하 버전은 즉시 업그레이드가 요구된다.

GHES 3.14.24 이상
GHES 3.15.19 이상
GHES 3.16.15 이상
GHES 3.17.12 이상
GHES 3.18.6  이상
GHES 3.19.3  이상

⚠ 워크어라운드는 존재하지 않는다. 패치 외에 임시 완화책(WAF 룰, 프록시 차단 등)으로 본 취약점을 차단하는 신뢰할 만한 방법은 공개된 바 없다.

5.2 한국 환경의 잠재 노출

본 리포트 작성 시점 기준 국내 GHES 사용 현황에 대한 공식 통계는 부재하나, 다음 영역에서 GHES가 광범위하게 사용되는 것으로 알려져 있다:

영역 위험 시나리오
방산·국방 SI 공급망 코드·빌드 산출물 유출 가능. 무기체계 소프트웨어 컴파일 환경 침해 시 후속 영향 막대.
금융권 (시중은행·증권사) 금융감독원 전자금융감독규정상 자체 호스팅 코드 저장소 비중 높음. 거래·결제 시스템 코드 노출 위험.
공공기관 행정안전부·과기정통부 산하 일부 기관 GHES 운영. 클라우드 도입 지연 영역에서 패치 사이클이 느림.
대기업 R&D 자동차·반도체·바이오 R&D 코드는 본질적으로 영업비밀 자산.
Web3 프로젝트 스마트 컨트랙트 사전 배포 코드, 키 관리 모듈 등이 비공개 GHES에 보관되는 경우 존재.

권고: 국가정보원·과학기술정보통신부 산하 기관, KISA, 금융보안원은 본 CVE에 대해 자체 호스팅 GHES 운영 기관 대상 일제 점검 공문 발송을 검토할 가치가 있다.

6. 침해 지표 및 감사 권고 (IoC & Audit)

본 CVE는 권한을 가진 인증 사용자가 트리거하므로, 전통적 IoC(IP·도메인·해시)보다는 로그 패턴 기반 탐지가 핵심이다.

6.1 GitHub 권고 감사 절차

GitHub Enterprise Server 관리자는 다음을 즉시 점검해야 한다.

항목 점검 명령/위치
감사 로그 검토 /var/log/github-audit.log 내 push option 값에 비정상 특수문자(;, \n, 경로 탐색 시퀀스) 포함 여부 확인
비정상 코드 경로 호출 정상 운영에서 사용되지 않는 내부 코드 경로 트리거 흔적 확인 (GitHub은 자체 텔레메트리에서 모든 이상 호출이 Wiz 연구진 테스트와 일치함을 확인)
신규 hook 디렉토리 사용자 정의 훅 디렉토리(custom_hooks_dir) 비정상 변경 이력 확인
pre-receive 훅 변경 최근 7-30일간 pre-receive 훅 스크립트 변경 이력 및 권한 변경

6.2 MITRE ATT&CK 매핑

ATT&CK ID Tactic / Technique 본 사건 적용
T1078.004 Valid Accounts: Cloud Accounts 정상 인증 사용자의 push 권한 활용
T1059 Command and Scripting Interpreter 임의 명령 실행
T1574 Hijack Execution Flow hook 디렉토리 리디렉션
T1480 Execution Guardrails rails_env 조작으로 샌드박스 가드레일 우회
T1611 Escape to Host (해당 시) 컨테이너/샌드박스 외부 실행
T1530 Data from Cloud Storage Object 공유 스토리지 노드 접근 (GitHub.com 시나리오)

7. 대응 권고사항

본 권고는 우선순위(P0=즉시, P1=24시간, P2=7일) 기반이다.

7.1 P0 (즉시 조치)

# 조치 대상
P0-1 GHES 즉시 패치 — 위 §5.1의 버전으로 업그레이드 GHES 관리자
P0-2 감사 로그 검토 — push option에 세미콜론 포함된 이력 검색 GHES 관리자
P0-3 인터넷 노출 GHES 인스턴스 임시 격리 — 패치 적용까지 외부 접근 차단 또는 IP 제한 보안팀
P0-4 pre-receive 훅 무결성 검증 — 변조 의심 시 클린 백업으로 복원 DevOps

7.2 P1 (24시간 내)

# 조치
P1-1 모든 push 권한 토큰(PAT, Deploy Key) 로테이션 검토
P1-2 CI/CD 파이프라인에서 GHES 배포 의존성 점검 — 패치 미적용 GHES → 프로덕션으로 이어지는 경로 식별
P1-3 git push option 사용 정책 수립 — 정상 업무에서 push option을 사용하지 않는 경우 GHES에서 비활성화 검토
P1-4 사고 대응팀 비상 대기 — 향후 30일간 GHES 관련 추가 폭로 모니터링

7.3 P2 (7일 내, 구조적 개선)

# 조치
P2-1 폐쇄형 의존성 SaaS 인벤토리 — 본 사건과 유사한 멀티서비스 폐쇄형 시스템 의존도 평가
P2-2 AI 기반 보안 감사 도입 검토 — IDA MCP·SemGrep·CodeQL·자체 LLM 파이프라인 등
P2-3 멀티서비스 신뢰 경계 재설계 — 내부 헤더 프로토콜의 입력 검증·구분자 인코딩 표준화
P2-4 비상 패치 절차 문서화 — '6시간 클라우드 패치, 88% 자체 호스팅 미패치'의 격차를 자체 환경에 적용해 보는 도상훈련

8. Web3·국내 산업 관점

8.1 Web3 프로젝트의 비대칭 노출

Web3 프로젝트는 일반적으로 다음 두 가지 이유로 본 CVE에 대한 노출이 평균보다 높다.

  1. 자체 호스팅 선호 — 키 관리·서명 모듈 등 보안 민감 코드를 외부 클라우드에 두지 않으려는 경향이 강하며, 이는 GHES·GitLab Self-Hosted 의존도 상승으로 이어진다.
  2. CI/CD를 통한 컨트랙트 배포— pre-receive 훅이 컴파일·배포·서명까지 자동화한 워크플로우는, 훅 단계에서의 RCE가 곧배포 파이프라인 변조로 직결된다.

특히 다음과 같은 시나리오가 가능하다:

시나리오 결과
GHES pre-receive 훅 변조로 컨트랙트 컴파일러 옵션 조작 백도어 삽입된 바이트코드 배포
빌드 환경에서 deployer 키 노출 멀티시그가 아닌 EOA 배포 환경 즉시 탈취
프런트엔드 빌드 산출물 변조 DApp 사용자 트랜잭션 서명을 공격자 주소로 리다이렉트 (BadgerDAO 2021 사건과 유사)

이는 CTI-2026-0420-VERCEL 리포트에서 다룬 'Web3 프런트엔드 공급망 공격면'과 정확히 같은 축의 위협이다. 코드 호스팅(GitHub) → 빌드 파이프라인(CI/CD) → 배포 인프라(Vercel) → 사용자 지갑으로 이어지는 체인은 어느 한 노드의 침해만으로도 사용자 자산 탈취로 직결된다.

8.2 국내 권고

대상 권고
DAXA 회원 거래소 자체 GHES 운영 시 즉시 패치. 외주 개발사·아웃소싱 파트너의 GHES 패치 상태 확인.
국내 Web3 발행사 컨트랙트 저장소·키 관리 코드의 호스팅 환경 식별 및 패치 검증.
방산·국방 SI 무기체계·국방 R&D 코드 저장 GHES 즉시 점검. 국방사이버안보훈령 기반 의무 보고 검토.
금융보안원·KISA GHES 사용 금융기관·핀테크 대상 일제 점검 공지 발행 검토.

9. 결론 — 인간과 AI의 비대칭이 시작됐다

CVE-2026-3854는 단 하나의 세미콜론이 글로벌 코드 호스팅 플랫폼을 흔든 사건이다. 그러나 본 칼럼이 주목하는 것은 결함의 단순함이 아니라, 그것을 발견한 방법의 단순함이다.

수년 전이라면 GitHub의 폐쇄형 multi-service 바이너리를 분석하여 X-Stat 헤더의 인젝션 가능성을 식별하는 작업은 적어도 수 개월의 노력을 요구했을 것이다. 보상이 보장되지 않는 한, 이런 작업에 인적 자원을 투입할 수 있는 보안 연구팀은 전 세계적으로 손에 꼽힐 정도였다. 그러나 IDA MCP와 AI 보조 도구는 이 비용을 48시간으로 압축했다. 이는 단순한 효율 개선이 아니라, '폐쇄형 소스의 보안 감사'라는 카테고리 자체의 경제성을 재정의하는 변화다.

이 변화는 세 가지 함의를 가진다.

첫째, 폐쇄형이 곧 안전을 의미하지 않는다.Security through obscurity는 더 이상 작동하지 않는다. AI는 폐쇄형 바이너리의 구조적 결함을 인간보다 빠르게, 더 적은 비용으로 가시화한다. 이는 자체 SaaS·내부 프로토콜·전용 프로토콜을 운영하는 모든 조직에 동일하게 적용된다.둘째, 신뢰 경계를 모든 컴포넌트 단위에서 재설계해야 한다."내부 트래픽이니 안전하다"는 가정은 단일 인젝션 포인트로 무너진다. Zero Trust는 사용자·장치 차원을 넘어서비스 간 프로토콜 수준으로 확장되어야 한다. 모든 내부 헤더, 모든 메타데이터, 모든 구분자는 잠재적 공격 표면이다.

셋째, 패치 속도와 적용 속도의 격차는 그 자체로 위협이다.GitHub.com의 6시간 패치는 모범 사례지만, GHES의 88% 미패치율은 현실이다. 본 CVE 같은 임계 결함이 공개된 시점부터 모든 환경이 패치되기까지의 기간은 공격자에게 가장 매력적인 골든 타임이다. 이 격차를 줄이는 것은 기술의 문제가 아니라거버넌스의 문제다. CISO·CIO·정부 규제기관이 풀어야 할 과제다.

본 칼럼의 최종 판단: AI는 방어자와 공격자에게 동일한 능력을 부여하지만, 공격자가 단 하나의 성공으로 충분하다는 비대칭을 증폭시키는 방향으로 더 빠르게 움직인다. 본 CVE는 그 비대칭이 본격화한 첫 임계 사례로 기록될 것이다. 다음 사례는 6개월 안에 등장한다고 보는 것이 합리적이다. 방어자는 그 전에 자체 환경의 폐쇄형 의존성을 AI로 먼저 감사할 의무가 있다.

10. 참고 문헌

본 칼럼은 2026년 4월 28일 공개된 1차 자료와 전문 보안 매체의 2차 자료를 교차 검증하여 작성되었다.

10.1 1차 자료

  1. Wiz Research Blog, "GitHub RCE Vulnerability: CVE-2026-3854 Breakdown". https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854
  2. GitHub Security Advisory, CVE-2026-3854 — Internal X-Stat header injection (2026-04-28).
  3. Sagi Tzadik (@sagitz_) on X, "We achieved Remote Code Execution on GitHub..." (2026-04-28). https://twitter.com/sagitz_
  4. Anthropic, "Project Glasswing: Securing critical software for the AI era". https://www.anthropic.com/glasswing

10.2 2차 보도 및 분석

  1. The Hacker News, "Researchers Discover Critical GitHub CVE-2026-3854 RCE Flaw Exploitable via Single Git Push". https://thehackernews.com/2026/04/researchers-discover-critical-github.html
  2. Cyber Express, "CVE-2026-3854 RCE Flaw In GitHub Enterprise Server". https://thecyberexpress.com/cve-2026-3854-rce-github-enterprise-server/
  3. Cyber Unit, "GitHub RCE Vulnerability CVE-2026-3854: What the Git Push Flaw Means for Canadian and US Businesses". https://cyberunit.com/insights/github-rce-vulnerability-cve-2026-3854-business-impact/
  4. Expert Insights, "GitHub Exploit Exposed Millions Of Public And Private Repositories, Wiz Finds". https://expertinsights.com/news/wiz-discloses-github-flaw-cve-2026-3854
  5. Cybersecurity News, "Critical GitHub.com and Enterprise Server RCE Vulnerability Enables Full Server Compromise". https://cybersecuritynews.com/github-com-and-enterprise-server-rce/
  6. Secure.com, "GitHub RCE Flaw Exposed Millions of Repositories". https://www.secure.com/news/github-rce-vulnerability-cve-2026-3854

10.3 AI 취약점 탐지 배경

  1. Anthropic, "Claude Mythos Preview" 발표 (2026-04-07).
  2. AI Security Institute (UK), "Our evaluation of Claude Mythos Preview's cyber capabilities". https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities
  3. Dark Reading, "Anthropic's Mythos Has Landed: Here's What Comes Next for Cyber". https://www.darkreading.com/cybersecurity-operations/anthropic-mythos-cyber-what-comes-next
  4. Intel 471, "How Much Does Anthropic's Mythos Change Enterprise Security?". https://www.intel471.com/blog/how-much-does-anthropics-mythos-change-enterprise-security
  5. ArmorCode, "Anthropic's Claude Mythos and What it Means for Security". https://www.armorcode.com/blog/anthropics-claude-mythos-and-what-it-means-for-security
  6. AISLE, "AI Cybersecurity After Mythos: The Jagged Frontier". https://aisle.com/blog/ai-cybersecurity-after-mythos-the-jagged-frontier
  7. CETaS (Alan Turing Institute), "Claude Mythos: What Does Anthropic's New Model Mean for the Future of Cybersecurity?". https://cetas.turing.ac.uk/publications/claude-mythos-future-cybersecurity

10.4 본 CTI 아카이브 관련 리포트

  1. CTI-2026-0422-MCP — MCP를 노리는 지능형 공격, 잠복형 공격
  2. CTI-2026-0420-VERCEL — Vercel 보안 침해 사건 분석

— 칼럼 끝 (End of Column) —

© 2026 Dennis Kim github.com/gameworkerkim/CYBER-THREAT-INTELLIGENCE-REPORT

본 칼럼은 공개된 정보에 기반한 독립적 분석으로, GitHub Inc., Wiz Inc., Anthropic 및 관련 조직의 공식 입장과 무관합니다.

TLP:GREEN · CTI-2026-0503-GITHUB · Published: 2026-05-03

"오늘 폐쇄형 바이너리를 48시간에 분석한 도구는, 내일 같은 시간에 익스플로잇을 만들어낼 것이다." — CTI-2026-0503