무엇이 바뀌었고, 공식으로 확인된 사실은 무엇인가
Cisco는 2026년 9월 16일 16:00 GMT에 보안 권고 cisco-sa-ISE-ABP-VNSW7Tn5를 냈다. 대상은 Cisco Identity Services Engine(ISE)과 ISE Passive Identity Connector(ISE-PIC)의 API다. 분류는 CWE-648(권한 있는 API의 잘못된 사용), 버그 ID는 CSCww39530이다.
공격 조건이 느슨하다. 관리자 계정, 사용자 클릭, 특정 정책 설정이 필요 없다. Cisco는 장비 설정과 관계없이 영향받는다고 적었다. 공격자는 취약한 API 엔드포인트에 조작된 요청을 보내는 방식으로 웹 기반 관리 인터페이스를 건너뛸 수 있다.
발견 경로는 연구자 제보가 아니라 Cisco TAC 지원 사례를 처리하는 과정이었다. PSIRT는 이 취약점이 실제로 악용되고 있다는 점을 인지했다고 밝혔다. 공격 주체, 최초 침해 시점, 피해 조직 수, 사용된 백도어 종류는 공개하지 않았다.
같은 날 미국 CISA는 KEV 카탈로그에 CVE-2026-76460을 추가했다. NVD에 정리된 연방기관 조치 기한은 2026년 9월 19일이다. 랜섬웨어 연계 여부는 Unknown이다. BOD 26-04에 따라 패치뿐 아니라, 패치 전에 이미 침해당했는지 확인하는 포렌식 점검이 요구된다. 한국 공공·민간 기관에 같은 기한이 법적으로 적용되지는 않는다. 다만 최고 점수, 실제 악용, 3일 기한은 우선순위를 정할 때 참고할 신호다.
같은 시기 ISE에는 CVE-2026-20192, CVE-2026-76423처럼 접근 통제·인증 우회 계열의 다른 결함도 패치됐다. 캐나다 사이버보안센터(AL26-021, 9월 17일)는 세 건을 묶어 안내하되, 실제 악용이 확인된 항목은 CVE-2026-76460이라고 구분했다. 이 글의 우선순위도 그 구분과 같다.
팩트체크
| 항목 | 내용 |
|---|---|
| 현재 판정 | 사실 — 취약점 존재, 패치 공개, 실제 악용은 Cisco·CISA가 공식 확인 |
| 원출처 | Cisco 권고 cisco-sa-ISE-ABP-VNSW7Tn5(2026-09-16), CVE-2026-76460, CISA KEV(2026-09-16) |
| 확인된 부분 | 인증 불필요, API 인증 통제 부족, 웹 관리 화면 우회, 설정과 무관, 우회책 없음, root 명령 실행 가능, 수정 패치 공개, TAC 사례에서 발견 |
| 미확인 부분 | 공격 주체, 정확한 피해 규모, 한국 내 침해 여부, 랜섬웨어 연계, 인터넷에 노출된 ISE 대수 |
| 협력·규제 기관 | CISA 연방 기한 9월 19일, 포렌식 점검 요구. 캐나다 사이버보안센터는 9월 17일 주의보 |
| 혼동 주의 | 사흘 전 공개된 Cisco Secure Email Gateway CVE-2026-76461과 CVE 번호는 이어지지만, 제품·공격면은 다르다 |
ISE가 뚫리면 일반 서버 침해와 무엇이 다른가
Cisco ISE는 유선·무선·VPN에 붙는 사용자와 기기를 확인하고, 얼마나 들어가게 할지 정하는 네트워크 접근 제어(NAC) 플랫폼이다. 방화벽이 ‘어디를 막을지’를 다룬다면, ISE는 ‘누가, 어떤 기기로, 어디까지 붙을지’를 다룬다.

관리 평면이 장악되면 공격자는 인증 정책, 권한 프로파일, 게스트·BYOD 규칙, 기기 프로파일, 보안 그룹 태그 같은 결정을 바꿀 수 있다. 그 결과는 단일 서버 침해보다 넓다. 이미 네트워크에 붙어 있는 단말의 이동 범위를 넓히거나, 차단해야 할 기기를 통과시킬 수 있기 때문이다.
Cisco는 성공 시 공격자가 root 권한으로 명령을 실행할 수 있다고 적었다. root가 있으면 장비 안 로그와 침해 흔적을 지우거나 숨기는 일이 가능하다. 그래서 장비 안 access.log만 보고 ‘이상 없음’으로 끝내면 안 된다. 권고도 방화벽·네트워크 등 장비 바깥 로그를 교차 확인하라고 못 박았다.
누구에게 필요한가. ISE 또는 ISE-PIC를 온프레미스로 운영하는 보안·네트워크 팀, 캠퍼스 NAC를 외주받은 MSP, 공공·금융처럼 단말 접근 통제를 직접 두는 조직이다. 굳이 필요 없는 경우는 가정용 공유기와 클라우드 SaaS만 쓰는 개인, Microsoft 365·Google Workspace만 쓰고 ISE가 없는 소규모 사업장이다. 다만 회사 와이파이·VPN이 어떤 NAC를 거치는지는 IT에 한 번은 확인하는 편이 낫다.
영향 제품과 올려야 하는 버전
영향 제품은 Cisco ISE와 ISE-PIC다. Cisco는 설정과 관계없이 영향받는다고 명시했다. 관리 포트를 인터넷에 열어 두지 않았어도, 공격자가 그 API에 도달할 수 있는 경로가 있으면 조건은 충족된다.
3.0은 소프트웨어 유지보수가 끝난 상태다. Cisco는 수정이 들어 있는 지원 버전으로 이전하라고 안내했다. 3.1과 3.2는 치명 결함 위주 수정만 이어지는 구간이므로, 가능하면 3.3 Patch 12, 3.4 Patch 7, 3.5 Patch 4처럼 지원이 살아있는 계열로 옮기는 편이 이후 대응에도 유리하다. 이 판단은 Cisco가 같은 주 권고에서 구버전 유지보수 범위를 좁혀 둔 점을 따른 것이다.
수정 버전
| 현재 릴리스 | 첫 수정 버전 | 비고 |
|---|---|---|
| 3.0 및 그 이전 | 지원 버전으로 이전 | 3.0은 유지보수 종료 |
| 3.1 | 3.1 Patch 12 | 치명 수정 위주 유지 |
| 3.2 | 3.2 Patch 11 | 치명 수정 위주 유지 |
| 3.3 | 3.3 Patch 12 | 지원 계열 |
| 3.4 | 3.4 Patch 7 | 지원 계열 |
| 3.5 | 3.5 Patch 4 | 지원 계열 |

우회 설정은 없다. 웹 관리 계정을 바꾸거나 정책을 조이는 것만으로는 이 결함을 막지 못한다. Cisco가 제시한 임시 완화는 인프라 ACL(iACL)로 관리·컨트롤 플레인 트래픽만 허용하는 것이다. 패치 창을 여는 동안 노출면을 줄이는 용도이지, 패치를 대체하지는 않는다.
사용 중인지, 이미 들어왔는지 확인하는 순서
패치 설치만으로 끝내지 말라는 점이 이번 권고의 핵심이다. CISA도 KEV 등재와 함께 패치 전 침해 여부를 보라고 했다. 아래 순서는 Cisco가 공개한 점검 방법을 실무 순서로 재배열한 것이다.
1. 우리 네트워크가 ISE를 쓰는지 먼저 본다
자산 목록, RADIUS/TACACS+ 서버 주소, 무선 컨트롤러·스위치의 인증 서버 설정, 벤더 유지보수 계약서에서 Identity Services Engine / ISE-PIC를 찾는다. 외주 MSP가 운영하면 버전과 패치 일정을 서면으로 받는다. 장비가 없다면 이 CVE는 직접 대상이 아니다.
2. 현재 버전을 수정 버전과 대조한다
관리 화면 또는 CLI에서 ISE 릴리스와 패치 번호를 확인한다. 위 표의 첫 수정 버전보다 낮으면 취약 후보다. 분산 구축이면 노드마다 버전이 다를 수 있으니 Primary만 보지 않는다.
3. access.log에서 수상한 사용자명을 찾는다
Cisco는 시도·성공 여부를 보려면 access.log를 보고 수상한 사용자명을 찾으라고 했다. 분산 구축이면 모든 노드 로그를 본다. 권고에 나온 예시 명령은 admin#show logging application ise-kong/access.log | include dummyuser다. 추가 로그는 디버그 로그를 포함한 지원 번들을 받은 뒤 ./ise/logs/apigateway/access.log..gz를 확인한다. 출력이 있으면 악성 활동 가능성으로 본다. 이 예시의 dummyuser는 검색 패턴 설명이지, 실제 공격자 계정명이 확정된 것은 아니다.

4. 장비 바깥 로그로 교차 확인한다
Cisco는 root 권한 때문에 장비 안 증거가 지워질 수 있다고 경고했다. 방화벽, 네트워크 장비, 프록시에서 ISE 노드가 외부 IP로 보낸 예상 밖 업로드, 악성으로 분류된 주소에서의 다운로드를 찾는다. 관리 대역으로 들어오는 비정상 API 트래픽도 같이 본다.
5. 침해가 의심되면 패치만 하지 말고 노드를 다시 깐다
Cisco는 악성 활동이 의심되면 해당 노드를 재이미징하고, 필요하면 구성 백업으로 복원하라고 강하게 권고했다. 이미 root를 내준 장비에 패치만 올리면, 남아 있는 계정·백도어·변조된 정책을 그대로 둘 수 있다. 재설치 뒤에는 백업 시점이 침해 이전인지부터 검증한다.
지금 당장 판단할 일, 그리고 흔한 실수
가정용 PC나 스마트폰을 쓰는 개인이 Windows 업데이트를 켜는 수준의 조치는 아니다. 판단의 주체는 ISE를 소유하거나 위탁 운영하는 조직이다.
지금 할 일부터 정리하면 이렇다. ISE 존재 여부를 확인하고, 인터넷 또는 광역 관리망에서 API에 닿는지 본다. 취약 버전이면 패치 창을 연다. 그 전에 iACL로 관리 트래픽을 제한한다. 패치와 동시에 로그 점검을 시작한다. 수상한 흔적이 있으면 재이미징을 패치보다 앞에 둔다.
흔한 실수는 네 가지다. 첫째, 관리 웹페이지를 사내에만 열어 두었으니 안전하다고 보는 것이다. 이번 결함은 로그인 화면이 아니라 API 인증 통제다. 둘째, Primary 노드만 올리고 서비스 노드를 남는 것이다. 셋째, 장비 안 로그가 깨끗하니 침해가 없다고 단정하는 것이다. 넷째, 같은 주 Cisco 이메일 게이트웨이 취약점과 한 건으로 묶어 담당자를 잘못 지정하는 것이다. 메일 관문과 NAC 정책 엔진은 운영 팀이 다른 경우가 많다.
패치 이후에도 정책이 갑자기 넓어졌는지, 새로 생긴 관리 계정은 없는지, 게스트 포털·VPN 인증 흐름이 바뀌지 않았는지는 별도로 본다. ISE가 네트워크의 출입 규칙을 들고 있기 때문이다.
확인 시점과 남는 불확실성
이 글의 버전·점수·악용 여부는 2026년 9월 20일 기준으로 Cisco 권고 1.0(Final), NVD, CISA KEV, 캐나다 사이버보안센터 주의보를 대조한 결과다. 공격 주체와 국내 피해는 공식 자료에 없다. 패치 번호는 이후 추가 릴리스가 나올 수 있으니, 적용 직전 공식 권고의 Fixed Software 표를 한 번 더 여는 것이 맞다.
자주 묻는 질문
집에 있는 공유기나 회사 노트북만 쓰면 조치해야 하나?
직접 대상은 아니다. Cisco ISE 또는 ISE-PIC를 운영하는 조직의 문제다. 회사 와이파이나 VPN이 ISE를 거치는지는 보안팀에 확인하면 된다.
관리 페이지를 인터넷에 안 열었으면 안전한가?
그것만으로 안전하다고 단정할 수 없다. Cisco는 설정과 관계없이 영향받는다고 적었다. API에 네트워크로 도달할 수 있으면 조건은 성립한다. iACL은 완화일 뿐 패치를 대체하지 않는다.
패치만 올리면 충분한가?
버전이 취약했고 관리면이 노출돼 있었다면 부족하다. Cisco는 root 권한으로 흔적을 지울 수 있다고 경고했고, 의심 시 재이미징을 권고했다. CISA도 패치 전 침해 여부를 보라고 했다.