상품 설명란에 넣은 중괄호 하나 — Adobe Commerce 템플릿 엔진이 그것을 명령으로 읽을 때

이미지 출처: CISA KEV

쇼핑몰 관리자 페이지에서 상품 설명을 편집하다 보면, 굵게·기울임 말고도 이상한 문법이 하나 눈에 띔. {{store url=""}} 같은 중괄호 두 개짜리 지시문. Magento 계열을 만져본 사람이면 다들 한 번쯤 써봤을 그 문법인데, 이게 바로 이번 이야기의 출발점임.

핵심 요약

• Adobe Commerce·Magento의 템플릿 엔진이 특수 문자를 제대로 무력화하지 않아, 콘텐츠에 삽입된 지시문이 서버에서 그대로 해석될 수 있는 문제임
• 공격 표면은 관리자 콘텐츠 필드·이메일 템플릿·CMS 블록처럼 "사용자가 문자열을 넣고 서버가 렌더링하는" 모든 지점임
• 방어는 패치 적용이 1순위, 그다음이 관리자 권한 최소화·템플릿 필터 화이트리스트 점검·렌더링 로그 기반 탐지임

템플릿 엔진이 왜 취약점의 무대가 되는가

Magento의 템플릿 문법은 원래 편의를 위해 만들어진 것임. 이메일 하단에 매번 스토어 주소를 손으로 적을 순 없으니 {{store}} 같은 지시문을 두고, 렌더링 시점에 실제 값으로 바꿔주는 구조. 문제는 이 "바꿔주는" 동작이 문자열을 데이터가 아니라 코드로 취급한다는 점임.

여기서 특수 요소의 중화(neutralization)가 제대로 안 되면 어떻게 되는지가 CVE-2026-75650의 핵심임. 공격자가 넣은 문자열이 단순 텍스트로 출력되는 게 아니라, 템플릿 파서를 거치면서 지시문 경계를 새로 만들어냄. 파서 입장에서는 "관리자가 정당하게 넣은 지시문"과 "외부에서 흘러들어온 문자열"을 구분할 방법이 없음. 둘 다 똑같은 중괄호로 보이니까.

이런 종류를 서버 사이드 템플릿 인젝션(SSTI)이라고 부름. SQL 인젝션이 쿼리 문법 경계를 넘는 거라면, SSTI는 템플릿 문법 경계를 넘는 것. 그리고 템플릿 엔진은 대개 객체 접근이나 메서드 호출 같은 기능을 품고 있어서, 경계를 한 번 넘으면 도달 범위가 생각보다 훨씬 넓어짐. 개념적으로만 말하면 "출력용 문법이 실행용 문법으로 승격되는 순간"이 위험 지점임.

어디를 봐야 하는가 — 공격 표면 지도

패치를 바로 못 올리는 상황이라면, 최소한 내 쇼핑몰에서 어디가 위험한지는 알고 있어야 함. 템플릿 인젝션이 성립하려면 두 조건이 동시에 필요함: 공격자가 문자열을 심을 수 있는 입력점과 그 문자열을 서버가 템플릿으로 렌더링하는 출력점.

• CMS 페이지·블록 — 마케팅팀이 자유롭게 편집하는 영역이라 지시문 사용이 일상적임. 그래서 이상한 지시문이 섞여도 눈에 잘 안 띔
• 이메일·트랜잭션 템플릿 — 주문 확인, 배송 안내 메일. 렌더링이 백그라운드 큐에서 도는 경우가 많아 흔적이 더 흐림
• 상품 속성·설명 필드 — 특히 외부 PIM이나 공급사 피드로 자동 동기화되는 환경이면, 내가 직접 입력하지 않은 문자열이 그대로 들어옴
• 위젯·레이아웃 업데이트 XML — 관리자 UI로 노출된 영역 중 가장 강력한 축에 속함
• 테마·확장 모듈 — 서드파티 익스텐션이 자체적으로 템플릿 필터를 호출하면서 코어의 안전장치를 우회하는 경우가 실제로 꽤 있음

정리하면 "관리자만 만질 수 있으니 괜찮다"는 전제가 흔들리는 게 문제임. 커머스 운영 조직은 보통 계정이 많음. 마케터, MD, 외주 개발사, 고객센터. 그중 한 계정만 털려도 조건이 성립함.

탐지: 로그에서 무엇을 골라낼 것인가

이 유형은 익스플로잇 순간이 조용해서, 사후 탐지를 미리 설계해두는 게 훨씬 이득임. 개인적으로는 다음 세 겹으로 보는 걸 추천함.

첫째, 콘텐츠 저장 시점의 문자열 검사. DB에서 CMS 블록·페이지·상품 설명 컬럼을 대상으로 중괄호 지시문 패턴을 주기적으로 스캔함. 정상 운영에서 쓰는 지시문 목록(store, media, block, widget 정도)을 화이트리스트로 잡아두고, 그 밖의 이름이 등장하면 알림. 정상 목록이 짧다는 게 오히려 유리한 지점임.

둘째, 렌더링 시점의 이상 징후. 템플릿 필터가 처리하는 과정에서 예외가 나거나, 평소보다 렌더링 시간이 튀거나, PHP 프로세스가 갑자기 외부로 커넥션을 여는 패턴. 특히 웹 서버 계정에서 나가는 아웃바운드 트래픽은 커머스 환경에서 원래 종류가 뻔하기 때문에, 화이트리스트 기반 이그레스 통제가 잘 먹힘.

셋째, 파일 시스템 무결성. 템플릿 인젝션의 최종 목적지는 대개 웹셸 설치나 결제 정보 스키밍 스크립트 삽입임. pub/, var/, generated/ 아래 신규 PHP 파일 생성과 체크아웃 페이지 JS 변경을 감시 대상에 넣어두면, 침해 이후 단계에서라도 잡을 여지가 생김. 커머스는 카드 정보가 흐르는 곳이라 스키머가 붙는 순간 피해가 바로 금전으로 이어짐.

완화: 지금 당장 할 수 있는 순서

• 보안 패치 적용 — 어도비 보안 공지에 맞춰 해당 버전 라인의 업데이트를 올리는 게 유일한 근본 해결임. 나머지는 전부 시간 벌기임
• 관리자 URL 은닉과 IP 제한 — 관리 경로를 랜덤화하고, 가능하면 사무실·VPN 대역으로만 접근을 제한함. 이것만으로도 대량 스캐닝의 대부분이 걸러짐
• 관리자 계정 권한 분리 — 마케팅 계정에 레이아웃 XML 편집 권한까지 주고 있진 않은지 역할(Role) 설정을 다시 봄. 2FA는 예외 없이 전 계정 적용
• 웹 서버 아웃바운드 차단 — PHP-FPM 계정이 임의 외부 호스트로 나가지 못하게 막음. 템플릿 인젝션이 성공해도 2차 페이로드 다운로드 단계에서 끊김
• 디스크 쓰기 권한 최소화 — 웹 루트 대부분을 읽기 전용으로 두고 쓰기가 필요한 디렉터리만 예외 처리함. 여기서 PHP 실행을 막아두면 웹셸 시나리오가 상당히 무력해짐
• 서드파티 모듈 재점검 — 코어를 패치해도 확장 모듈이 자체 필터를 돌리면 구멍이 남을 수 있음. 템플릿 필터를 직접 호출하는 코드가 있는지 확인해볼 것

마무리하며

커머스 취약점을 볼 때마다 느끼는 건데, 이쪽은 다른 분야보다 패치까지 걸리는 시간이 유독 길다는 점이 진짜 문제인 것 같음. 쇼핑몰은 멈추면 매출이 바로 꺾이니까 "다음 정기 점검 때"로 미루기 쉽고, 그 사이 공격자는 자동화 스캐너로 이미 전 세계를 훑고 있음. 실제로 커머스 플랫폼 취약점은 공개 후 며칠 안에 대량 스캐닝이 시작되는 게 거의 공식처럼 굳어져 있음.

그래서 개인적으로 추천하는 건, 패치 창구를 미리 만들어두는 습관임. "긴급 보안 패치는 트래픽 최저 시간대에 30분 안에 적용한다"는 절차를 평소에 합의해두면, 막상 공지가 떴을 때 회의부터 하느라 하루를 날리는 일이 없어짐. 기술적 방어보다 조직적 준비가 결국 더 크게 작동하는 영역인 것 같기도 하고.

혹시 Magento나 Adobe Commerce를 운영 중이시라면, 오늘 관리자 계정 목록 한 번만 열어보시길. 퇴사한 외주 개발사 계정이 아직 살아있는 경우가 생각보다 많음. 저도 이번에 정리하면서 몇 개 발견했음. 여러분 환경에서는 어떤 항목이 제일 먼저 걸렸는지 댓글로 공유해주시면 같이 배워보아요!