jithinkrishnanrs/stylesmuggler-ioc-toolkitStyleSmuggler(CVE-2026-75650) Magento 오픈소스 및 Adobe Commerce용 IOC 툴킷. 손상된 스토어, Rust 임플란트, PHP 웹 셸, 지속성 아티팩트 및 알려진 침해 지표를 탐지합니다.
Magento 제로데이 · Adobe Commerce 제로데이 · CVE-2026-75650 · APSB26-146 · VULN-39341 · 비인증 RCE · Magento 악성코드 · Magento 백도어 제거 · Magento 2.4.9 취약점 · Rust 임플란트 · GraphQL styles 인젝션 · PHP 웹 셸
StyleSmuggler(CVE-2026-75650)에 대한 커뮤니티 침해 지표(IOC), 침해 스캐너, 그리고 완화/패치 지침입니다. 이 취약점은 Sansec이 2026년 9월 5일에 공개한 비인증 Magento Open Source / Adobe Commerce RCE이며, 2026년 9월 4일부터 실제 공격에서의 악용이 확인되었습니다. Adobe는 2026년 9월 7일에 공식 수정 버전인 APSB26-146을 발표했습니다. "StyleSmuggler IOC", "CVE-2026-75650", "APSB26-146", "VULN-39341", "Magento fc-cache malware", "Magento chronyd backdoor", "gvfsd-user Magento", "Magento GraphQL styles RCE"를 검색하셨다면, 바로 이 저장소가 원하시는 곳입니다.
이것은 방어용 툴킷입니다. 공개된 1차 사고 보고서를 바탕으로 작성된 탐지 시그니처, 침해 스캐너, 그리고 강화/차단 규칙을 포함합니다. 익스플로잇 코드, 개념 증명(PoC) 트리거, 또는 공격 페이로드를 생성하는 어떤 것도 포함하지 않습니다. 그런 것을 찾고 계신다면 잘못된 저장소에 오신 것입니다 — 대신 패치하고 헌팅하십시오.
| 취약점 | StyleSmuggler (Sansec의 명칭) — CVE-2026-75650 |
| 벤더 | Adobe (Magento Open Source, Adobe Commerce) |
| CVE | CVE-2026-75650, 2026-09-07 할당 |
| Adobe 게시판 | APSB26-146, 2026-09-07 20:20 UTC 게시, Priority 1 (최고 등급) |
| 추가로 필요한 항목 | APSB26-138 (Adobe의 정기 2026년 9월 Commerce 업데이트, 격리 패치 249-2026-09-001-CE, 2026-09-08 릴리스). Adobe는 VULN-39341을 이것을 대체하는 것이 아니라 추가로 적용해야 한다고 명시함. |
| CVSS | 10.0 (3.1 및 4.0) — Critical. 전체 3.1 벡터: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| CWE | CWE-1336, 템플릿 엔진에 사용되는 특수 요소의 부적절한 중화 |
| CISA KEV | 2026-09-08 CISA의 알려진 악용 취약점(KEV) 카탈로그에 추가됨. 연방 민간 행정부(FCEB) 조치 기한: 2026-09-11. CISA 항목은 또한 포렌식/IR 트리아지가 필요하다고 표시하며, 알려진 랜섬웨어 캠페인 사용 여부는 "Unknown"으로 기재됨. 더 이상 Magento 커뮤니티만의 문제가 아님 — 이제 연방 차원에서 추적되는, 실제로 악용 중인 RCE임. |
| 공식 패치 | 배포됨. 핫픽스 VULN-39341. 적용 범위가 보편적이지 않음 — 아래 표 참조. |
| 인증 필요 여부 | 없음 — 비인증 |
| 공개 익스플로잇 코드 | Adobe/Sansec의 공식 PoC는 없으나, 교차 보도에 따르면 전체 체인을 연구실에서 재현했다고 자처하는 공개 GitHub 저장소(약 9월 8일 생성)가 존재함 — "공개 익스플로잇 코드 없음"이라는 표현은 실제보다 약하게 들림. docs/VULNERABILITY.md 참조. |
| 영향받는 버전 | Sansec이 깨끗한 Magento Open Source 2.4.7, 2.4.8, 2.4.9에서 재현; 최초 확인된 피해자는 이전 패치까지 완전히 패치된 2.4.6-p15를 운영 중이었음 |
| 악용 | 2026-09-04 22:20 UTC부터 활성화; 패치 릴리스 이후에도 지속; 2026-09-14 기준 최소 세 개의 독립적인 툴킷이 동일한 진입점을 악용하는 것으로 확인됨. 한 익스플로잇 추적 네트워크는 9월 9일 이후 500개 이상의 서로 다른 소스 IP를 보고함. 서드파티 WAF 텔레메트리(Imperva)는 관측된 표적이 소매(~39.5%), 라이프스타일(~19.5%), 헬스케어(~17.9%)에 치우쳐 있다고 보고함 — 이는 개별 벤더의 가시성 스냅샷이며, 취약한 매장 전체 모집단에 대한 주장은 아님. |
| 알려진 Rust 임플란트 변종 | [kworker/u:8:0] (9월 4일) → fc-cache v2.1.4 (9월 6일) → chronyd v2.1.5 (9월 7일) — 동일 운영자, 동일 에이전트 ID, 버전 증가. chronyd 빌드는 cron 항목 없이 PID-1 부모를 가진 채 스스로 재실행되는 것이 관측됨. |
| 두 번째, 무관한 공격자 | pub/media/catalog/product/cache/ 내의 PHP 웹 셸, 그에 앞서 DNS 유출 정찰 프로브 — Rust 임플란트와 무관, 2026-09-07 확인 |
| 세 번째, 별개의 툴킷 | 2026-09-14 확인. 코어 프레임워크 파일 vendor/magento/framework/App/View.php에 직접 편집된 원격 파일 포함(RFI) 백도어로, 광고 기술 추적으로 위장한 쿠키(gl_google_advisor_824808)로 게이트됨. 요청 시 원격 페이로드를 가져와 실행한 뒤 임시 파일을 삭제함 — 요청 사이에 디스크에 남는 것은 벤더 파일 내 변조된 한 줄뿐임. |
| 이메일 없이 기폭 | 2026-09-14 확인. 두 번째 체인은 "결제 실패" 이메일을 전혀 렌더링하지 않고 POST /paypal/transparent/response/(쿼리 문자열 내 PHP 소스)를 통해 전체 코드 실행에 도달함 — 마커 MGPROOF::/MGKWSIM::, kwc 파라미터를 통한 직접 명령 실행. 이메일 트리거만을 중심으로 구축된 완화 조치는 이를 커버하지 못함. |
| 알려진 전달 벡터 | GraphQL styles[] 파라미터; var/log/system.log에 기록되는 잘못된 스토어 코드; Magento의 고객 사용자 정의 옵션을 통해 업로드된 파일; 무관한 두 번째 공격자의 Store: 헤더 주입; /paypal/transparent/response/ 쿼리 문자열 내 PHP 소스(이메일 독립적) |
| 영향 | 원격 코드 실행 → 지속적인 Rust 기반 백도어, 독립적인 PHP 웹 셸, 은밀한 프레임워크 수준 RFI 백도어, Redis 세션 수집, app/etc/env.php를 통한 자격 증명/비밀 정보 노출 |
| 제품 | APSB26-146으로 해결됨 | 공식 수정 없음 |
|---|---|---|
| Adobe Commerce (B2B, Cloud 포함) | 2.4.4 – 2.4.9 | 2.4.4 미만 |
| Adobe Commerce B2B | 1.3.3 – 1.5.3 | 1.3.3 미만 |
| Magento Open Source | 2.4.6 – 2.4.9만 해당 | 2.4.5 이하 |
지원이 종료된 구버전을 사용 중이라면, 똑같이 악용 가능한 상태임에도 Adobe는 수정
버전을 제공하지 않습니다. 선택 가능한 방안은 docs/PATCHING.md를
참고하세요 — Adobe의 Commerce 전용 핫픽스 패키지 대신 전용 긴급 릴리스(3.5.0)를
제공하는 Mage-OS 사용자를 위한 안내도 포함되어 있습니다.
이 정보는 빠르게 바뀝니다. 조치를 취하기 전에 기본 출처와 교차 확인하세요:
Sansec의 권고문 및
Adobe의 보안 공지.
진행 로그는 docs/TIMELINE.md를 참고하고, 이 문서의 내용을
수정할 때는 출처를 인용하세요.
Magento 자체의 GraphQL styles 파라미터와 의존성 주입 기반 파일 스캐닝이 파일 기반
지연 실행 프리미티브로 악용됩니다. 원래 문서화된 체인은 두 단계로 구성되지만 —
Sansec의 9월 14일 업데이트 기준으로 — 그것이 유일한 확인된 체인은 아니며, 기폭
단계가 항상 원래 2단계에서 설명한 것을 요구하지도 않습니다:
var/log/system.log — Magento가 그대로 기록하는 잘못된 스토어 코드를 통해,
또는 var/report/<hash>)에 도달합니다. 이는 GraphQL styles[] 파라미터, 변조된
요청 헤더, 또는 (아래의 두 번째, 무관한 공격자의 경우) Store: 헤더를 통해
밀반입됩니다.getProcessedTemplate 경로) Magento 자체의 DI/코드 스캐너가 오염된 파일을
include()하여 공격자의 PHP를 실행하게 되는 코드 경로를 거치게 됩니다. 이메일을
열 필요는 없습니다 — 서버 측에서 렌더링되는 것만으로 충분하며 — 메일 전송 자체가
실패하더라도 체인은 발동할 수 있습니다.도구 없이 확인 가능한 손쉬운 조기 경고 신호: 받은편지함에 렌더링되지 않은
{{var ...}} 태그가 그대로 노출되고 고객 주소가 .invalid로 끝나는, 깨진 형태의
"Payment Transaction Failed Reminder" 이메일이 도착하는 것입니다. 이는 누군가 로그를
확인하기 전에 나타나는 첫 번째 가시적 신호인 경우가 많습니다.
하지만 그 이메일만이 실행에 도달하는 유일한 방법은 아닙니다. Sansec은 이메일을
완전히 건너뛰는 두 번째의 독립적인 기폭 체인을 확인했습니다: 쿼리 문자열에 PHP
소스를 심은 POST /paypal/transparent/response/ 요청으로, 이는 MGPROOF::(실행
증명 확인, mgproof717.txt라는 파일과 함께) 또는 MGKWSIM::을 출력하는 페이로드가
관찰된 것으로 이어집니다 — 후자는 kwc 요청 파라미터로 base64 인코딩되어 도착하는
모든 것을 실행하는 직접적인 명령 실행 프리미티브로, 이메일은 어디에도 관여하지
않습니다. 실패한 결제 이메일을 감시하거나 비활성화하는 것만을 중심으로 구축된
완화책은 이 경로를 커버하지 못합니다.
Sansec의 업데이트는 동일한 Rust 임플란트 캠페인에 대한 두 번째의 독립적인 악용 경로도 확인했습니다: 세션 저장소를 Redis에서 데이터베이스로 옮긴 스토어조차 여전히 침해당했습니다 — 동일한 운영자의 두 번째 시도가 몇 초 후 Magento의 고객 사용자 정의 옵션(customer custom options) 기능을 통해 업로드된 파일을 사용하여 성공한 것입니다. 세션 저장소를 옮기는 것만으로는 해결책이 되지 않습니다.
별도로, 9월 7일 Sansec은 완전히 무관한 공격자를 발견했습니다. 이 공격자는 정확히 동일한 StyleSmuggler 진입점을 사용했지만 훨씬 단순한 페이로드를 사용했습니다. Magento 자체의 제품 이미지 캐시(pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php)에 PHP 웹 셸을 드롭했으며, 그에 앞서 페이로드를 Store: HTTP 헤더에 숨기고 발견한 내용을 HTTP 응답이 아닌 DNS를 통해 유출하는 정찰 프로브를 실행했습니다. Sansec에 따르면 이는 "기성 도구"이며 지속적인 캠페인은 아니지만, 취약한 호스트 하나가 하나의 결함을 통해 두 개의 무관한 침입을 겪을 수 있다는 의미입니다. Rust 임플란트를 정리했다고 해서 스토어가 깨끗하다는 뜻은 아닙니다.
그리고 9월 14일, Sansec은 세 번째로 별개의 툴킷을 확인했습니다. 이는 위의 두 가지와도 또 다릅니다. 새 파일을 드롭하는 대신 Magento 핵심 벤더 파일(vendor/magento/framework/App/View.php)을 직접 편집하여, 쿠키(gl_google_advisor_824808)로 게이트되는 온디맨드 원격 파일 포함 백도어를 추가했으며, 이를 의도적으로 광고 기술 추적으로 위장했습니다. 쿠키가 존재하면 백도어는 그 값을 URL로 base64 디코딩하여 가져오고, 응답을 /tmp/tmp.log에 기록하고, 실행한 뒤 즉시 삭제합니다. 따라서 요청 사이에 디스크에 남는 것은 벤더 파일의 변조된 한 줄 외에는 아무것도 없습니다. pub/media 스윕으로는 이 백도어를 절대 잡을 수 없습니다. 벤더 파일 무결성을 직접 확인해야 합니다.
Rust 임플란트 자체도 진화했습니다. 원래의 [kworker/u:8:0] 위장 빌드(9월 4일)에 이어 NTP 트래픽으로 위장하여 비콘을 보내는 fc-cache 위장 빌드 v2.1.4(9월 6일)가 나타났고, 그다음 동일한 임플란트, 동일한 에이전트 ID의 chronyd 위장 재배포 v2.1.5(9월 7일)가 이어졌습니다. 이는 공격자가 공개하는 탐지 수단을 회피하기 위해 적극적으로 반복 개선하고 있다는 증거입니다. chronyd 빌드는 또한 cron 항목 없이, 부모 프로세스 ID가 1인 상태로 스스로 재실행되는 것이 관찰되었으며, 이는 이름 변경이 cron에 의해 트리거된 것이 아니라 자체적으로 시작되었음을 시사합니다. 빈 crontab은 이 빌드에 대해 호스트가 깨끗하다는 증거가 아닙니다. Sansec은 이 임플란트가 지속성/정찰 이상으로 무기화되었다는 증거를 아직 보지 못했다고 밝혔습니다. 그러나 무관한 공격자의 작동하는 웹 셸과, 이제 동일한 접근 경로에서 세 번째 툴킷의 작동하는 백도어가 있는 상황에서 이를 안심의 근거로 받아들여서는 안 됩니다.