Magento 이메일 템플릿 렌더링 미인증 원격 코드 실행 취약점 (CVE-2026-75650)

NOW Briefing

Brief 1 전자상거래 플랫폼 Magento와 Adobe Commerce의 이메일 템플릿 처리에서 인증 없이 서버 코드를 실행할 수 있는 원격 코드 실행(RCE) 제로데이 취약점(CVE-2026-75650)이 확인됐습니다. 보안 업체 Sansec은 2026년 9월 4일부터 이 취약점이 실제 공격에 악용되고 있다고 밝혔습니다.

Brief 2 공격자는 로그인 없이 상점 서버에서 임의의 PHP 코드를 실행할 수 있습니다. 실제 침해 사례에서는 Rust로 작성된 리눅스 백도어와, 별도 공격자가 설치한 원격 조작용 스크립트(웹셸)가 관측됐습니다.

Brief 3 Adobe가 9월 7일 배포한 긴급 핫픽스 VULN-39341을 즉시 적용하고, 암호화 키 교체와 함께 관리자 비밀번호·API 토큰 등 관련 자격증명을 발급처에서 재발급해야 합니다. 9월 4일 이후 인터넷에 노출된 상점은 침해 가능성을 전제로 우선 점검해야 합니다.

‍

Magento 이메일 템플릿 렌더링 미인증 원격 코드 실행 취약점 (CVE-2026-75650)

‍

■ 개요

‍

Magento Open Source와 Adobe Commerce는 상품·주문·결제·회원 관리 기능을 갖춘 전자상거래 사이트 구축 플랫폼입니다. 이번 취약점은 Adobe Commerce 2.4.4~2.4.9, Adobe Commerce B2B 1.3.3~1.5.3, Magento Open Source 2.4.4~2.4.9에 영향을 줍니다.

공격은 인증이나 사용자 조작 없이 상점의 공개 인터페이스만으로 성립합니다. 상점이 스스로 만들어 발송하는 결제 실패 알림 메일을 서버가 렌더링할 때 공격자가 심어둔 PHP 코드가 실행되고, 웹 서버 권한으로 임의 명령까지 수행할 수 있습니다. Sansec은 9월 7일 최신 보안 패치를 적용한 2.4.7-p10 상점을 겨냥한 공격 시도를 관측해 자사 방어 제품으로 차단했으며, 당시 패치 수준으로는 방어되지 않는다고 설명했습니다.

Adobe는 이 취약점을 최우선 등급으로 분류하고 정식 릴리스가 아닌 긴급 핫픽스로 대응했습니다. 9월 4일 22시 20분(UTC) 최초 악용이 확인됐고, 9월 5일 Sansec이 패치가 없는 상태에서 긴급 공지를 냈으며, 9월 7일 20시 20분(UTC)에 Adobe 핫픽스가 배포됐습니다. 그 사이 노출된 상점은 패치 적용과 침해 조사를 함께 진행해야 합니다.

‍

■ 요약

‍

항목	내용
CVE ID	CVE-2026-75650 (이메일 템플릿 렌더링 중 인증 없이 코드 실행)
CVSS 점수	CVSS v3.1 10.0
취약점 유형	CWE-1336, 템플릿 엔진 입력 미차단으로 인한 원격 코드 실행
영향/위험	• 미인증 원격 공격자의 임의 PHP 코드 실행 가능 • 실제 공격에서 Rust 기반 리눅스 백도어 설치 관측됨 • 별도 공격자의 PHP 웹셸 설치 관측됨 • 최신 패치(2.4.7-p10)를 적용한 상점을 겨냥한 공격 시도 관측·차단됨(Sansec 기준)
취약 버전	• Adobe Commerce 2.4.4~2.4.9 (2026년 8월 릴리스 이하) • Adobe Commerce B2B 1.3.3~1.5.3 (2026년 8월 릴리스 이하) • Magento Open Source 2.4.4~2.4.9 (2026년 8월 릴리스 이하)
패치 버전	• 정식 릴리스 없음 • Adobe 긴급 핫픽스 VULN-39341을 의존성 관리 도구(Composer) 패치로 적용 필요(APSB26-146)

‍

■ 기술 분석

‍

Magento의 이메일 템플릿은 본문과 스타일(CSS) 값을 문자열로만 다룬다는 전제로 설계돼 있습니다. 그런데 템플릿 스타일 값을 저장하는 통로가 별도 검증 없이 데이터 객체에 값을 담는 방식이어서, 문자열 대신 배열이 들어와도 그대로 보관됐습니다. 이 배열이 템플릿 렌더링 경로로 전달되면 정상 클래스들을 이어 붙여 의도치 않은 동작을 끌어내는 가젯 체인의 입력이 되고, 최종적으로 서버에서 공격자가 심어둔 PHP 코드가 실행됩니다. 취약점 이름 'StyleSmuggler'는 스타일 속성을 통로로 코드를 밀반입한다는 뜻입니다.

Sansec이 공개한 공격 흐름은 두 단계입니다. 먼저 공격자는 상점의 공개 API인 GraphQL 등으로 비정상 요청을 보내 Magento가 스스로 남기는 오류 리포트 파일에 PHP 문자열이 기록되게 만듭니다. 이어서 결제 실패 알림 메일이 서버에서 렌더링될 때 그 오염된 코드가 실행됩니다. 가젯 체인의 상세 분석은 Sansec이 후속 공개 예정이라고 밝혀, 현재 공개 정보로는 중간 단계의 세부 구현까지 확정되지 않았습니다.

Adobe 핫픽스는 두 곳을 고칩니다. 하나는 관리자 이메일 템플릿 미리보기 블록에 권한 검사를 추가한 것이고, 다른 하나는 템플릿 본문·스타일 값에 명시적인 세터를 정의해 문자열이 아닌 입력을 빈 문자열로 강제한 것입니다.

아래는 핫픽스 패치 원문(unified diff) 가운데 Magento\Email\Model\AbstractTemplate에 새로 추가된 두 세터 부분입니다. 이 클래스에는 원래 두 세터가 정의돼 있지 않아 배열 입력이 걸러지지 않았고, Magento 공개 저장소의 2.4-develop 브랜치에서도 두 메서드 정의는 확인되지 않습니다. 아래 diff는 Adobe 핫픽스 패치 파일을 커밋 고정 형태로 재배포한 저장소에서 확인한 것입니다.

+    public function setTemplateText($value)
+    {
+        return $this->setData('template_text', is_string($value) ? $value : '');
+    }
+
+    /**
+     * Set template styles
+     *
+     * Rejects non-string input
+     *
+     * @param mixed $value
+     * @return $this
+     */
+    public function setTemplateStyles($value)
+    {
+        return $this->setData('template_styles', is_string($value) ? $value : '');
+    }

‍

■ PoC

‍

공개된 검증용 PoC는 연구자 dinosn이 배포한 Docker 기반 검증 랩입니다. 이 랩은 컴포넌트 수준에서 PHP가 실행되는지와 핫픽스 적용 전후 동작 차이만 재현하며, 인터넷에서 바로 실행할 수 있는, 인증 없이 성립하는 HTTP 공격 체인은 포함하지 않습니다. 페이로드는 /tmp에 무작위 이름의 마커 파일 하나를 쓰는 것이 전부이고, 명령 실행이나 외부 통신 기능은 없습니다. 지정된 환경변수와 Docker 컨테이너 안이 아니면 실행 자체를 거부합니다.

아래 코드는 공개 PoC의 component_probe.php에서 판정 결과를 출력하는 부분입니다. 마커 파일이 생성되고 내용이 일치하는지 확인한 뒤 결과를 JSON으로 출력합니다. 코드는 수정하지 않고 그대로 옮겼습니다. 전체 코드는 참고 자료의 원문에서 확인할 수 있습니다.

$observed = is_file($markerFile)
    && hash_equals($markerValue, (string) file_get_contents($markerFile));

echo json_encode(
    [
        'probe' => 'marker-only component code execution',
        'target' => 'Magento 2.4.9 email-template rendering component',
        'execution_observed' => $observed,
        'payload_capability' => 'write one nonce-bound file in /tmp',
        'network_callback' => false,
        'command_execution' => false,
        'exception' => $thrown,
    ],
    JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES
) . PHP_EOL;

$cleanup();
exit($observed ? 0 : 2);

⚠️ WARN

실제 공격이 진행 중인 취약점이므로 운영 상점이나 운영망과 연결된 스테이징에서는 검증을 시도하지 않아야 합니다.
패치 적용 여부는 재현 대신 vendor/bin/magento-patches -n status 출력으로 확인하는 것이 안전합니다.

‍

■ 탐지 및 점검

‍

• var/report/ 아래 리포트 파일에 주입 흔적이 남았는지 점검합니다. Sansec은 grep -ril 'x_trace_' var/report/로 해당 문자열을 포함한 리포트 파일을 찾도록 안내합니다.

• pub/media 하위에 PHP 파일이 존재하는지 파일 시스템에서 직접 확인합니다(find pub/media -name '*.php'). 관측된 웹셸은 pub/media/catalog/product/cache/ 아래 무작위 이름으로 놓이고 X-Cache-Token 헤더가 없는 요청에는 404를 반환하므로, 브라우저로 접근해 보는 방식으로는 판별할 수 없습니다.

• 정상 시스템 프로세스로 위장한 백도어를 찾습니다. kworker, fc-cache, chronyd 이름의 비정상 프로세스와 13,43 * * * * 형태로 두 번씩 재기동하는 예약 실행(크론) 항목이 대표 지표입니다.

• 결제 실패 알림 메일(Payment Transaction Failed Reminder) 발송량이 급증했는지 확인합니다. 정상적인 결제 거절과 동일한 메일이 발송되므로, 개별 메일이 아니라 짧은 시간 내 급증 패턴으로 판단해야 합니다.

• 아웃바운드 통신에서 UDP 123번 포트로 나가는 시각 동기화 프로토콜(NTP) 모양의 비콘과 TLS 443 연결을 점검합니다. Sansec 분석에 따르면 서버에 심어진 악성 모듈(임플란트)은 60초마다 ntp.timesync.to를 조회해 48바이트 UDP 패킷을 123번 포트로 보내고, 99.84.67.186:443으로는 TLS 위의 WebSocket으로 통신합니다. 방화벽·NetFlow 로그로는 목적지와 포트만 확인되므로 실제 페이로드 검증에는 전체 패킷 캡처가 필요합니다.

✅ CHECK

해시와 공격자 IP 전체 목록은 참고 자료의 Sansec 원문 IoC 항목에서 확인하시기 바랍니다.
프로세스 이름이나 파일명만으로는 침해를 확정할 수 없으므로, 리포트 파일 주입 흔적·웹셸 파일·아웃바운드 비콘 중 둘 이상이 함께 관측되는지로 판단합니다.

‍

■ 대응 방안

‍

• Adobe가 배포한 VULN-39341-composer-patches.zip을 repo.magento.com에서 내려받아 Composer 패치로 적용하고, vendor/bin/magento-patches -n status 출력으로 적용 여부를 확인합니다.

• 핫픽스는 2026년 8월 릴리스 기준으로만 검증했으므로, 유지보수 모드로 전환하고 크론을 중지한 상태에서 적용한 뒤 캐시를 비우고 서비스를 재개하는 순서로 진행합니다.

• 암호화 키를 교체하는 것만으로는 부족하므로, 관리자 비밀번호, API 토큰, 결제 게이트웨이 자격증명, 데이터베이스 비밀번호, SSH 키, 외부 연동 시크릿을 각 발급처에서 새로 발급받아야 합니다.

• 9월 4일 이후 인터넷에 노출돼 있던 상점은 침해 가능성을 전제로 우선 조사하고, 백도어나 웹셸을 삭제하기 전에 로그와 파일 사본을 먼저 보존합니다.

• 패치를 즉시 적용하기 어려운 환경에서는 Sansec이 안내한 대로 실시간 공격 차단과 임플란트 스캔을 병행하고, 결제 실패 알림 메일 급증 같은 이상 징후를 모니터링해야 합니다. 커뮤니티가 배포한 웹 서버 차단 규칙 등 임시 대응책은 핫픽스 적용을 대체할 수 없습니다.

‍