패치만으로는 해결할 수 없는 2026년의 4가지 신뢰 실패 사례 (AUR, PAN-OS, Cisco SD-WAN, PeopleSoft)

이번 봄의 모든 기조 연설은 우리에게 동일한 이야기를 했습니다. AI가 취약점 공개와 무기화 사이의 간극을 압축했으므로, 해결책은 더 빠르게 패치하는 것이라는 점입니다. 좋습니다. 하지만 지난 몇 주 동안 실제로 악용된 사례들을 다시 살펴보니, 가장 심각한 사례들 대부분은 여러분이 얼마나 빨리 패치하느냐에는 관심조차 없었습니다. 버그들은 영리하지 않았습니다. 그것들은 신뢰 가정(trust assumptions)과 무결성 검사(integrity checks)의 누락이었으며, 이는 여러분 중 절반이 코드를 작성하기 시작하기 전부터 이미 CWE 카테고리로 명명되어 있던 것들입니다. 여기 그중 네 가지에 대한 메커니즘과 오늘 바로 실행할 수 있는 탐지 방법이 있습니다.

신뢰 모델이 공격 표면이다 (AUR, CVE 없음)

6월 11일경, 누군가가 Arch User Repository (AUR)에 있는 버려진 패키지 더미를 채택하고, 빌드 레시피(build recipes)를 수정하여 이를 자격 증명 탈취기(credential stealers)로 탈바꿈시켰습니다. 정리가 진행되는 동안 커뮤니티 목록에는 400개 이상의 확인된 사례와 그 이상의 사례가 보고되었습니다. 제로데이(zero-day)도 없었고 Arch 자체 인프라의 침해도 없었습니다. 공식 저장소(official repos)는 전혀 건드려지지 않았습니다.

메커니즘은 모욕적일 정도입니다. 공격자는 PKGBUILD와 .install 파일을 수정하여 빌드 중에 npm을 호출하고, 악성 패키지(atomic-lockfile)를 가져온 뒤, SSH 키, 토큰, 브라우저 데이터, 클라우드 자격 증명(cloud creds), 그리고 메시징 세션을 수집하는 기능이 제거된 Rust 바이너리를 떨어뜨렸습니다. 두 번째 파동에서는 첫 번째의 서명을 피하기 위해 npm 대신 bun을 사용했습니다. 악용된 것은 AUR의 신뢰 모델이었습니다. AUR은 현재 누가 유지 관리하느냐보다 패키지의 _이름과 이력(name and history)_을 더 신뢰하며, 버려진 패키지를 채택하는 것은 허용된 프로세스입니다. 아무도 침입하지 않았습니다. 그들은 시스템이 설계상 열어둔 문을 통해 걸어 들어왔을 뿐입니다.

Arch를 사용 중이라면 분류(Triage)하십시오:

# 설치 날짜별 외부 (AUR) 패키지 -- 6월 11일 이후에 수정된 것은 모두 의심 대상입니다
pacman -Qqm | while read pkg; do
  pacman -Qi "$pkg" | grep -E "^(Name|Install Date)" | paste - -
...

초기 보도에서 잘못 짚은 미묘한 차이 하나는 다음과 같습니다. eBPF 루트킷(rootkit)은 선택 사항이며, 루트 권한(root-only, CAP_BPF 필요)에서만 작동하고 권한 상승(privilege escalation)을 수행하지는 않습니다. 이는 단지 사후에 스틸러(stealer)를 숨길 뿐입니다. 하지만 이는 정리(cleanup) 계산법을 바꿉니다. 만약 페이로드(payload)가 루트 권한으로 실행되었다면, pacman -R로는 시스템을 정리할 수 없습니다. 패키지 관리자(package manager)는 자신이 알고 있는 파일만 삭제하며, 루트킷의 존재 목적 자체가 자신이 알려지지 않는 것에 있기 때문입니다. 깨끗한 미디어(clean media)로 재구축하거나, 해당 호스트를 신뢰하지 마십시오.

CVE-2026-0257: 복호화할 수 있는 모든 쿠키를 신뢰하는 방화벽 (PAN-OS)

이것은 보안 장비가 존재 목적 그 자체에서 실패한 사례입니다. GlobalProtect 포털은 사용자가 계속해서 재인증(re-auth)하지 않도록 암호화된 "인증 오버라이드(authentication override)" 쿠키를 발행합니다. 쿠키가 다시 돌아오면, PAN-OS는 자신의 개인 키(private key)로 이를 복호화한 후, 서명(signature)을 검증하지 않고 그 내용을 신뢰합니다. 이 취약점의 CWE는 565로, 무결성 검사(integrity checking) 없는 쿠키에 대한 의존성입니다.

해당 장비의 HTTPS 서비스에 동일한 인증서가 재사용되는 경우 상황은 더 악화됩니다. 이는 특이한 설정이 아닌 흔한 구성입니다. 공격자는 HTTPS를 통해 연결하여 공개 키(public key)를 가져온 뒤, 방화벽이 절대적인 진리로 받아들일 쿠키를 위조합니다. Rapid7은 5월 17일에 공격이 시작된 것을 확인했습니다. Palo Alto는 CISA가 이를 KEV(Known Exploited Vulnerabilities)에 추가한 날인 5월 29일에 CVSS 점수를 4.7에서 7.8로 조용히 상향 조정했습니다.

다음 두 가지 조건이 모두 충족될 때만 노출됩니다: 포털 또는 게이트웨이에서 인증 오버라이드 쿠키가 활성화되어 있고, 쿠키 암호화 인증서가 다른 서비스와 공유되는 경우입니다. 오버라이드 설정은 Network > GlobalProtect > Portals/Gateways > Agent > Authentication에서 확인하십시오. 완화 방법(Mitigation)은 인증 오버라이드를 비활성화하거나, 오직 쿠키 암호화만을 위해 사용되며 다른 곳에는 공유되지 않는 인증서를 생성하는 것입니다. Prisma Access 또한 영향 목록에 포함되었으나, Panorama와 Cloud NGFW는 포함되지 않았습니다.

PoC(Proof of Concept)의 흔적을 찾기 위해 GlobalProtect 로그를 조사하십시오:

# 공개 PoC에서 발견된 위조된 쿠키(Forged-cookie) 세션의 특징:
#   - 저가형 호스팅 IP(Vultr 등)로부터 로컬 관리자 계정으로의 쿠키 인증
#   - 도메인 필드가 비어 있는(EMPTY) 소스 사용자
...

CVE-2026-20182: 인증 단계가 인증을 수행하지 않는 컨트롤 플레인 (Cisco SD-WAN)

이 사례는 수개월간 지속된 패턴이며, Cisco가 이를 겪고 있습니다. 4월 20일, CISA KEV 목록에는 인증되지 않은 접근으로 체이닝(chaining)되는 세 가지 Catalyst SD-WAN Manager 결함이 등재되었습니다: CVE-2026-20122 (권한 있는 API의 잘못된 사용), CVE-2026-20128 (비밀번호를 복구 가능한 형식으로 저장), 그리고 CVE-2026-20133 (민감 정보 노출)입니다. 그 후 5월 14일, 헤드라인을 장식했어야 할 사건이 발생했습니다: CVE-2026-20182, CVSS 10.0으로, 피어링 인증(peering-authentication) 단계가 단순히 인증을 수행하지 않는(CWE-287) SD-WAN 컨트롤 플레인(control plane)의 인증 우회(authentication bypass) 취약점입니다. Cisco가 UAT-8616으로 추적 중인 정교한 공격자가 이를 제로데이(zero-day)로 공격했습니다. CISA는 이에 대해 긴급 지침(Emergency Directive) 26-03을 발행했으며, PoC 코드가 유포되자 연구자들은 약 10개의 추가적인 클러스터가 결합되는 것을 확인했습니다. 6월에는 인증된 공격자가 장비 내의 모든 파일을 덮어쓸 수 있는 경로 탐색(path traversal, CVE-2026-20262)을 포함하여 두 건이 더 추가되었습니다.

이 장비는 전체 패브릭(fabric)에 설정을 푸시하는 컨트롤러로, 네트워크에서 가장 높은 권한을 가진 단일 장비입니다. 그런데 지난 몇 달 동안 복구 가능한 비밀번호 저장, 정보 유출, 경로 탐색, 그리고 인증을 수행하지 않는 컨트롤 플레인 인증 메커니즘이 연달아 배포되었습니다. 20182 취약점을 악용한 후, UAT-8616은 vmanage-admin 계정에 공격자 키를 주입했고, 그 후 NETCONF(TCP 830 상의 SSH)를 통해 로그인하여 명령을 실행하기 시작했습니다.

# SD-WAN 컨트롤 구성 요소에서 공격자 키 주입 흔적을 찾으십시오:
grep "Accepted publickey for vmanage-admin" /var/log/auth.log

...

CVE-2026-35273: 실제로 해결하기 어려웠던 사례 (PeopleSoft)

공정한 평가를 하자면, 이것은 진정한 제로데이 (zero-day) 공격이었습니다. ShinyHunters (Mandiant는 이들을 UNC6240으로 추적함)는 5월 말부터 6월 초까지 PeopleTools 8.61 및 8.62의 환경 관리 (Environment Management) 구성 요소에 존재하는 인증되지 않은 RCE (unauthenticated RCE)인 CVE-2026-35273을 통해 Oracle PeopleSoft를 파고들었습니다. 이 취약점의 점수는 9.8로 평가되었습니다. Mandiant는 공격 시점을 5월 27일부터 6월 9일 사이로 파악했습니다. Oracle의 긴급 보안 권고 (out-of-band advisory)는 6월 10일이 되어서야 발표되었으며, 즉 전체 공격 캠페인이 패치할 수 있는 수단이 존재하기도 전에 이미 실행되었습니다. Mandiant는 100개 이상의 조직에 통보했으며, 그중 68%가 고등 교육 기관이었습니다. CISA는 6월 12일에 이를 KEV (Known Exploited Vulnerabilities) 목록에 등재했습니다.

공격 이후, 공격자들은 Azure 서비스로 위장한 MeshCentral 에이전트 (C2 주소: azurenetfiles[.]net)를 설치하고, 측면 이동 (lateral-movement) 및 변조 (defacement)를 위한 *_fanout.sh 스크립트를 실행했으며, zstd를 사용하여 데이터를 유출했습니다.

# PeopleSoft 웹/앱 디렉토리에 남겨진 침해 흔적:
find / -name "README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT" 2>/dev/null

...

패턴: 잘못된 가설은 패치로 해결할 수 없다

이제 실제 논거가 될 거시적인 관점을 살펴보겠습니다. Verizon의 2026 DBIR에 따르면, 알려진 취약점 (known-exploited vulnerability)을 해결하는 데 걸리는 중앙값 시간이 전년 대비 32일에서 43일로 증가했으며, 완전히 패치된 비율은 38%에서 26%로 감소했습니다. Rapid7의 2026년 보고서는 높음(high) 및 심각(critical) 등급의 결함에 대한 확인된 공격 사례가 105% 급증(71건에서 146건)했다고 기록했습니다. 또한 CSA와 Zero Day Clock이 이제는 몇 시간 단위로 측정하는 '취약점 공개에서 무기화까지의 시간' (disclosure-to-weaponization window)은 과거에는 몇 주가 걸리곤 했습니다. 공격은 압축되고, 복구는 확장되고 있습니다. 그리고 그렇습니다, AI가 발견 및 무기화 단계를 압축했습니다. 이 부분은 엄연한 사실입니다.

하지만 이 네 가지 사례에서 공격자들이 얻은 이득을 보십시오. 이 중 어느 것도 근본적인 문제는 속도의 문제가 아니었습니다. 시스템이 그 이름이 좋다는 이유로 신뢰하는 패키지, 복호화할 수 있는 모든 쿠키를 신뢰하는 방화벽, 인증 단계에서 인증을 수행하지 않는 제어 평면 (Control Plane), 또는 인터넷에 그대로 노출된 ERP 엔드포인트(Endpoint)는 패치만으로는 해결할 수 없습니다. 그리고 이 중 두 가지 사례인 Cisco의 10.0과 PeopleSoft RCE의 경우, 공격자들은 패치가 존재하기도 전에 이미 내부 침투를 완료한 상태였습니다. 벤더(Vendor)가 인지하기도 전에 이미 시작된 시계(Clock)를 패치 속도로 앞지를 수는 없습니다.

"더 빠르게 패치하라"는 말은 틀린 말이라기보다 논점에서 벗어난 말입니다. 이것들은 우리가 출시하기로 동의했던 설계 결함 (Design failures)이었으며, 상류 (Upstream) 단계의 잘못된 가정 (Assumption)을 하류 (Downstream) 단계의 아무리 빠른 수정으로도 고칠 수는 없습니다. 보안 취약점 노출 시간 (Window)은 붕괴되었습니다. 그 틈을 타고 들어온 버그들은 그 시간이 필요하지도 않았습니다.

당신이 신뢰하라고 안내받은 제품 중에서 여전히 발견되는 최악의 기본 신뢰 (Trust-by-default) 사례는 무엇입니까? 사례를 알려주세요.

원문은 blog.vertexops.org에 게시되었습니다.