AI 코딩 에이전트의 설정 파일 신뢰 결함은 에이전트가 시작 시점에 읽어들이는 설정 파일의 출처와 권한을 검증하지 않아, 제3자가 심어둔 설정이 내 권한으로 로드되는 결함이다.
올해 NVD에 등재된 AI 코딩 CLI 도구 CVE 2건이 같은 지점에서 성립한다. 공격 입력이 소스코드가 아니라 설정 파일이라, 제안된 코드를 읽어보고 승인하는 습관으로는 걸러지지 않는다. 도구 허용목록·버전 고정 같은 조직 정책은 이미 표준 권고다(관련 글 참조). 이 글이 다루는 두 건은 그 정책을 지켜도 남는 층, 즉 에이전트가 시작할 때 읽는 파일의 출처·권한 문제다.
이 글은 자주 발생하는 실수 패턴, 점검·조치 절차, 자가진단을 정리했다.
한눈에 보는 핵심
Q. 승인 프롬프트를 꼼꼼히 보면 막을 수 있나요? A. 두 건 모두 승인 단계보다 앞에서 성립합니다. CVE-2026-35603은 머신 전역 기본 설정을 로드하는 시점의 결함이라, 공격자가 심어둔 설정이 도구 실행과 함께 자동으로 로드됩니다(벤더는 이를 로컬 권한 상승으로 분류). CVE-2026-12537은 NVD 설명대로 샌드박스 적용 전의 호스트 레벨 코드 실행입니다. Q. PC를 혼자 쓰는데도 해당되나요? A. CVE-2026-35603은 공유 다중 사용자 Windows와 설정이 심긴 뒤의 도구 실행이 악용 전제라, 단독 PC면 해당하지 않습니다. CVE-2026-12537은 NVD가 CVSS 4.0 10.0 CRITICAL과 CVSS 3.1 7.8 HIGH를 함께 등재했고 공격 벡터 평가가 네트워크(4.0)와 로컬(3.1)로 갈립니다. 어느 쪽이든 악용 무대는 헤드리스 CI이고, 저장소에 심긴 설정 파일로 성립하므로 공용 빌드 서버가 해당합니다. Q. 남의 저장소는 에이전트로 열면 안 되나요? A. 문제는 여는 행위가 아니라 저장소 안 설정 파일을 신뢰 입력으로 취급하는 기본값입니다. 벤더 어드바이저리는 헤드리스(CI) 환경에서 워크스페이스 폴더를 자동 신뢰한 것을 원인으로 밝히고, 완화책으로 폴더 신뢰와 도구 허용목록을 제시합니다. 전체 허용 모드가 세분화된 도구 허용목록을 무시하던 문제도 같은 문서에서 함께 정정됐습니다.자주 발생하는 실수 패턴
| # | 패턴 | 위험도 |
|---|---|---|
| 1 | ProgramData 하위 도구 폴더를 미리 만들지 않아 비관리자가 선점 가능 | 높음 |
| 2 | 헤드리스 CI에서 외부 기여자가 트리거하는 이벤트로 에이전트 실행 | 치명 |
| 3 | 워크스페이스 폴더 자동 신뢰 기본값을 외부 저장소에도 적용 | 치명 |
| 4 | 전체 허용 모드로 돌려 세분화된 도구 허용목록이 무시됨 | 치명 |
| 5 | .env를 유출 위험(읽히는 것)으로만 보고, 실행 입력(에이전트가 읽어 동작이 바뀌는 것)으로는 안 봄 | 높음 |
| 6 | AI 코딩 CLI를 수동 업데이트로만 운영 — CVE 수정 버전 미반영 | 높음 |
권한 교정 스크립트
# 관리자 PowerShell — 전역 설정 폴더를 선점하고 쓰기를 잠근다
# CVE-2026-35603의 원인은 이 폴더가 사전 생성·접근제한되지 않은 것이었다
# $dir에는 아래 자가진단 1단계에서 찾아낸 폴더 경로를 넣는다
$dir = 'C:\ProgramData\<1단계에서 찾은 폴더>'
New-Item -ItemType Directory -Path $dir -Force | Out-Null
icacls $dir /setowner 'BUILTIN\Administrators'
# /inheritance:r 을 단독 선행하면 DACL이 비는 구간이 생긴다 — grant와 한 번에 적용
icacls $dir /inheritance:r /grant:r 'BUILTIN\Administrators:(OI)(CI)F' 'NT AUTHORITY\SYSTEM:(OI)(CI)F' 'BUILTIN\Users:(OI)(CI)RX'
icacls $dir # Users에 (W)·(M)·(F)가 없어야 정상
Get-ChildItem $dir -Force # 남이 심어둔 설정 파일이 있는지결함이 생성된 코드가 아니라 도구가 시작 시 읽는 입력에 있을 때는 코드 리뷰·승인 습관이 방어선이 되지 못한다.
방어는 파일시스템 권한과 실행 트리거 쪽에 둬야 한다.
자가진단
# [관리자 PowerShell] 1) ProgramData 하위에 일반 사용자가 쓸 수 있는 폴더가 있는가
# 한글 Windows는 계정 표시가 현지화되므로 SID도 함께 매칭한다
Get-ChildItem C:\ProgramData -Directory | ForEach-Object { icacls $_.FullName } |
Select-String '(Users|Everyone|S-1-5-32-545|S-1-1-0).*\((M|F|W|GW|GA)\)'
# 2) 설치된 AI 코딩 CLI·CI Action이 수정 버전 이상인가
# 영향 받는 패키지명과 수정 버전은 아래 NVD 원문(및 거기 링크된 벤더 어드바이저리)에 적혀 있다
# 본인이 쓰는 도구와 직접 대조할 것 — 숫자만 보고 다른 도구에 대입하지 말 것
# https://nvd.nist.gov/vuln/detail/CVE-2026-35603
# https://nvd.nist.gov/vuln/detail/CVE-2026-12537
# [관리자 PowerShell] 3) 남의 저장소를 에이전트로 열기 '전'에 설정 파일 확인
Get-ChildItem -Force -Depth 2 | Where-Object { $_.Name -like '.*' }
# [관리자 PowerShell] 4) CI가 외부 기여자 트리거로 에이전트를 돌리는가
Select-String -Path .github\workflows\* -Pattern 'pull_request_target|issue_comment|workflow_run'
# [Git Bash·Linux CI] 3)~4) 동일 점검
ls -a
find . -maxdepth 2 -name '.env*' -o -maxdepth 2 -type d -name '.*'
grep -rnE 'pull_request_target|issue_comment|workflow_run' .github/workflows/위 시그널이 발견되면 결함이다. NVD — CVE-2026-35603 원문(설정 로드 시 디렉터리 소유권·권한 미검증)를 함께 참조하라.
조치 절차
| 순위 | 조치 |
|---|---|
| 1 | 설치된 AI 코딩 CLI·CI Action 버전을 NVD·벤더 어드바이저리 원문에 적힌 수정 버전과 직접 대조 — 미달이면 즉시 업데이트 |
| 2 | ProgramData 하위 도구 폴더를 관리자 소유로 선점·잠금, 이미 있던 설정 파일은 확인 후 제거 |
| 3 | 헤드리스 CI 워크플로에서 외부 기여자 트리거를 끊고, 워크스페이스 신뢰는 신뢰하는 입력에만 환경변수로 명시적으로 켠다. 전체 허용 모드 대신 허용 도구를 명시 |
| 4 | 신뢰하지 않는 저장소는 켜기 전에 설정 디렉터리와 .env 확인 — 켜고 나서 보면 이미 로드된 뒤다 |
| 5 | 공유 PC·공용 빌드 서버에서 에이전트를 쓰던 기간의 API 키·토큰을 로테이트 |
| 6 | 운영 중인 웹서비스의 외부 노출 점검은 별건 — 개발 머신·CI 하드닝과 따로 관리한다 |
지금 해야 할 것
실무자: 설치된 도구 버전을 NVD·벤더 어드바이저리 원문의 수정 버전과 직접 대조하고, 공유 PC·공용 빌드 서버의 설정 폴더 권한을 교정하라. 이 점검은 그 머신에 접근 가능한 사람이 직접 해야 한다.