QNAP NAS의 PHP2Shell 수정 펌웨어는 build 20261023으로 나왔다. 다만 빌드 날짜만 보고 판단하면 안 된다. 내 운영체제 계열에 맞는 전체 버전 번호까지 맞춰 봐야 한다. App Center 앱과 컨테이너 안의 PHP는 그와 별개로 따로 확인해야 한다.
QNAP은 10월 22일 보안 권고 QSA-26-18을 낸 뒤 두 차례 개정했다. 10월 24일 운영체제 수정 빌드가, 10월 28일 Notes Station 3 수정판이 올라왔다. 그 사이 미국 CISA는 두 취약점을 실제 악용 취약점 목록에 올렸다.
워드프레스와 웹호스팅 쪽 대응은 이전 글에서 다뤘다. 이 글은 QNAP NAS 소유자가 확인할 것만 정리한다.
한눈에 보기
📌 권고 — QNAP QSA-26-18 (현재 V1.2, 상태 Resolved)
📌 대상 — CVE-2026-109618, CVE-2026-109619 (통칭 PHP2Shell)
📌 운영체제 수정 — QTS·QuTS hero·QuTScloud build 20261023
📌 앱·장비 수정 — Notes Station 3 3.9.15 / QVR Surveillance 3.0.3.1756(ARM32) / TVR OS 1.0.5
📌 펌웨어로 안 고쳐지는 것 — Container Station 컨테이너·타사 앱 안의 PHP
👉 할 일: 펌웨어 → 앱 → 컨테이너 순서로 따로 확인
10월 22일 이후 바뀐 것
첫 권고가 나왔을 때 QNAP의 모든 영향 제품은 ‘수정 중’이었다. 수정 버전은 ‘추후 공지’였다. 당시에는 인터넷 노출을 끊고 수정판을 기다려야 했다. 지금은 설치할 버전이 있다.
| 날짜 | 일어난 일 |
|---|---|
| 10월 21일 | PHP 수정 릴리스 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 |
| 10월 22일 | QNAP QSA-26-18 V1.0. 전 제품 ‘수정 중’, 수정 버전 미정 |
| 10월 23일 | PHP, 별개 취약점 CVE-2026-115560 안내 (정식 수정판 없음) |
| 10월 24일 | QSA-26-18 V1.1. QTS·QuTS hero·QuTScloud 수정 빌드 공개 |
| 10월 26일 | 미국 CISA, 두 CVE를 실제 악용 취약점(KEV) 목록에 추가 |
| 10월 28일 | QSA-26-18 V1.2. Notes Station 3 3.9.15 수정 |
권고 문서의 다른 문장은 그대로다. QNAP은 PHP를 노린 공격 시도가 공개적으로 보고됐다고 적었다. 동시에 QNAP 제품을 노린 악용 보고는 받지 않았다고 밝혔다.
내 NAS 운영체제별 수정 빌드
지금 쓰는 버전은 제어판 → 시스템 → 펌웨어 업데이트 화면에서 보인다. 운영체제 계열(QTS·QuTS hero·QuTScloud)과 전체 버전 번호를 아래 표와 함께 맞춰 본다. 빌드 날짜가 같아도 계열이 다르면 다른 펌웨어다. 수정 빌드보다 새 펌웨어가 나와 있다면 최신 버전을 설치하면 된다. QNAP도 최신 버전 유지를 권고한다.
| 현재 운영체제 | 설치할 수정 빌드 (build 20261023) |
|---|---|
| QTS 6.1.0 | QTS 6.1.0.3656 |
| QTS 5.2.11 이하 | QTS 5.2.11.3661 |
| QuTS hero h6.1.0 | QuTS hero h6.1.0.3656 |
| QuTS hero h6.0.x | QuTS hero h6.0.2.3656 |
| QuTS hero h5.3.x | QuTS hero h6.0.2.3656 (계열 변경) |
| QuTS hero h5.2.11 이하 | QuTS hero h5.2.11.3661 |
| QuTScloud c5.2.9 이하 | QuTScloud c5.2.9.3661 |
표에서 특히 주의할 항목은 세 가지다.
QuTS hero h5.3.x에는 같은 계열 수정판이 없다. QNAP이 지정한 수정 버전은 h6.0.2.3656이다. 운영체제 계열이 바뀌므로 다운로드 센터에서 내 모델의 지원 여부와 업그레이드 경로부터 확인한다. 업데이트 전에는 중요한 데이터를 외부 장치나 별도 저장소에 백업하고, 복원되는지까지 확인해 둔다. 같은 NAS 안의 스냅숏은 장비 자체에 문제가 생기면 함께 잃을 수 있어 백업을 대신하지 못한다. 경로가 불분명하면 QNAP 기술지원에 먼저 문의한다.
6.1 계열 수정 빌드는 퍼블릭 베타로 배포됐다. QNAP 커뮤니티의 10월 24일 배포 공지는 QTS 6.1.0.3656과 QuTS hero h6.1.0.3656을 퍼블릭 베타로 표기했다. 5.2.11 계열과 h6.0.2 계열 빌드는 정식 릴리스로 올라왔다.
‘5.2.11 이하’의 수정판은 하나뿐이다. 권고 표에는 QTS 5.2.11.3661만 있다. QTS 5.2를 설치할 수 없는 구형 모델용 수정판은 표에 없다. 이런 모델은 QNAP 제품 지원 상태 페이지에서 업데이트 제공 여부부터 봐야 한다. 보안 매체 집계로는 QTS 5.2 이전에 쓰던 선택형 PHP 7.4 앱도 아직 조사 중으로 분류돼 있다.
펌웨어로 끝나지 않는 세 층
QNAP NAS 안의 PHP는 한 군데에만 있지 않다. 관리 화면을 돌리는 운영체제, QNAP이 만든 앱, 사용자가 올린 컨테이너에 각각 들어 있다. 고치는 주체와 경로가 층마다 다르다.
| 층 | 해당 예시 | 고치는 경로 |
|---|---|---|
| ① 운영체제 | QTS · QuTS hero · QuTScloud | 펌웨어 업데이트 |
| ② QNAP 앱 | Notes Station 3 → 3.9.15 QVR Surveillance(ARM32) → 3.0.3.1756 | App Center에서 앱별 업데이트 |
| ③ 컨테이너·타사 앱 | Container Station 이미지, 타사 웹앱 | 이미지·앱 제공사의 수정판 |
③은 QNAP이 펌웨어를 아무리 고쳐도 그대로 남는다. QNAP 권고가 직접 밝힌 내용이다. 컨테이너 이미지나 타사 앱 안의 PHP는 QNAP 업데이트 범위 밖이라고 적었다.
별도 장비도 있다. QVR 전용 녹화 장비가 쓰는 TVR OS는 1.0.5에서 고쳐졌다. NAS가 아니라 그 장비 자체를 업데이트해야 한다.
목록 변화도 하나 있다. 첫 권고의 영향 목록에는 QuMagie 2.10.1 이하와 QNE(ADRA) 1.0.7 이하가 있었다. 11월 1일 확인한 영문·한국어 권고 표에는 두 제품이 없다. QNAP은 빠진 이유를 밝히지 않았다. 목록에서 빠졌다는 사실이 수정 완료를 뜻하지는 않는다. 해당 제품을 운영한다면 제품별 릴리스 노트와 QNAP 지원 안내로 수정 여부를 확인하고, 확인 전까지는 외부 접근을 막아 두는 편이 안전하다.
컨테이너에서 실제 실행 중인 PHP 버전 확인
Container Station에서 웹앱을 돌린다면 이 부분을 별도로 점검해야 한다. 이미지 태그에는 PHP 버전이 안 적혀 있을 수 있다. 실행 중인 컨테이너 안에서 PHP 버전을 직접 확인하는 편이 정확하다. 공식 기준은 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상이다. 배포판 이미지는 버전 숫자를 그대로 둔 채 보안 수정만 넣는 경우도 있어, 그때는 이미지 제공자의 보안 공지로 확인한다.
이미지를 새로 받는 것만으로는 부족하다. 이미 돌고 있는 컨테이너는 예전 이미지로 계속 실행된다. 새 이미지를 받은 뒤 컨테이너를 다시 만들어야 수정이 반영된다. 재생성 후에는 실행 중인 컨테이너에서 PHP 버전을 한 번 더 확인한다. Nextcloud처럼 앱 단위 이미지를 쓴다면 그 이미지 제공자가 PHP를 올렸는지도 확인해야 한다.
10월 22일 이후 컨테이너 운영자가 알아둘 일이 두 가지 더 생겼다.
① 8.4.27·8.5.12의 SimpleXML 충돌 — 이번 보안 릴리스에서 특정 SimpleXML 코드가 worker를 멈추게 하는 회귀 버그가 보고됐다. 오류 로그에는 zend_mm_heap corrupted가 찍힌다. 8.3.36과 8.2.35는 해당하지 않는다. 이 현상이 나타나면 PHP 후속 수정판이나 이미지 제공자의 수정 패키지를 먼저 확인한다. 다른 PHP 계열로 옮긴다면 앱 호환성과 지원 기간을 따져야 한다. 보안 패치 이전 버전으로 되돌리는 것은 답이 아니다.
② 별개 취약점 CVE-2026-115560 — 10월 21일 수정판으로는 막히지 않는다. 세션 직렬화 설정을 특정 방식으로 바꾸는 드문 구성에서만 해당한다고 PHP는 설명했다. 다음 정기 릴리스에서 고칠 예정이다. 그 전까지 PHP가 제시한 완화책은 session.upload_progress.enabled=0이다. 이 설정은 파일 업로드 진행률 표시 기능에 영향을 줄 수 있다. 바꾼 뒤에는 PHP 작업 프로세스를 재시작해야 실제 요청에 반영된다.
②의 설정 변경은 컨테이너처럼 php.ini를 직접 다룰 수 있는 환경 이야기다. QNAP 운영체제 내부 PHP 설정을 사용자가 바꾸라는 뜻이 아니다.
업데이트 순서
QNAP 권고의 완화 조치와 설치 안내를 순서대로 묶으면 아래와 같다.
1. 외부 노출부터 끊는다
공유기의 NAS 포트포워딩과 UPnP를 끈다. myQNAPcloud의 자동 라우터 구성에서 UPnP 포트포워딩도 끈다. 쓰지 않는 myQNAPcloud Link와 게시 서비스는 내린다.
2. 펌웨어를 올린다
제어판 → 시스템 → 펌웨어 업데이트 → 실시간 업데이트에서 업데이트를 확인한다. 알림이 없으면 QNAP 다운로드 센터에서 모델명으로 받아 수동 설치한다.
3. 앱을 따로 올린다
App Center에서 Notes Station 3 등 설치된 앱을 검색해 업데이트한다. 지금 쓰지 않는 PHP 기반 앱은 중지해 둔다.
4. 컨테이너를 다시 만든다
수정된 PHP가 든 이미지를 받고 컨테이너를 재생성한 뒤, 실행 중인 PHP 버전을 다시 확인한다.
5. 흔적을 점검한다
QuLog Center에서 낯선 로그인과 접근을 확인한다. Security Center와 Malware Remover를 최신 정의로 돌린다. 아마존 위협 인텔리전스가 첫 악용 시도를 관측한 10월 17일부터 보는 편이 안전하다.
6. 침해가 의심되면
NAS를 네트워크에서 분리하고, 모든 비밀번호를 바꾸고, QNAP 지원에 문의한다. 비밀번호는 NAS와 분리된 다른 기기에서 바꾸는 편이 안전하다. 패치를 설치해도 이미 들어온 침입 흔적까지 지워지지는 않는다.
웹 서버 끄기와 내부망 제한은 패치가 아니다
QNAP NAS 사용자 사이에서 가장 많이 퍼진 대응이 내장 웹 서버 끄기다. QNAP은 이 조치가 관리 화면을 보호하지 않는다고 권고에 적었다. 관리 화면 자체가 PHP로 돌아가기 때문이다.
관리 포트를 내부망에만 여는 것도 한계가 있다. QNAP은 이미 감염된 내부 기기에서 들어오는 공격은 막지 못한다고 밝혔다. 집 안 PC 한 대가 뚫리면 NAS 관리 화면은 같은 공유기 안에 있다.
패치 후에도 권고는 같다. 원격 접속은 QVPN이나 공유기 VPN을 거친다. 관리 포트(기본 8080·443)는 QuFirewall이나 허용·거부 목록으로 신뢰할 수 있는 대역에만 연다.
시놀로지와 비교하면 차이가 분명해진다. 시놀로지는 영향 범위를 패키지 센터의 PHP 패키지 쪽으로 봤다. DSM 내부 PHP는 외부에 열린 모듈이 없어 위험이 최소라고 평가했다. QNAP은 운영체제의 웹 구성요소에 PHP를 쓴다. 같은 취약점이어도 QNAP은 운영체제 펌웨어를 먼저 올려야 하는 이유다.
QNAP NAS가 실제로 공격받았나
📌 확정 — 미국 CISA는 10월 26일 두 CVE를 KEV 목록에 올렸다. PHP 취약점이 실제로 악용됐다는 공식 확인이다. 같은 시점 QNAP 권고는 자사 제품을 노린 악용 보고가 없다고 적고 있다.
📢 보도 — 보안 연구자의 허니팟에서 Apache mod_php 위의 PHP 8.4.26을 상대로 원격 코드 실행이 성공했다. 보안업체 Tenable 분석에 따르면 공격에 유리한 단일 worker 구성이었다. 실제 서버에서 같은 성공률이 나온다는 뜻은 아니다.
🔎 분석 — ‘PHP가 악용됐다’와 ‘QNAP NAS가 뚫렸다’는 다른 문장이다. 지금 확인된 건 앞의 것뿐이다. 다만 NAS 관리 화면에 PHP가 들어 있는 이상, 인터넷에 직접 노출된 장비는 원격 공격 위험을 고려해야 한다.
🔎 Hoonyspot 판단
가장 흔한 실수는 펌웨어 업데이트 알림 하나를 처리하고 끝내는 것이다. 운영체제 계열과 전체 버전이 수정 빌드 이상인지 확인한 뒤, App Center와 Container Station을 한 번씩 더 여는 3단계 점검이 필요하다.
파일 공유만 쓰고 외부 접속을 열지 않은 가정용 NAS라면 펌웨어 업데이트가 대응의 대부분이다. 반대로 NAS에서 웹앱이나 Docker 컨테이너를 운영한다면 컨테이너 점검을 따로 해야 한다. 이 경우 QNAP의 ‘Resolved’ 표시는 내 컨테이너까지 해결됐다는 뜻이 아니다.
자주 묻는 질문
Q. 펌웨어 업데이트 알림이 뜨지 않습니다.
알림이 없다고 패치된 것은 아닙니다. 모델이 해당 운영체제 계열을 지원하는지 먼저 확인해 보세요. QNAP 제품 지원 상태 페이지에서 볼 수 있습니다. 지원 모델이라면 다운로드 센터에서 수동 설치가 가능합니다.
Q. 외부 접속을 쓰지 않으면 업데이트를 미뤄도 되나요?
위험은 크게 낮아지지만 패치를 대신하지는 못합니다. QNAP도 내부망 제한이 이미 감염된 내부 기기의 공격은 막지 못한다고 안내했습니다.
Q. 내장 웹 서버를 껐는데 이걸로 충분한가요?
아닙니다. QNAP은 웹 서버를 꺼도 관리 화면은 보호되지 않는다고 밝혔습니다. 펌웨어 업데이트가 필요합니다.
Q. Container Station 컨테이너도 QNAP 업데이트로 고쳐지나요?
아닙니다. 컨테이너 안 PHP는 이미지 제공사가 고친 이미지로 컨테이너를 다시 만들어야 반영됩니다.
확인 기준일: 2026년 11월 1일. QNAP 보안 권고 QSA-26-18(V1.2) 기준이며, 후속 개정에 따라 수정 버전과 대상 제품이 바뀔 수 있습니다. 업데이트 전에는 내 모델에 맞는 공식 패키지인지 QNAP 다운로드 센터에서 다시 확인해 주시기 바랍니다. 이 글은 실제 NAS 업데이트를 수행한 후기가 아니라 공식 자료를 정리한 내용입니다.
참고 자료
- QNAP 보안 권고 QSA-26-18 — qnap.com
- QNAP 커뮤니티 수정 빌드 배포 공지 — community.qnap.com
- 미국 CISA KEV 등재 공지(10월 26일) — cisa.gov
- Tenable PHP2Shell 분석 — tenable.com
- PHP 8.4.27 릴리스 — github.com/php
- Synology PHP2Shell 성명 — synology.com
- 네덜란드 NCSC PHP2Shell 영향 제품 목록 — github.com/NCSC-NL
