FortiMail 취약점 CVE-2026-104286, 패치 전에 확인할 것

확인일 2026년 10월 2일. 기준 문서는 Fortinet 권고 FG-IR-26-175와 CISA 10월 1일 알림입니다.

메일 보안 장비를 쓰는 곳이라면 받은편지함보다 그 앞단을 먼저 봐야 합니다. FortiMail 취약점 CVE-2026-104286은 2026년 10월 1일 권고 FG-IR-26-175로 공개됐습니다. 로그인하지 않은 공격자가 HTTP 또는 HTTPS 요청으로 장비 안에 임의 파일을 쓸 수 있는 문제입니다. Fortinet은 실제 악용을 확인했다고 밝혔고, 같은 날 미국 CISA도 알려진 악용 취약점 목록에 올렸습니다. 수정 빌드는 10월 2일 기준으로 아직 예정 상태입니다.

한눈에 결론

  • 대상은 FortiMail 7.2·7.4·7.6·8.0 일부 버전입니다. 개인 메일 앱 문제가 아닙니다.
  • CVSS 9.8, 인증 없음, 네트워크에서 공격 가능. 권고는 실제 악용을 Yes로 표시합니다.
  • 8.0.2, 7.6.7, 7.4.9는 upcoming입니다. 받은 패치로 적으면 안 됩니다.
  • 당장 할 일은 관리 화면을 인터넷에서 닫거나 IBE 기능을 끄는 것입니다.
  • 우회만으로 끝이 아닙니다. 추가된 파일과 원격 보관 설정을 같이 봅니다.

로그인 없이 파일을 쓸 수 있는 문제인가

Fortinet 권고의 표현은 경로 제한 실패(CWE-22)와 NULL 바이트 처리 실패(CWE-158)입니다. 관리 화면에 해당하는 GUI 구성요소에서, 인증되지 않은 공격자가 만든 HTTP 또는 HTTPS 요청으로 기반 시스템에 임의 파일을 쓸 수 있습니다. CVSS 3.1 기본 점수는 9.8이고, 벡터는 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H입니다. 네트워크에서, 조건이 낮고, 권한이 없어도, 사용자 조작 없이 기밀성·무결성·가용성에 높은 영향이 난다는 뜻입니다.

권고의 영향 항목은 ‘승인되지 않은 코드 또는 명령 실행’입니다. CVE 설명문 자체는 임의 파일 쓰기까지를 적습니다. 파일 쓰기가 곧 원격 코드 실행이라고 설명문이 단정하지는 않지만, 영향란과 공개된 침해 흔적은 쓴 파일이 실행 경로로 이어진 사례를 전제로 합니다. 공격 요청을 만드는 방법은 권고에 없고, 이 글도 재현 절차는 다루지 않습니다.

발견은 외부 제보가 아니라 Fortinet 제품 보안팀 Gwendal Guégniaud의 내부 발견입니다. 공개일은 2026년 10월 1일이고, 권고는 Known Exploited를 Yes로 표시합니다. CISA는 같은 날 알림에서 CVE-2026-104286 Fortinet FortiMail Path Traversal Vulnerability 한 건을 KEV에 추가했다고 밝혔습니다. NVD에 반영된 KEV 조치는 10월 4일까지 제조사 안내에 따라 완화하고, 연방 기관에는 침해 여부 확인도 요구합니다. 이 기한은 미국 연방 민간 기관 기준입니다. 한국 기관이 그 날짜를 법적으로 물려받는 것은 아닙니다.

지금 사실로 볼 수 있는 범위

구분 내용
현재 판정 사실. 제조사 권고와 CISA 목록이 같은 날 맞음
원출처 Fortinet FG-IR-26-175, CISA 2026-10-01 알림
확인된 부분 인증 없는 임의 파일 쓰기, 실제 악용, 영향 버전, 우회, 침해 지표
미확인 부분 국내 피해 규모, 공격 집단 이름, 수정 빌드 실제 배포일
협력업체 주장 해당 없음. 제조사 내부 발견 후 공개

여러 보안 매체가 같은 권고를 옮겼더라도 독립 근거로 세지 않습니다. 운영 판단은 Fortinet 표와 CISA 등재로 충분하고, 매체 문장으로 버전 범위를 넓히거나 줄이지 않습니다.


메일 사용자와 장비 운영자의 일이 다른 이유

이 글의 대상은 FortiMail을 게이트웨이로 두는 조직입니다. 직원 편지함 앞이나 옆에서 스팸과 악성 메일을 거르는 장비라, 관리 화면이 인터넷에 열려 있으면 메일 내용이 아니라 장비 자체가 공격면이 됩니다. 일반 사용자는 휴대폰 앱을 업데이트한다고 이 취약점이 닫히지 않습니다.

굳이 해당하지 않는 경우도 분명합니다. FortiMail을 쓰지 않는 회사, FortiGate만 있는 환경, 개인 Gmail이나 네이버 메일을 쓰는 사람은 이번 번호의 직접 대상이 아닙니다. 포티넷 다른 제품이 같이 영향받는다는 문장은 권고에 없습니다. 일부 취약점 정리 사이트가 FortiRecorder 업그레이드 문장을 붙인 경우가 있지만, FG-IR-26-175 본문 표에는 FortiMail만 있습니다. 다른 제품까지 확대하지 않는 편이 맞습니다.

IBE를 끄는 조치는 운영자 일이면서, 쓰는 부서에는 영향이 있습니다. IBE는 외부 수신자가 포털에서 암호화 메일을 받아 보는 기능입니다. 법무·인사·재무가 이 방식으로 첨부파일을 주고받는다면, 기능을 끄는 순간 그 수신 경로가 멈춥니다. 보안팀만 알고 끄면 업무 장애로 돌아옵니다.


FortiMail 취약점, 권고 표와 스캐너 범위가 어긋나는 지점

운영 판단의 기준은 권고 표입니다. 2026년 10월 2일 확인한 FG-IR-26-175는 아래와 같습니다. CVE 설명문도 같은 네 구간을 적습니다.

분기 영향 버전 권고의 해결
FortiMail 8.0 8.0.0 ~ 8.0.1 8.0.2 이상, upcoming
FortiMail 7.6 7.6.0 ~ 7.6.6 7.6.7 이상, upcoming
FortiMail 7.4 7.4.0 ~ 7.4.8 7.4.9 이상, upcoming
FortiMail 7.2 7.2.0 ~ 7.2.9 7.4 분기로 업그레이드

그런데 NVD 영향 제품란과 CVE 레코드의 기계 판독 범위는 더 좁거나 다릅니다. 7.6은 7.6.5까지, 7.4는 7.4.6까지로 나오고, 권고 표에 없는 7.0.0~7.0.9가 포함됩니다. 스캐너가 이 피드를 그대로 쓰면 7.6.6과 7.4.7·7.4.8을 안전하다고 잘못 볼 수 있습니다. 반대로 7.0은 권고 표에 없으니, 피드만 보고 패치 대상으로 단정하기도 이릅니다. 7.0을 쓰는 곳은 권고가 갱신됐는지 다시 확인하고, 표에 없으면 제조사에 별도 확인이 필요합니다. 이 글을 쓰는 시점의 공식 표에는 7.0이 없습니다.

7.2 행은 더 주의가 필요합니다. 해결 칸은 7.4 분기로 올리라고 되어 있습니다. 그러나 7.4.0부터 7.4.8까지도 같은 권고의 영향 범위입니다. 오늘 받을 수 있는 7.4 최신이 7.4.8이라면, 분기만 옮겨도 취약 버전에 남습니다. 7.4.9가 실제로 배포된 뒤에야 그 이동이 수정이 됩니다. 일부 보도는 7.2 사용자가 7.4 이상으로 패치할 수 있다고 적었지만, 그 문장만 따르면 아직 없는 수정 빌드를 있는 것처럼 오해하기 쉽습니다.

영향 버전과 수정 상태 표. 8.0은 8.0.2 예정, 7.6은 7.6.7 예정, 7.4는 7.4.9 예정, 7.2는 7.4 이동만으로는 부족
공식 권고 기준 영향 범위와 수정 상태. 2026년 10월 2일 확인.

확인은 장비 CLI나 관리 화면에서 현재 빌드를 읽는 것으로 시작합니다. 위 표의 닫힌 구간에 들어가면 우회 대상입니다. 인벤토리 도구의 패치됨 표시는 수정 빌드 번호가 다운로드 목록에 생긴 뒤에만 믿습니다.


수정 빌드 전에 막을 수 있는 두 가지

Fortinet이 적은 우회는 두 갈래입니다. 둘 다 필수가 아니라 대안입니다.

  1. IBE 기능을 끕니다. CLI는 config system encryption ibe 다음 set status disable, end입니다.
  2. 관리 화면을 인터넷에서 닫거나, 신뢰하는 사설망에서만 열리게 합니다.

메일 수신 포트와 관리 포트를 같은 주소에 열어 둔 곳이 많습니다. 메일 중계만 남기고 관리 접속은 VPN이나 점프 호스트 뒤로 내리는 쪽이 두 번째 우회입니다. IBE로 외부 암호화 메일을 주고받으면 첫 조치는 업무 영향이 있습니다. 관리 화면이 이미 사내망에만 있다면 두 번째 조치는 된 상태일 수 있고, 그때는 IBE 경로가 남아 있는지 권고 문구대로 끄는 쪽을 검토합니다. 둘을 같이 하면 공격면은 더 줄지만, 권고가 둘 다를 필수로 적지는 않았습니다.

끄기 전에 설정을 백업하고, IBE를 쓰는 부서에 수신 경로가 멈춘다는 점을 알립니다. 가상 패치는 권고에 No입니다. IPS 시그니처가 나중에 생겨도, 10월 2일 기준 공식 대체 수단은 위 우회뿐입니다. 유지보수 창을 8.0.2가 나온 것으로 가정해 잡지 마십시오. 작업 당일 권고 페이지에서 upcoming이 빠졌는지, 릴리스 노트가 해당 CVE를 적는지 확인한 뒤 올립니다.

메일 수신을 멈추지 않고 관리 화면만 닫기

둘째 우회는 관리 인터페이스를 닫으라는 뜻이지, MX로 들어오는 메일 수신까지 멈추라는 뜻이 아닙니다. 공인 IP 하나에 SMTP 수신과 관리용 HTTP·HTTPS가 같이 열려 있는 구성이 많습니다. 그때 방화벽에서 막을 대상은 관리 접속이고, 메일 중계 포트는 그대로 둡니다. 권고는 관리 포트 번호를 적지 않았습니다. 설치마다 바꿀 수 있으므로, 장비 설정에 적힌 관리 접속 포트와 메일 포트를 먼저 구분한 뒤 관리 쪽만 사설망이나 VPN으로 제한합니다.

변경 전에는 설정 백업과 함께 현재 버전, IBE 사용 여부, 관리 접속 허용 범위를 남깁니다. 우회 뒤 외부 암호화 메일 수신이 멈추면 무엇을 되돌릴지 이 기록이 기준이 됩니다. 다만 관리 화면을 인터넷에 다시 여는 것은 우회를 푸는 일입니다. 업무 대체 경로가 있고, 파일 흔적 확인이 끝난 뒤에만 검토합니다. 흔적을 보기 전에 되돌리면 이미 올라간 파일을 놓친 채 공격면만 다시 열게 됩니다.

왼쪽은 문이 열린 장비로 외부 화살표가 향하고, 오른쪽은 닫힌 문 뒤에서 내부 장비만 연결된 그림
왼쪽은 관리 화면이 바깥에 열린 상태, 오른쪽은 내부 구간으로만 연결한 상태의 개념 그림입니다.

우회 뒤에도 남아 있을 수 있는 흔적

파일 쓰기 취약점은 패치나 우회 이후에도 이미 올린 파일이 남을 수 있습니다. Fortinet은 침해 지표로 추가·변경된 파일과 두 개 IP, 로그 예시를 공개했습니다. 아래 해시는 권고 원문의 SHA-256입니다. 탐지용으로만 적고, 파일을 구하는 방법은 다루지 않습니다.

경로 상태 SHA-256
/data/lib/liblog.so 추가 8015f34d…75cef84
/bin/smit 변경 77324ac4…418a5b6a
/data/bin/webconsole 추가 7a6cea9f…fd69ee38
/data/bin/mailservice 추가 4000276a…ae82157b
/data/etc/httpd.conf 변경 703e97c6…3bffdef5
/data/etc/ld.so.preload 추가 8953ec79…fdfbac23b6
/data/migadmin.tar.gz 변경 d6fe51c2…795609d3

표의 해시는 앞뒤를 줄인 값입니다. 대조할 때는 권고 원문의 전체 해시를 씁니다. 이 중 ld.so.preload는 리눅스에서 프로그램이 시작될 때 지정 라이브러리를 불러오게 하는 파일입니다. 권고가 이 경로를 추가로 표시한 것은, 단순 웹셸 하나보다 재부팅 뒤에도 남을 수 있는 흔적을 보라는 신호입니다. 해시가 같으면 Fortinet이 본 사례와 같습니다. 해시가 달라도 그 경로에 평소 없던 파일이 있으면 별도 조사가 필요합니다.

IP는 79.141.169.187과 45.129.0.192입니다. 로그 예시에는 archive234 계정으로 원격 보관을 79.141.169.187의 /uploads로 보내는 설정 변경이 있습니다. 관리자 로그아웃이 ui=(null)로 남은 줄, cron에서 셸이 돈 줄도 예시입니다. IBE 복호화 쪽에서 Invalid Base64 Encoding, 문자 0x2a가 잡힌다는 줄도 있습니다. 0x2a는 별표 문자입니다. Fortinet은 이 로그가 공격 패킷 그 자체라고 설명하지 않았으므로, 침해의 확정 증거가 아니라 같이 볼 흔적으로 다루는 것이 맞습니다.

확인은 장비에 접속할 수 있는 운영자가 합니다. 파일 존재와 해시, 최근 관리자 설정 변경, 원격 보관 대상 IP를 봅니다. 흔적이 있으면 우회로 끝내고 재사용하지 않습니다. 격리 후 신뢰하는 절차로 다시 설치하고, 관리자 비밀번호와 연동 계정을 바꿉니다. 국내 침해 건수나 공격 그룹 이름은 공개된 권고에 없습니다.

원격 보관 계정이 특히 중요합니다. 로그 예시의 archive234는 메일 보관본을 외부 IP의 /uploads로 보내도록 바뀐 설정입니다. 이 줄이 장비에 남아 있다면, 파일 쓰기에서 끝나지 않고 보관 메일이 밖으로 나갔을 가능성을 조사해야 합니다. 권고는 그 전송이 실제로 몇 통이었는지, 어떤 도메인이 대상이었는지는 적지 않았습니다. 그래서 해시가 맞는 파일을 찾은 조직은 보관 정책과 원격 대상 IP를 로그에서 기간별로 세고, 해당 구간 메일의 민감도를 따로 판단해야 합니다. 흔적이 없는 조직까지 유출이 있었다고 볼 근거는 없습니다.


지금 기다릴지, 우회를 먼저 할지

수정 빌드가 없으면 대기만 하는 선택이 취약 상태를 연장합니다. 관리 화면이 인터넷에 있고 버전이 영향 범위면 우회가 먼저입니다. 관리 화면이 이미 닫혀 있고 IBE를 쓰지 않으면 노출은 줄었지만, 권고가 IBE를 첫 우회로 적은 만큼 기능 상태를 기록해 두는 편이 안전합니다. 7.2를 7.4.8로 올려 패치 완료로 보고하는 것은 현재 표와 맞지 않습니다.

현재 상태 우선 판단
관리 화면이 인터넷에 열림 수신 포트를 유지하고 관리 접속부터 닫음
IBE로 외부 암호화 메일을 씀 부서에 알린 뒤 기능을 끄거나 대체 경로를 정함
7.2를 7.4.8로 올릴 예정 수정이 아님. 7.4.9 배포 전까지 우회 유지
스캐너가 7.6.6을 안전으로 표시 권고 표가 7.6.6까지 영향. 피드보다 권고 우선
FortiMail을 쓰지 않음 이번 CVE의 직접 조치 대상이 아님

미국 연방 기관의 KEV 기한은 10월 4일입니다. 그 날짜가 한국 회사의 법정 기한은 아닙니다. 다만 목록 등재는 개념 증명 단계가 아니라 악용 확인 단계라는 뜻이라, 주말 뒤로 미루기에는 공격면이 넓습니다. 메일 흐름을 멈추지 않으려면 관리 포트만 먼저 닫고, IBE는 업무 확인 뒤 끄는 순서가 현실적입니다.

빠지기 쉬운 판단은 네 가지입니다.

  • 스캐너의 7.6.5 상한을 믿고 7.6.6을 제외하는 것.
  • upcoming을 배포된 패치로 적는 것.
  • IBE를 끄면서 외부 수신 부서에 알리지 않는 것.
  • 파일 흔적을 보지 않고 우회만 체크하는 것.

우회 후에도 권고 페이지를 다시 열어 8.0.2, 7.6.7, 7.4.9가 실제로 나왔는지 확인합니다. 배포 전에는 릴리스 노트에 CVE-2026-104286이 적혀 있는지도 같이 봅니다.

패치 전 확인 순서. 현재 버전 확인, 관리 화면 외부 차단, IBE 기능 끄기, 추가된 파일 흔적 확인, 수정 빌드 재확인
패치 전 확인 순서. 3번 IBE는 업무 영향을 본 뒤 적용합니다.

자주 나오는 확인 질문

개인 메일에도 패치가 필요한가

아닙니다. FortiMail 장비를 운영하지 않으면 이번 CVE의 직접 대상이 아닙니다. 포털이나 앱 업데이트로 대신되지 않고, 반대로 개인 사용자에게 장비 CLI를 실행하라고 할 일도 없습니다.

7.0은 영향인가

권고 표에는 없고, NVD 영향 제품란에는 7.0.0~7.0.9가 있습니다. 10월 2일 기준 운영 판단은 권고 표를 우선하고, 7.0은 표가 갱신되기 전까지 영향이라고 단정하지 않습니다. 해당 분기를 쓰는 곳은 권고 페이지를 다시 확인합니다.

패치는 나왔는가

권고는 8.0.2, 7.6.7, 7.4.9를 upcoming으로 적습니다. 10월 2일 확인 시점에는 배포됐다고 쓰지 않습니다. 다운로드 센터에 그 빌드가 생기고 릴리스 노트가 이 CVE를 적기 전에는 우회를 유지합니다.

관리 화면만 막으면 충분한가

권고는 관리 화면 제한을 대안 우회로 적습니다. IBE를 쓰는 곳은 기능 중지의 업무 영향을 본 뒤 첫 번째 우회도 검토합니다. 어느 쪽을 했든 파일 흔적 확인은 별개입니다.


출처

버전 범위가 문서마다 다르면 FG-IR-26-175 표를 우선합니다. 수정 빌드 배포 여부는 작업 당일 같은 페이지에서 다시 확인합니다.

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x
()
x