필터는 'javascript:'를 막았는데 인코딩된 'javascript:'는 통과시켰다 — Plex Media Server CVE-2026-96654 방어 노트

이미지 출처: CISA KEV

링크 하나가 어떤 행동을 할지는 주소 맨 앞의 몇 글자, 그러니까 URI 스킴이 정함. http:면 페이지를 열고, mailto:면 메일 앱을 띄우고, javascript:면 그 자리에서 스크립트를 실행함. 웹 보안 쪽에서 이 몇 글자 때문에 생긴 사고만 모아도 꽤 긴 연대기가 될 거다. 이번 Plex Media Server의 CVE-2026-96654도 그 연대기에 들어갈 사례라서, 홈서버를 직접 굴리는 입장에서 정리해 봤음.

핵심 요약

• Plex Media Server 웹 화면에서 인코딩된 URI 스킴을 제대로 걸러내지 못하는 취약점(CWE-84 계열)으로, 결과적으로 XSS로 이어질 수 있음
• 공격자가 심어둔 링크나 메타데이터를 관리자가 웹 UI에서 보거나 클릭하면 그 세션 권한으로 스크립트가 실행될 수 있음
• 대응 우선순위는 최신 버전 업데이트, 외부 노출 최소화, 공유 사용자와 외부 메타데이터 점검 순서

1. 이 취약점이 정확히 뭐가 문제인지

NVD 분류명은 "Improper Neutralization of Encoded URI Schemes in a Web Page"임. 말이 길지만 풀어보면 단순함.

• 보통 웹 애플리케이션은 사용자 입력에 javascript:, data:, vbscript: 같은 위험한 스킴이 들어오면 막도록 만들어짐
• 근데 이 검사를 문자열 그대로 비교하는 방식으로 하면, HTML 엔티티나 퍼센트 인코딩, 대소문자 섞기, 중간에 공백·제어문자 끼워 넣기 같은 변형을 놓침
• 필터는 "이건 javascript:가 아니네" 하고 통과시키는데, 브라우저는 디코딩한 다음 해석하니까 결국 javascript:로 인식함
• 즉, 검사하는 쪽과 해석하는 쪽이 같은 문자열을 서로 다르게 읽는 게 핵심 문제

Plex는 영화 제목, 설명, 컬렉션 이름, 외부 링크 같은 메타데이터를 웹 UI에 그대로 그려주는 구조라서, 이런 값 중 하나가 링크 속성(href 등)으로 들어가는 지점이 있으면 바로 문제가 됨. 정확히 어떤 필드에서 터지는지, 영향받는 버전 범위가 어디까지인지는 Plex 공식 보안 공지와 NVD 항목을 꼭 직접 확인하는 게 맞음. 수치는 나중에 갱신되는 경우도 많아서 처음 본 숫자를 그대로 믿지 않는 편임.

2. 홈서버 운영자 입장에서 현실적인 공격 흐름

실행 가능한 페이로드는 다루지 않고 개념만 짚어봄.

• 입력 지점: 공유받은 사용자, 외부 에이전트가 가져오는 메타데이터, 혹은 조작된 미디어 파일의 태그 정보 등에 인코딩된 스킴이 섞인 링크가 들어감
• 저장: 서버가 이 값을 위험하다고 판단하지 못하고 그대로 저장함
• 트리거: 관리자가 웹 UI(app.plex.tv 또는 로컬 32400 포트 웹)에서 해당 항목을 열거나 링크를 클릭함
• 결과: 관리자 브라우저 세션 권한으로 스크립트가 실행되면서 토큰 탈취, 설정 변경, 공유 권한 조작 같은 2차 피해로 이어질 수 있음

개인적으로 제일 신경 쓰이는 건 Plex 토큰임. 이 토큰 하나면 웹 로그인 없이 API로 서버를 만질 수 있어서, XSS가 "팝업 하나 뜨는 장난"으로 끝나지 않는 이유가 바로 이거임.

3. 탐지: 어디를 들여다보면 되나

• Plex Media Server 로그: Windows는 %LOCALAPPDATA%\Plex Media Server\Logs, 리눅스는 보통 /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Logs 아래에 있음. 메타데이터 편집 요청이나 평소에 없던 IP에서 들어온 API 호출을 확인함
• 메타데이터 직접 검색: 라이브러리 DB나 웹 UI에서 제목·설명·링크 필드에 %6A, &#, 이상한 공백 같은 인코딩 흔적이 들어간 항목이 있는지 확인함. 정상 영화 설명에 이런 문자열이 들어갈 일은 거의 없음
• 리버스 프록시 로그: Nginx나 Caddy 앞단에 두고 있다면 요청 URL과 쿼리스트링에 인코딩된 javascript, data 스킴이 섞여 들어오는지 검색 규칙을 하나 만들어두면 편함
• 계정 쪽 이상 징후: Plex 계정의 인증된 기기 목록에 모르는 기기가 생겼는지, 공유 사용자 목록이 바뀌었는지 확인함

4. 완화: 오늘 할 것과 이번 주에 할 것

오늘 바로

• Plex Media Server를 패치가 반영된 최신 버전으로 업데이트함. 자동 업데이트를 꺼둔 사람이 의외로 많아서 설정 > 일반에서 한번 확인해 보는 거 추천함
• 의심스러운 일이 있었다면 Plex 계정에서 모든 기기 로그아웃 + 비밀번호 변경으로 기존 토큰을 무효화함
• 2단계 인증이 꺼져 있다면 켜둠

이번 주 안에

• 32400 포트를 공유기에서 직접 포워딩해 두었다면 꼭 필요한지 다시 생각해 봄. 외부 시청이 필요하면 VPN(WireGuard, Tailscale 등) 뒤로 숨기는 쪽을 개인적으로는 더 선호함
• 리버스 프록시를 쓰고 있다면 Content-Security-Policy 헤더로 인라인 스크립트와 javascript: 실행 범위를 줄여둠. Plex 웹 UI가 깨지지 않는 선에서 조금씩 조여가는 게 현실적임
• 라이브러리 공유 사용자 중 지금은 연락도 안 하는 계정은 정리함
• 관리자 작업은 평소 쓰는 브라우저 프로필 말고 관리 전용 프로필에서 하는 습관을 들이면 XSS 한 방에 전부 털리는 상황을 꽤 줄일 수 있음

5. 개발하는 사람이라면 가져갈 교훈

이건 Plex만의 문제가 아니라 URL을 받는 모든 서비스에 해당하는 얘기라서 짧게 덧붙임.

• 위험한 스킴을 차단 목록으로 막지 말고, http/https처럼 허용할 스킴만 허용 목록으로 받는 게 기본임
• 검사는 반드시 디코딩·정규화가 끝난 뒤에 해야 함. 브라우저가 해석하는 형태와 같은 형태로 만들어놓고 비교해야 우회가 안 됨
• 가능하면 직접 파싱하지 말고 언어나 프레임워크가 제공하는 URL 파서로 scheme을 뽑아서 판단함
• 출력할 때도 문맥(HTML 본문, 속성, URL)에 맞는 이스케이프를 따로 적용함. 입력 검증 하나만 믿으면 결국 이런 구멍이 생기는 것 같다

마무리

홈서버는 "집에서 혼자 쓰는 거니까" 하는 마음 때문에 업데이트가 제일 늦게 되는 장비인 것 같다. 나도 Plex는 한번 세팅해 두면 몇 달씩 안 들여다보다가 이번에 버전 확인하면서 생각보다 오래 방치했다는 걸 알았음. 이번 기회에 업데이트하고, 포트 포워딩이랑 공유 사용자 목록까지 같이 한번 정리해 봐요. 로그에서 이상한 흔적을 찾았거나 CSP를 Plex에 맞춰 적용해 본 분이 있으면 댓글로 경험 공유해 주세요. 같이 정리해서 다음 글에 보태보겠습니다.