FortiClient EMS 사전 인증 우회가 드러낸 VPN·NAC 보안 경계

Fortinet FortiClient EMS에서 인증 전 API 접근을 우회할 수 있는 CVE-2026-35616이 제로데이 악용과 함께 공개됐다. Django 미들웨어가 Apache mod_ssl의 WSGI 환경 변수와 공격자가 조작한 HTTP 헤더를 같은 방식으로 신뢰하면서, 인증되지 않은 원격 공격자가 내부 API 엔드포인트에 접근해 임의 코드 또는 명령을 실행할 수 있는 구조다. CISA는 2026년 4월 6일 이 취약점을 KEV(Known Exploited Vulnerabilities) 목록에 넣고 연방 기관에 72시간 내 패치를 명령했다.

취약점 범위와 악용 정황

CVE-2026-35616은 FortiClient EMS 7.4.5~7.4.6에 영향을 주는 부적절한 접근 제어(CWE-284) 취약점이다. 조작된 요청으로 인증 절차를 통과하면 원격의 비인증 공격자가 임의 코드 또는 명령 실행에 도달할 수 있으며, CVSS 3.1 점수는 9.1(Critical)이다.

항목	내용
CVE ID	CVE-2026-35616
CVSS 점수	9.1 (Critical)
CWE	CWE-284 (Improper Access Control)
영향 버전	FortiClient EMS 7.4.5, 7.4.6
취약점 유형	Pre-authentication API bypass
제로데이 여부	예 (야생 악용 확인)
발견자	Simo Kohonen (Defused Cyber), Nguyen Duc Anh
CISA KEV 등재	2026년 4월 6일

2026년 3월 31일 watchTowr 허니팟은 최초 악용 시도를 포착했다. 이후 Defused Cyber가 실제 제로데이 악용을 공식 확인했다. 같은 시기에는 FortiClient EMS 7.4.4의 사전 인증 SQL 인젝션인 CVE-2026-21643(CVSS 9.1)도 활발히 악용 중이었다.

프록시와 Django 사이에서 무너진 인증 경계

FortiClient EMS는 기업 엔드포인트를 중앙 관리하며 VPN 프로파일 배포, NAC 기반 규정 준수 검사, 보안 패브릭 통합을 수행한다. Apache HTTP 서버가 리버스 프록시 역할을 맡고, 뒤쪽에 Django 기반 REST API 서버가 배치된다. mTLS 인증은 Apache mod_ssl이 처리한 뒤 그 결과를 WSGI 환경 변수로 Django에 넘기는 구조다.

⤢✕

정상적인 mTLS 처리에서는 Apache가 클라이언트 인증서 검증 결과를 신뢰 가능한 WSGI 환경 변수 SSL_CLIENT_VERIFY=SUCCESS로 전달한다. 하지만 FortiClient EMS의 CertChainAuth 미들웨어에는 이 값과 공격자가 직접 넣을 수 있는 X-SSL-CLIENT-VERIFY HTTP 헤더를 동일하게 신뢰하는 코드 경로가 있었다.

공격자는 EMS HTTPS 포트에 직접 접근한 뒤 X-SSL-CLIENT-VERIFY: SUCCESS 헤더와 위조된 클라이언트 인증서를 전송해 Django 미들웨어를 통과할 수 있었다. Apache가 검증한 결과와 외부 입력값의 출처가 백엔드에서 구분되지 않은 것이다.

validate_cert_chain()도 우회를 완성하는 결함을 갖고 있었다. 이 함수는 인증서 Subject와 Issuer Distinguished Name(DN) 문자열이 Fortinet 루트 CA 목록과 일치하는지만 확인하고, X.509 서명의 암호학적 검증은 수행하지 않는다. Fortinet 루트 CA의 DN 정보만 복사한 자체 서명 위조 인증서로 체인 검증을 통과할 수 있는 이유다.

엔드포인트 관리 제품에서 반복되는 우회 구조

이 사례는 VPN과 엔드포인트 관리 제품에서 나타나는 인증 우회 문제를 세 방향으로 보여준다.

리버스 프록시는 외부 인터넷 트래픽과 신뢰 가능한 내부 경로를 분리하는 경계다. 백엔드 애플리케이션이 헤더가 어느 경로에서 왔는지 판별하지 못하면 그 경계는 유지되지 않는다. FortiClient EMS에서는 Apache가 제거해야 했던 헤더를 핫픽스 이전에 RequestHeader unset 지시어로 처리하지 않았다.

Django가 HTTP_X_* 형식으로 매핑되는 HTTP 헤더를 환경 변수처럼 다루는 특성도 프록시 앞단에서 특히 주의해야 한다. 헤더를 명시적으로 제거하지 않으면 외부 요청이 내부 프록시에서 전달된 요청처럼 보일 수 있다.

인증서 DN을 문자열로 비교하는 방식은 세션 토큰 재사용이나 고정 헤더 값 주입과 비슷한 구조적 약점을 가진다. 메타데이터만 대조하고 실제 암호학적 서명을 검증하지 않으면 위조를 막을 수 없다.

NAC의 신뢰 기반을 지키는 인증 설계

FortiClient EMS는 엔드포인트의 정책 준수 여부를 검사한 뒤 네트워크 접근을 허용하는 NAC의 핵심 컴포넌트다. 기업에 배포된 엔드포인트를 관리하면서 VPN 연결 정책과 NAC 규칙을 배포하고, VPN 게이트웨이와 방화벽 정책, 엔드포인트 격리 명령, Zero Trust Network Access(ZTNA) 태그 발급처럼 네트워크 접근을 통제하는 기능도 EMS를 거친다. EMS 서버가 우회되면 NAC 전체가 무력화될 수 있으며, 기업 네트워크 접근 제어 전반에 영향을 줄 수 있다.

mTLS는 리버스 프록시에서 클라이언트 인증서를 완전히 검증하고, 백엔드에는 검증 결과만 신뢰 채널로 전달해야 한다. 외부에서 삽입할 수 있는 헤더는 프록시 진입점에서 unset 처리한다.

인증 전 접근이 가능한 API도 최소화해야 한다. 상태 확인용 /health를 제외한 엔드포인트는 인증 미들웨어를 우회하지 않도록 설계한다. 모든 API 엔드포인트는 인증이 필요한 상태로 등록하고, 명시적 예외가 있을 때만 공개 접근을 허용한다.

각 요청에서는 신원 확인과 권한 확인을 분리해 검증해야 한다. API 토큰과 서비스 계정에는 필요한 범위의 권한만 부여하고, 읽기 작업용 토큰으로 쓰기나 명령 실행이 가능해서는 안 된다. 관리 API와 일반 에이전트 통신 API도 인증 체계를 분리하며, 내부 네트워크라는 이유만으로 요청을 신뢰하지 않고 내부 서비스 간 통신에도 mTLS 또는 서비스 메시 기반 인증을 적용한다.

인증서 체인 검증은 DN 문자열이 아니라 전체 X.509 체인의 서명을 대상으로 수행하며, 유효 기간과 폐기 목록(CRL/OCSP) 확인도 병행한다.

EMS 관리 포트는 인터넷에서 직접 접근할 수 없도록 방화벽으로 제한하고, VPN 또는 제로 트러스트 네트워크 접근(ZTNA) 경로를 통해서만 접근하도록 구성한다.

제로데이 공개 직후의 패치 운영

CVE-2026-35616 공개와 CISA KEV 등재 사이의 간격은 수일이었고, 연방 기관의 패치 마감은 72시간 내였다. 기업 경계 보안 솔루션에는 평시 패치 절차와 구분되는 대응 체계가 필요하다.

⤢✕

인터넷 경계에 노출된 VPN 게이트웨이, RDP 브로커, SSH 배스천 호스트는 취약점 공개 후 단일 자릿수 일(single-digit day) 내 패치를 목표로 해야 한다. 이 범주의 솔루션에서 월별 패치 주기는 이미 위험하다.

긴급 배포를 실제로 수행하려면 자동화 기반도 준비돼 있어야 한다. 프로덕션과 같은 스테이징 환경의 IaC 기반 자동 프로비저닝, 사전 승인된 긴급 배포 권한, 배포 후 오류율 급증을 감지하는 자동화된 롤백 트리거가 필요하다.

FortiClient EMS 환경에서는 다음 항목을 확인한다.

FortiClient EMS 버전 7.4.5~7.4.6 사용 여부 확인
핫픽스(FG-IR-26-099) 즉시 적용 또는 7.4.7로 업그레이드
Apache 설정에 RequestHeader unset X-SSL-CLIENT-VERIFY 지시어 추가 확인
EMS 관리 포트의 인터넷 직접 노출 여부 점검
2026년 3월 31일 이후 EMS 접근 로그에서 비정상 인증 시도 조사
IoC: X-SSL-CLIENT-VERIFY 헤더가 포함된 외부 발신 요청

제품 단위 보안 검토가 필요한 이유

CVE-2026-35616 직전에 패치된 CVE-2026-21643(CVSS 9.1)은 FortiClient EMS 7.4.4의 사전 인증 SQL 인젝션이었다. 동일 제품에서 유사한 심각도의 사전 인증 취약점이 연이어 발견되고 악용된 점은 구조적 보안 설계 검토가 필요함을 시사한다.

인증 처리 경계, API 접근 제어, 입력 데이터의 신뢰 판단이 여러 레이어에 분산될수록 레이어 간 신뢰 가정의 불일치가 고심각도 취약점으로 이어질 수 있다. 기업 경계 보안 솔루션은 벤더 보안 공지 수신, 자동 패치 알림 설정, 정기적인 접근 제어 감사를 운영 표준으로 다뤄야 한다.