지름길인 줄 알았던 링크가 서버의 칸막이를 넘었다 — LiteSpeed cPanel 플러그인 심볼릭 링크 결함 CVE-2026-54420

이미지 출처: CISA KEV

공유 호스팅 한 대에는 수십, 많게는 수백 개의 계정이 같은 디스크 위에 얹혀 산다. 각 계정은 자기 홈 디렉터리 안에서만 움직이도록 칸막이가 쳐져 있고, 이 칸막이가 제대로 서 있다는 믿음 위에서 모든 임차인이 안심하고 사이트를 운영한다. 그런데 그 칸막이를 무력화하는 가장 오래된 수법 중 하나가 바로 심볼릭 링크다. 파일 하나가 "나는 사실 저쪽 파일이야"라고 가리키기만 하면, 그 링크를 따라가는 권한 높은 프로세스가 가지 말아야 할 곳까지 발을 들이게 되는 것이다. CVE-2026-54420은 LiteSpeed의 cPanel 플러그인이 바로 이 링크를 무비판적으로 따라가면서 생긴 문제로 정리된다.

핵심 요약

• 낮은 권한의 계정이 만든 심볼릭 링크를, 권한 높은 플러그인 프로세스가 그대로 따라가면서 계정 경계를 넘는 파일 접근이 발생할 수 있음
• 핵심 위험은 다른 계정·시스템 파일의 노출 또는 변조이며, 공유 호스팅처럼 한 호스트에 다수 사용자가 공존하는 환경에서 특히 치명적임
• 방어는 플러그인 최신화, 심볼릭 링크 보호 옵션 활성화, 링크 생성·추적에 대한 모니터링이라는 세 축으로 접근하는 것이 현실적임

심볼릭 링크 따라가기, 왜 위험한가

심볼릭 링크 자체는 정상적인 운영체제 기능임. 문제가 되는 지점은 "누가 만든 링크를, 누가 어떤 권한으로 따라가느냐"임. 일반 사용자는 자기 권한으로만 파일을 읽고 쓸 수 있지만, 백업·캐시·로그 처리처럼 시스템을 대신 손보는 보조 프로세스는 흔히 더 높은 권한으로 돈다. 이때 보조 프로세스가 경로 끝에 놓인 링크의 진짜 목적지를 확인하지 않고 그대로 open 하면, 사용자는 자기 손이 닿지 않던 파일을 그 프로세스의 손을 빌려 건드리게 됨.

전형적인 흐름은 이렇게 요약됨. ①공격자가 자기 계정 안에 평범해 보이는 파일을 두고, 그 파일을 시스템 영역의 민감한 파일로 향하는 링크로 바꿔치기함. ②권한 높은 플러그인 작업이 해당 경로를 처리할 차례가 옴. ③프로세스가 링크를 따라가 엉뚱한 대상을 읽거나 덮어씀. 여기엔 검사와 사용 사이의 시간 틈을 노리는 TOCTOU(Time-of-Check to Time-of-Use) 경쟁 조건이 섞이는 경우가 많아, 단순히 "링크를 한 번 막는다"로는 깔끔하게 닫히지 않는 까다로움이 있음.

방어자 관점에서 무엇을 먼저 보나

학습 목적이든 운영 목적이든, 이런 부류는 익스플로잇 코드를 외우는 것보다 탐지 가능한 흔적을 아는 편이 훨씬 쓸모 있음. 개인적으로는 다음 순서로 점검하기를 추천함.

• 패치 우선: 가장 확실한 차단은 플러그인을 취약점이 정리된 버전으로 올리는 것. 공유 호스팅 사업자라면 노드 단위로 배포 상태를 한 번에 확인하는 절차를 갖추는 게 좋음.
• 심볼릭 링크 보호 활성화: 커널·웹서버 단의 링크 보호 기능을 켜두면, 링크 소유자와 따라가는 프로세스의 소유자가 어긋날 때 추적을 거부하도록 만들 수 있음. 공유 환경에서는 이 옵션 하나가 광범위한 변종을 한꺼번에 막아 줌.
• 이상한 링크 모니터링: 사용자 홈 밑에서 시스템 경로나 다른 계정 경로를 가리키는 심볼릭 링크가 새로 생기는지 주기적으로 훑는 것. 파일 무결성 모니터링 도구나 간단한 점검 스크립트로도 "내 칸막이 밖을 가리키는 링크"는 충분히 잡아낼 수 있음.
• 로그 상관분석: 권한 높은 플러그인 작업의 실행 시점과, 직전에 발생한 비정상적 링크 생성·교체 이벤트를 시간축으로 맞춰 보는 것. 경쟁 조건성 공격은 보통 짧은 간격의 반복 시도라는 패턴을 남김.

재현은 개념까지만, 손은 방어에 두자

공격 재현을 욕심내기보다, "권한이 다른 두 주체가 같은 경로를 공유할 때 신뢰는 어디서 깨지는가"라는 질문을 붙들고 있으면 이 유형의 결함이 전부 같은 가족이라는 게 보임. 백업 솔루션, 캐시 워머, 로그 로테이터처럼 사용자 디렉터리를 대신 손보는 모든 보조 프로세스가 잠재적 후보임. 그러니 이번 CVE를 LiteSpeed 플러그인 하나의 이야기로만 닫지 말고, 우리 환경에서 높은 권한으로 사용자 파일을 만지는 작업이 또 어디 있나를 적어 내려가 보길 권함. 그 목록이 곧 다음 점검 대상이 됨.

공유 호스팅의 칸막이는 한 번 세워두면 끝나는 벽이 아니라, 매 패치마다 다시 다지는 살아 있는 경계라는 걸 이번에도 느낀다. 여러분 서버의 링크 보호 옵션은 지금 켜져 있나요? 점검해 보고, 막힌 부분이나 더 좋은 탐지 아이디어가 있으면 댓글로 같이 나눠 보아요.