패치 없는 Magento·Adobe Commerce 제로데이 취약점, 온라인 쇼핑몰 백도어 공격에 악용 중

공격자들이 Magento 오픈소스와 Adobe Commerce의 새로운 미패치 취약점을 악용하고 있다. 이 취약점을 이용하면 로그인 없이도 온라인 쇼핑몰 서버에서 악성 코드를 실행할 수 있다. 네덜란드의 전자상거래 보안 기업 Sansec이 9월 5일 공개한 권고문에 따른 내용이다.

이 취약점을 발견하고 StyleSmuggler로 명명한 Sansec은 공격이 9월 4일부터 시작됐다고 밝혔다. "현재 진행 중인 쇼핑몰 침해 사태 때문에 조기 공개를 결정했다"고 회사는 밝혔다.

9월 6일 현재 Adobe는 공식 권고문, CVE 식별자, 패치, 또는 임시 해결 방법을 발표하지 않았으며, Adobe Commerce 보안 게시판 색인에도 8월 11일 업데이트 이후 새로운 내용이 없다.

공격에 성공하면 공격자는 쇼핑몰 서버에서 코드를 실행하고 지속적인 백도어를 설치할 수 있다. Sansec은 2.4.9를 포함한 모든 현재 버전이 영향을 받으며, Magento 오픈소스 2.4.7, 2.4.8, 2.4.9 클린 설치 환경에서 인증 없는 전체 공격 체인을 재현했다고 밝혔다.

첫 번째 피해 쇼핑몰은 Adobe의 2026년 7월·8월 보안 업데이트가 적용된 2.4.6-p15를 운영 중이었다. 이는 해당 릴리스 계열에서 Adobe가 제공하는 최신 패치 수준으로, Adobe의 8월 게시판에서 '2.4.6-2026-aug'로 표기된 버전이다.

Sansec은 Adobe Commerce 또는 클라우드 버전의 Adobe Commerce에 대한 재현 결과는 공개하지 않았으며, Adobe도 영향을 받는 버전을 확인하지 않았다. Sansec은 침해된 쇼핑몰 수도 공개하지 않았다.

연구진이 자사 Shield 제품을 사용하지 않는 쇼핑몰에 제시한 임시 조치는 Adobe가 임시 수정을 배포할 때까지 GraphQL을 비활성화하는 것이다.

Magento 호스팅·개발사 Disrex Group은 침해된 쇼핑몰 두 곳에 대응하면서, headless 및 PWA(프로그레시브 웹 앱) 스토어는 GraphQL이 필수인 반면 대부분의 클래식 스토어와 Hyvä 스토어는 그렇지 않다고 설명했다.

Adobe의 다음 정기 보안 릴리스는 9월 8일 예정이라고 Sansec은 밝혔으며, 해당 릴리스에서 이 취약점이 다뤄질지는 아직 알 수 없다.

Disrex의 조사 결과는 Sansec 외부에서 확인된 독립적인 악용 증거다. 9월 5일 공개된 인시던트 대응 저장소에서 Disrex는 9월 5일에 침해된 쇼핑몰 두 곳과 공격을 받았으나 침해되지 않은 세 번째 쇼핑몰에 대응했으며, 웹서버 규칙은 침해된 쇼핑몰 중 한 곳에서 포착한 공격 트래픽을 기반으로 작성됐다고 밝혔다.

해당 쇼핑몰은 Magento 2.4.7-p2를 운영 중이었다. Adobe의 버전 이력에 따르면 이 보안 패치 수준은 2024년 8월에 출시된 것으로, 현재 최신 버전인 2.4.7-p10보다 8단계 뒤처진 버전이다. Disrex가 Store A로 지칭한 이 쇼핑몰은 Sansec Shield 고객이었으며, Sansec의 첫 번째 차단 규칙이 적용되기 몇 시간 전인 9월 4일 23:10 UTC에 공격을 받았다.

해당 저장소에는 자체 경고 문구가 포함돼 있다. README에는 "이 저장소는 라이브 인시던트 진행 중 몇 시간 만에 AI 도움을 받아 작성됐다"고 명시돼 있으며, 검토가 이루어지지 않았고 Apache 규칙은 실제 Apache 서버에서 실행된 적이 없으며 대부분의 정리 명령도 실행이 아닌 작성에 그쳤다고 덧붙였다.

Sansec의 침해 지표에 따르면, 임플란트(백도어 프로그램)는 Linux 커널 스레드 이름인 [kworker/u:8:0]으로 위장한 백그라운드 프로세스로, 웹 루트가 아닌 사이트 사용자 홈 디렉터리의 ~/.local/share/.gvfsd/gvfsd-user 경로에 바이너리가 설치되고 5분마다 재시작하는 cron 항목이 추가된다.

Disrex는 해당 바이너리가 x86-64 및 arm64용으로 빌드된 약 1.9 MB 크기의 심볼 제거·정적 링크된 Rust 프로그램이라고 설명했다. 또한 cron 항목이 /var/spool/cron/crontabs/의 스풀 파일에 직접 기록되기 때문에 시스템 로그에 crontab 교체 기록이 남지 않는다고 밝혔다.

한 쇼핑몰에서는 같은 항목이 1,728번 기록됐으며, 임플란트는 제거 후 1초 이내에 항목을 다시 추가했다.

두 쇼핑몰 중 한 곳에서 임플란트는 외부로 아무런 연결을 하지 않았다. 쇼핑몰 자체의 Redis 인스턴스 포트 6379로만 28개의 연결을 유지하며 Magento의 세션 스토리지를 읽었다고 Disrex는 밝혔다. 또한 임플란트가 실행 중인 상태에서 각각 200 MB 이상 수집한 두 번의 패킷 캡처에서 Sansec이 공개한 다운로드 호스트 또는 C2(명령·제어 서버) 주소로의 패킷은 단 한 건도 발견되지 않았다.

Sansec은 규칙 적용 전에 공격을 받은 Shield 고객들의 경우 백도어가 실제로 사용됐다는 징후가 없으며, 해당 프로세스가 확인된 경우 Magento 자격증명을 교체할 것을 권고했다.

Sansec의 개요에 따르면 공격은 두 단계로 이루어진다. 먼저 Magento가 오류 보고서 생성 등의 작업에서 직접 작성하는 파일에 PHP 코드를 심는다. 그런 다음 플랫폼의 표준 '결제 트랜잭션 실패 알림' 이메일을 트리거하여 Magento가 해당 파일을 실행하도록 만든다. 코드는 Magento가 메시지를 렌더링하는 동안 실행되므로 누군가가 이메일을 열 필요가 없으며, 이메일 전송이 실패해도 공격이 성공할 수 있다.

Sansec은 전체 익스플로잇 체인을 아직 공개하지 않았으며, 체인·드로퍼·임플란트에 대한 상세 분석은 향후 업데이트로 제공할 예정이라고 밝혔다.

Disrex가 공개한 규칙과 함께 게시된 메커니즘 분석에 따르면, 삽입된 텍스트 내 지시문이 Magento 자체 클래스들을 연쇄 실행해 커맨드라인 의존성 주입(DI) 컴파일러를 위한 코드로 유도한다.

해당 코드는 최종적으로 공격자가 선택한 파일 경로, 즉 직전에 오염시킨 로그 파일을 포함시킨다. 실행된 PHP 드로퍼는 프로세스를 시작하기 위해 6가지 PHP 함수를 순서대로 시도한 후 임플란트를 다운로드하여 실행한다. Disrex는 체인이 종료되는 지점으로 setup/src/Magento/Setup/Module/Di/Code/ 아래의 파일 세 개를 지목했다. Sansec은 해당 분석을 확인하지 않았으며, Disrex도 조합된 요청을 공개하지 않았다.

1단계에서 두 위치가 중요하다. Sansec의 공개 검사 스크립트는 var/report/에서 마커 X_TRACE_를 검색한다. 그러나 Disrex는 자사가 대응한 두 건의 감염 모두 var/report/ 대신 var/log/system.log를 통해 오염됐으며, Sansec의 검사로는 탐지되지 않았을 것이라고 밝혔다. 따라서 두 디렉터리 모두 검색해야 한다.

마커는 이미 변형되고 있다. Disrex는 9월 5일 오전에는 X-TRACE- 뒤에 16진수 10자리가 붙는 트리거 헤더를, 오후에는 TRACE라는 단어 없이 같은 헤더를 관측했다. 따라서 검색 시 정확한 문자열이 아닌 패턴 형태로 매칭해야 한다.

system.log의 include 직후 정수 인수를 사용한 array_merge()에서 발생한 TypeError는 익스플로잇 성공의 증거라고 Disrex는 밝혔다. 다만 더 은밀한 변형은 빈 배열을 반환하여 로그에 아무것도 남기지 않는다.

프로세스 확인 방법과 관련해서 Disrex는, 정상적인 커널 스레드는 root 소유이며 상주 메모리가 없으므로 실제 메모리를 사용하는 사이트 사용자 소유의 대괄호 이름 프로세스가 임플란트라고 설명했다. 임플란트는 자신의 커맨드 라인을 해당 대괄호 문자열로 설정하므로, 프로세스의 comm 필드를 기준으로 작성된 검사에는 탐지되지 않는다.

Disrex는 또한 한 쇼핑몰에서 메모리에서 실행 중인 바이너리가 디스크의 파일과 다른 빌드였다는 사실을 발견하고, 파일 경로와 함께 /proc/<pid>/exe에서 실행 중인 프로세스도 해싱하여 비교할 것을 권고했다. Sansec은 '결제 트랜잭션 실패 알림' 이메일이 예상치 못하게 대량 발송된다면 조사가 필요하다고 밝혔다. 다만 정상적인 결제 거절도 동일한 알림을 발생시킨다.

Sansec과 Disrex의 침해 지표 목록에 공개된 지표는 다음과 같다:

• 프로세스: 비루트 사용자 소유의 [kworker/u:8:0]
• 파일: ~/.local/share/.gvfsd/gvfsd-user
• 파일: ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
• 파일: /tmp/.gvfsd_<8hex>.lock
• 파일: /tmp/.kw_<random><random>
• Cron: */5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user (및 /tmp/.kw_를 가리키는 변형)
• SHA-256: e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 (Sansec 샘플)
• SHA-256: 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef (Disrex 두 쇼핑몰 디스크에서 발견)
• SHA-256: 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 (Disrex 한 쇼핑몰 메모리에서 실행 중)
• 도메인: 247.cdnflare[.]xyz (악성코드 다운로드 호스트)
• IP: 99.84.67[.]186:443 (Sansec 분석 기준, WebSocket·TLS를 통한 C2)
• IP: 88.216.72[.]181 (Sansec 분석 기준 공격자 소스)
• IP: 5.181.86[.]133 (Disrex 분석 기준, 대량 발송 공격자 소스)

Sansec은 임플란트 탐지를 위해 자사의 eComscan 스캐너 사용을 권고하며, 버전 1.9.7은 Shield 고객에 한해 프로세스를 종료할 것이라고 밝혔다.

Disrex는 한 쇼핑몰에서 반대 결과를 보고했다. 임플란트가 실행 중이고 cron 항목이 1,728개 존재하는 상태에서 백그라운드 프로세스 및 예약 작업 검사를 활성화하여 eComscan을 실행했으나 스토어가 '정상'으로 보고됐다고 밝혔다. Disrex는 실행된 eComscan 버전이나 실행 시점은 명시하지 않았다.

현재 설치 가능한 공식 패치는 없다. Adobe가 패치를 배포하기 전까지 선택 가능한 조치는 다음과 같다: Sansec의 임시 GraphQL 비활성화, Disrex·ProxiBlue·Graycore가 각각 공개한 비공식 완화 조치 3종, 그리고 취약점과 무관하게 적용 가능한 서버 설정 2가지.

Disrex는 익스플로잇의 URL 쿼리 문자열 파라미터를 차단하는 nginx 및 Apache 규칙을 공개했다. 그러나 Disrex가 실제 쇼핑몰에서 직접 테스트한 결과, POST 본문이나 JSON 본문으로 동일한 파라미터를 전송하면 PHP까지 도달했다. nginx와 Apache는 쿼리 문자열만 검사하기 때문이다. Disrex는 이 규칙이 취약점 자체를 차단하는 것이 아니라 현재 진행 중인 공격 캠페인을 차단하는 수준이라고 설명했다.

Disrex의 주요 완화 조치는 Magento의 의존성 주입 코드 스캐너 세 가지 메서드에 검사를 추가하여 커맨드라인 외부에서는 실행되지 않도록 방지하는 것이다. 이 수동 편집은 모든 composer install 시 초기화되므로, Disrex는 배포 시 자동 재적용되는 composer-patches 소스 패치로도 제공하며 2.4.6부터 2.4.9까지 변경 없이 적용 가능하다고 밝혔다.

세 파일 중 하나인 ClassesScanner.php는 서드파티 모듈 mageplaza/module-admin-permissions에 의해 HTTP를 통해 호출되며, 이를 보호하면 해당 모듈의 관리자 화면이 중단된다. 따라서 Disrex는 관리자들에게 수정 전 vendor 디렉터리를 먼저 검색할 것을 권고했다.

해당 보호 조치는 실제 운영 스토어가 아닌 테스트 환경에서 검증됐으며, Disrex는 이것만으로는 완전한 수정이 아니라고 밝혔다. GitHub 사용자 ProxiBlue도 9월 5일 동일한 보호 조치와 비공식 패치 3종을 공개했다. Sansec과 Adobe 모두 해당 스캐너가 체인의 종착점이라는 점을 확인하지 않은 상태다.

Graycore, LLC는 9월 5일 GitHub와 Packagist에 Magento 모듈을 공개했다. Graycore에 따르면 현재 코드는 체인의 세 지점을 강화한다: 이메일 템플릿 블록 지시문이 백엔드 블록을 거부하고, 그리드 행 URL 생성기가 클래스 생성 전 검증하며, Web API 치명적 오류 보고서의 PHP 여는 태그가 무효화된다.

작성 시점에 Packagist에 올라온 버전은 이전 릴리스로, 유일한 완화 조치는 이후 제거된 PayPal GraphQL 리졸버를 대상으로 한 것이었다. README에는 "이것은 강화(hardening)이지 수정(fix)이 아니다"라고 명시돼 있으며, 취약점을 통한 다른 경로가 여전히 열려 있고 스토어가 이미 침해됐을 수 있다고 경고한다.

Disrex는 취약점 체인과 전혀 무관하게 적용할 수 있는 서버 설정 두 가지를 제시했다. 두 쇼핑몰 중 한 곳에서는 드로퍼가 시도한 6가지 PHP 함수 중 처음 네 개가 비활성화돼 있었다. 그러나 proc_open은 비활성화되지 않아 드로퍼가 이를 사용해 임플란트를 시작했으며, open_basedir도 자식 프로세스를 억제하는 데 아무런 효과가 없었다.

Disrex가 저장소의 모든 규칙보다 우선시하는 조치는 PHP의 disable_functions에 proc_open을 추가하고, /tmp·/var/tmp·/dev/shm을 noexec 옵션으로 마운트하여 다운로드된 바이너리가 실행되지 않도록 하는 것이다.

이미 감염된 쇼핑몰의 경우 Disrex의 정리 가이드는 다음 순서를 제시한다: 증거를 먼저 보존하고, 프로세스를 종료하기 전에 cron 항목을 먼저 제거할 것(프로세스가 cron을 복원하기 때문), 재부팅을 하지 말 것(/proc 아래의 사본이 유일하게 남은 바이너리일 수 있기 때문), 정리를 위해 composer install을 실행하지 말 것(수정된 파일의 타임스탬프가 덮어써지기 때문).

이후 세션 스토리지를 플러시하고, app/etc/env.php의 crypt/key를 교체하며, 해당 파일의 모든 관리자 비밀번호, 결제 사업자 API 키, 기타 모든 연동 자격증명을 교체할 것을 권고한다.

호스팅 사업자 Nexcess와 Liquid Web은 9월 5일 동일한 내용의 사고 공지를 게시하며 서버 환경을 검토 중이며 예방 조치를 시행하고 있다고 밝혔다.

두 회사 모두 고객 침해가 확인됐거나 자체적으로 취약점을 재현했다고 주장하지는 않았다. Disrex는 두 쇼핑몰에서 26개의 서로 다른 소스 주소를 기록했는데, 그중 두 곳은 대량 발송 호스팅 인프라이고 나머지는 각각 2~6건씩 요청을 보낸 주거용 프록시 풀이었다. Sansec의 권고문에 명시된 단일 공격자 주소를 차단했더라면 Disrex가 관측한 트래픽의 25% 미만만 차단할 수 있었을 것이라고 밝혔다. 현재까지 어느 소스도 공격자의 신원을 특정하지 못했다.

The Hacker News는 Adobe, Sansec, Disrex, Graycore에 논평을 요청했으며, 답변을 받는 대로 기사를 업데이트할 예정이다.