캐시 워머가 열어준 뒷문 — Mirasvit Full Page Cache의 신뢰할 수 없는 역직렬화 이야기

이미지 출처: 재시도

쇼핑몰 관리자 입장에서 '캐시 워머(Cache Warmer)'는 고마운 도구임. 손님이 몰리기 전에 미리 페이지를 데워두니 첫 방문자도 빠른 화면을 만나게 됨. 그런데 그 따뜻함의 뒤편에서, Magento용 Mirasvit Full Page Cache 확장 기능이 외부에서 들어온 데이터를 너무 순순히 PHP 객체로 되살려내는 길을 열어뒀다는 점이 CVE-2026-45247로 정리되었음. 편의 기능이 공격 표면이 되는, 보안에서 자주 보던 그 장면임.

핵심 요약

• Mirasvit Full Page Cache Warmer가 신뢰할 수 없는 입력을 역직렬화(unserialize)해 PHP 객체 주입으로 이어질 수 있는 취약점임(CVE-2026-45247).
• Magento(전자상거래) 환경에서 캐시 관련 입력값이 객체로 복원되며, 매직 메서드 체인을 통한 코드 실행·파일 조작 가능성이 우려됨.
• 방어는 확장 기능 업데이트, 입력 무결성 검증, unserialize 사용 지점 점검, WAF·로그 모니터링의 조합으로 접근함.

역직렬화가 왜 그렇게 위험한가

직렬화는 객체를 저장·전송하기 좋은 문자열로 바꾸는 일이고, 역직렬화는 그 문자열을 다시 객체로 되살리는 일임. 문제는 이 '되살리는' 과정에서 PHP가 객체를 만들면서 __wakeup(), __destruct() 같은 매직 메서드를 자동으로 호출한다는 점임. 공격자가 직렬화 문자열의 클래스 이름과 속성값을 마음대로 지정할 수 있으면, 애플리케이션 안에 이미 존재하는 클래스들을 부품처럼 엮어(이걸 가젯 체인이라고 부름) 파일을 쓰거나 지우고, 경우에 따라 코드 실행까지 노릴 수 있음.

즉 취약점의 본질은 '믿어도 되는 데이터인지 확인하지 않고 unserialize에 넘기는 것'에 있음. Mirasvit Full Page Cache Warmer의 경우, 캐시를 데우는 흐름에서 외부 영향을 받을 수 있는 값이 검증 없이 객체로 복원되는 경로가 약점으로 지목됨. 공격 재현은 개념 수준에서만 이해하면 충분하고, 여기서 동작하는 페이로드를 만들어 보일 이유는 없음.

방어자가 가장 먼저 볼 곳

탐지와 완화를 같이 가져가야 함. 우선순위를 매기자면 이렇게 정리됨.

• 버전 확인과 업데이트: 가장 확실한 방어임. 설치된 Mirasvit Full Page Cache 확장의 버전을 점검하고, 벤더가 배포한 패치 버전으로 올리는 것이 먼저임. 정확한 영향 버전과 점수는 벤더 공지와 NVD 항목을 직접 대조해 확인하는 편을 권함.
• unserialize 사용 지점 감사: 코드베이스에서 unserialize() 호출을 전부 찾아, 입력 출처가 신뢰 가능한지 따져봄. 꼭 객체 복원이 필요 없다면 json_decode 같은 데이터 전용 형식으로 바꾸고, 불가피하다면 allowed_classes 옵션으로 복원 가능한 클래스를 화이트리스트로 제한하는 방식이 안전함.
• 입력 무결성 검증: 캐시 키·파라미터처럼 외부에서 닿을 수 있는 값에는 서명(HMAC)이나 엄격한 형식 검증을 붙여, 변조된 직렬화 문자열이 역직렬화 단계까지 도달하지 못하게 막음.

탐지·모니터링 관점

완벽한 차단이 어렵다면 '빨리 알아채는' 쪽으로 보완함. 웹 요청 로그에서 직렬화 패턴(예: O:로 시작하는 객체 표기, 비정상적으로 긴 인코딩 문자열)이 캐시 관련 엔드포인트로 들어오는지 살펴봄. WAF가 있다면 역직렬화 의심 페이로드를 탐지·차단하는 규칙을 캐시 워머 경로에 맞춰 점검함. Magento 운영이라면 파일시스템 무결성 모니터링을 함께 켜서, 갑작스러운 파일 생성·수정이 객체 주입의 흔적은 아닌지 확인하는 흐름이 도움이 됨. 개인적으로는 의심스러운 엔드포인트를 정해 한동안 상세 로깅을 켜두고 패턴을 모아보는 방식을 추천함 — 사후 분석할 때 이만한 자료가 없음.

전자상거래라서 더 신경 쓰이는 이유

쇼핑몰은 결제·회원 정보가 모이는 곳이라, 코드 실행으로 이어질 수 있는 취약점은 곧 카드 스키밍(매지카트류) 같은 후속 공격의 발판이 되기 쉬움. 캐시 워머는 성능을 위해 넓게 동작하다 보니 공격자가 노리기 좋은 길목이기도 함. 그래서 단순히 '패치 하나 올리고 끝'이 아니라, 같은 확장 생태계의 다른 직렬화 지점, 관리자 권한 분리, 외부 노출 최소화까지 한 번에 점검해두는 편이 마음이 놓임.

정리하며

이번 건은 새로운 마법이 아니라, PHP 역직렬화라는 오래된 약점이 또 한 번 실전 제품에서 드러난 사례임. 핵심은 늘 같음 — 믿을 수 없는 입력은 객체로 되살리지 않는다. 운영 중인 Magento에 Mirasvit 캐시 확장을 쓰고 있다면, 오늘 버전부터 확인하고 unserialize 지점을 한 번 훑어보는 걸로 시작해보면 좋겠음. 비슷한 역직렬화 사례를 분석한 경험이 있다면 댓글로 탐지 노하우 나눠주세요. 같이 보안 근육 키워봐요!