내 Plex 서버는 누구의 심부름까지 하고 있을까? CVE-2026-96652 SSRF, 로그로 찾고 설정으로 막기

이미지 출처: CISA KEV

OWASP가 2021년 Top 10을 개편할 때 커뮤니티 설문 1위로 SSRF(Server-Side Request Forgery)를 아예 단독 항목(A10)으로 올렸음. 그때만 해도 "클라우드 쓰는 큰 회사 얘기 아닌가" 싶었는데, 집에 Plex 하나 띄워놓고 공유기 포트포워딩까지 해둔 사람이라면 남 얘기가 아닌 것 같다. 이번에 공개된 CVE-2026-96652가 딱 그 SSRF 유형이고, 대상이 Plex Media Server라서 홈서버 운영자들이 한 번쯤 짚고 넘어가야 할 것 같아 정리해 봤음.

핵심 요약

• CVE-2026-96652는 Plex Media Server가 외부 입력을 받아 서버 자신이 요청을 보내는 과정에서 목적지 검증이 부족해 생기는 SSRF 취약점임
• 악용되면 Plex 서버가 바깥에서는 닿을 수 없는 공유기 관리 페이지, NAS, 로컬 API 등에 대신 요청을 보내는 "중계기"가 될 수 있음
• 대응의 핵심은 최신 버전 업데이트, 외부 노출 최소화, Plex 서버의 아웃바운드·내부망 접근 제한, 로그에서 내부 IP 대상 요청 확인임

SSRF를 한 줄로 정리하면

SSRF는 공격자가 직접 문을 두드리는 게 아니라 서버에게 "저 문 좀 대신 두드려줘"라고 시키는 공격임. 서버는 원래 신뢰받는 위치(내부망 안쪽)에 있으니까, 서버가 보내는 요청은 방화벽이나 접근통제를 그대로 통과하는 경우가 많음.

• 외부 공격자 → Plex 서버: "이 URL에서 메타데이터(혹은 이미지, 자막 등) 좀 가져와줘"
• Plex 서버 → 공격자가 지정한 내부 주소: 공유기 관리 페이지, 같은 대역의 NAS, 127.0.0.1에서만 열린 관리 포트 등
• 결과: 응답 내용이 노출되거나, 최소한 "어떤 포트가 열려 있는지"를 응답 시간·에러 차이로 추측할 수 있게 됨

미디어 서버는 성격상 바깥에서 포스터, 썸네일, 자막, 메타데이터를 끌어오는 기능이 많다 보니 "URL을 받아서 서버가 직접 가져오는" 구조가 여기저기 있을 수밖에 없음. 이번 취약점도 그런 지점 중 한 곳에서 목적지 검증이 느슨했던 것으로 보면 됨. 구체적인 엔드포인트나 요청 형태는 패치 전 서버가 많이 남아 있을 시점이라 여기서는 개념 수준까지만 다룸.

홈서버에서 이게 왜 더 아픈가

회사라면 서버 대역과 사용자 대역이 나뉘어 있고 내부 서비스에도 인증이 걸려 있는 경우가 많은데, 집은 사정이 다름.

• Plex, NAS, 공유기, IP카메라, 프린터가 전부 같은 192.168.x.x 대역에 평평하게 붙어 있음
• 공유기·카메라 관리 페이지가 "어차피 내부에서만 보이니까" 기본 비밀번호 그대로인 경우가 꽤 있음
• Docker로 Plex를 올렸다면 같은 호스트의 다른 컨테이너 관리 UI(포트 하나 열어둔 대시보드 같은 것)도 사정권에 들어옴
• 클라우드 VM에 Plex를 올렸다면 인스턴스 메타데이터 서비스(169.254.169.254) 쪽이 가장 민감한 표적이 됨. 여기서 임시 자격증명이 새면 피해가 서버 한 대로 끝나지 않음

개인적으로는 SSRF 자체보다 "내부라서 안전하다"는 가정이 깔린 집 안 장비들이 진짜 약점인 것 같다. SSRF는 그 가정을 무너뜨리는 열쇠 역할을 할 뿐임.

탐지: 로그에서 볼 것

Plex는 로그를 꽤 상세하게 남겨서 이상 징후를 보기 어렵지 않은 편임. 운영체제별 Plex 데이터 디렉터리 아래 Logs 폴더에 있는 서버 로그를 기준으로 아래를 확인해 보면 됨.

• 내부·예약 주소로 나가는 요청: 127.0.0.1, localhost, 10.x, 172.16~31.x, 192.168.x, 169.254.x 같은 주소가 외부 URL을 가져오는 동작 로그에 찍혀 있으면 의심 1순위임
• 평소와 다른 포트: 80, 443이 아닌 22, 8080, 9000, 5000번대 같은 포트로 짧은 시간에 연달아 요청이 나간 흔적은 포트 스캔 패턴일 가능성이 큼
• 낯선 원격 IP에서 들어온 요청 직후의 아웃바운드: 내가 안 쓰는 시간대에 외부 IP가 들어오고, 바로 뒤에 서버가 내부 주소로 뭔가를 가져오려 했다면 시간 순으로 묶어서 봐야 함
• 이상한 URL 표기: 10진수·16진수로 바꾼 IP, @가 섞인 URL, 리다이렉트를 여러 번 거치는 주소 등은 필터 우회 시도에서 자주 보이는 형태임

공유기나 방화벽에서 아웃바운드 로그를 남길 수 있다면 Plex 서버 IP가 출발지인 내부 대역 접속만 따로 걸러보는 것도 효과가 좋음. Plex가 NAS 공유 폴더를 읽는 정상 트래픽 말고, 공유기 관리 포트나 다른 기기 웹 포트로 가는 연결이 보이면 바로 들여다봐야 함.

완화: 오늘 할 수 있는 순서

• 1. 업데이트부터: Plex 웹 설정의 일반 항목에서 현재 버전을 확인하고, 이번 CVE를 다룬 보안 공지에 명시된 수정 버전 이상으로 올림. Docker 이미지라면 태그 고정 여부를 확인하고 이미지를 새로 받아 컨테이너를 재생성해야 실제로 반영됨
• 2. 원격 접근 다시 보기: 공유기에서 32400 포트를 직접 열어둔 상태라면, 정말 외부 재생이 필요한지부터 다시 따져봄. 가족끼리만 쓴다면 Tailscale, WireGuard 같은 VPN 뒤로 숨기는 쪽이 훨씬 마음 편함
• 3. Plex 서버의 "손 닿는 범위" 줄이기: 호스트 방화벽(ufw, Windows 방화벽 등)에서 Plex 프로세스나 컨테이너가 공유기 관리 IP, 카메라, 다른 관리 포트로 나가는 걸 막음. Docker라면 별도 네트워크로 분리하고 필요한 볼륨만 마운트함
• 4. 클라우드라면 메타데이터 보호: AWS라면 IMDSv2를 강제해서 토큰 없는 단순 GET 요청으로는 자격증명을 못 가져가게 하고, 인스턴스 역할 권한도 최소로 줄임
• 5. 내부 장비 기본기: 공유기·NAS·카메라 관리 비밀번호를 바꾸고, 관리 페이지에 접근할 수 있는 IP를 제한함. SSRF가 또 나와도 이 단계가 잘 되어 있으면 피해가 확 줄어듦
• 6. 가능하면 VLAN 분리: 공유기가 지원한다면 서버류와 IoT 기기를 다른 대역으로 나누는 게 근본적인 해법임. 처음엔 귀찮은데 한 번 해두면 차차 다른 취약점 대응도 편해짐

정리하며

SSRF는 화면에 뭔가 터지는 게 보이는 취약점이 아니라서 당했는지조차 모르고 지나가기 쉬움. 그래서 패치만 하고 끝내기보다 내 Plex 서버가 집 안에서 어디까지 닿을 수 있는지를 한 번 그려보는 게 더 의미 있는 것 같다. 업데이트, 노출 최소화, 아웃바운드 제한 이 세 가지만 해둬도 이번 같은 취약점이 다시 나왔을 때 훨씬 덜 불안함.

혹시 로그를 보다가 내부 주소로 나가는 수상한 요청을 발견했거나, Docker 네트워크 분리하다 막히는 부분이 있으면 댓글로 남겨주세요. 같이 보면서 하나씩 정리해 보아요!