Adobe Commerce 제로데이 패치 공개…암호화 키만 바꾸면 부족하다

Adobe는 2026년 9월 7일 Adobe Commerce와 Magento Open Source의 제로데이 취약점 CVE-2026-75650을 막는 핫픽스 VULN-39341을 공개했다. Adobe 긴급 업데이트 문서 는 인증되지 않은 공격자가 영향받는 설치에서 임의 코드를 실행할 수 있고 실제 공격도 확인됐다며, 패치 후 암호화 키와 노출 가능 자격 증명을 함께 교체하도록 지시한다.

관리자는 9월 7일 공개된 핫픽스를 적용하는 데서 대응을 끝내면 안 된다. Tenable의 9월 8일 분석 에 따르면 공격은 패치가 나오기 사흘 전인 9월 4일부터 관측됐으므로, 버전과 패치 상태 확인에 이어 침해 조사, 악성 지속성 제거, 암호화 키와 결제·API·데이터베이스·SSH 자격 증명 교체까지 진행해야 한다.

영향 버전과 핫픽스 검증 범위는 다르다

영향 범위는 Adobe Commerce 2.4.4~2.4.9 계열의 2026-aug 및 이전 버전이다. Adobe Commerce B2B는 1.3.3, 1.3.4, 1.4.2, 1.5.2, 1.5.3 계열의 2026-aug 및 이전 버전이 포함된다. Magento Open Source는 2.4.6~2.4.9 계열의 2026-aug 및 이전 버전이 대상이다.

운영자는 관리 화면의 제품 버전만 보지 말고 Composer 잠금 파일, 배포 기록, 적용한 로컬 패치까지 대조해야 한다. 기존 누적 보안 패치의 상태가 정상이어도 VULN-39341이 별도로 배포됐다는 뜻은 아니다.

핫픽스가 공식적으로 시험된 범위는 각 영향 계열의 2026-aug 빌드다. 같은 지원 계열의 더 오래된 빌드에서도 작동할 수 있지만 검증된 조합은 아니므로, 복제한 스테이징 환경에서 Composer 충돌과 주문·결제·이메일 처리의 회귀 여부를 확인해야 한다.

VULN-39341은 배포와 상태 확인까지 끝내야 한다

패치 파일은 VULN-39341-composer-patches.zip으로 제공된다. 현재 코드와 데이터베이스를 백업하고 설치 버전과 기존 로컬 패치 목록을 기록한 뒤, 운영 환경과 같은 배포 브랜치에서 압축을 풀어 Composer 패치 절차에 포함한다. 로드밸런서 뒤의 모든 노드에 동일한 산출물이 배포됐는지도 확인해야 한다.

1. 복제 환경에 핫픽스를 적용하고 Composer 오류와 핵심 거래 흐름의 회귀를 점검한다.
2. 검증된 변경을 전체 운영 노드에 배포하고 노드별 코드와 배포 로그를 대조한다.
3. Adobe Commerce on Cloud에서는 Quality Patches Tool을 설치한 뒤 vendor/bin/magento-patches -n status | grep "39341\|Status"를 실행한다.
4. VULN-39341_Hotfix_COMPOSER.patch가 Applied로 표시되는지 확인하고 결과를 보존한다.

이 상태 확인 명령은 Commerce on Cloud 환경을 대상으로 제시됐다. 온프레미스 운영자는 같은 출력을 보편적인 검증 기준으로 삼지 말고 Composer 적용 기록, 실제 변경 파일과 각 서버의 배포 결과를 확인해야 한다. 일부 노드에 이전 코드가 남아 있다면 공격 경로도 남아 있을 수 있다.

패치 뒤에는 프로세스·cron·웹셸을 구분해 찾는다

핫픽스는 새로운 취약점 악용을 차단하지만 이미 실행 중인 백도어나 웹셸을 제거하지 않는다. 의심 징후가 발견되면 호스트를 결제·관리 트래픽에서 격리하고, 프로세스·네트워크 연결·파일 생성 시각과 웹 서버 및 애플리케이션 로그를 보존한 상태에서 사고 대응 범위를 정해야 한다.

Sansec의 StyleSmuggler 분석 은 템플릿의 styles 속성을 통한 PHP 코드 주입과 결제 실패 알림 이메일 렌더링을 거친 실행 경로를 재현했다. 최초 공격 계열은 Rust 기반 백도어를 설치해 [kworker/u:8:0], fc-cache, chronyd 같은 이름으로 위장했으며, 변종에 따라 cron을 사용하거나 cron 없이 다시 실행됐다.

• crontab -l | grep -i gvfsd로 사용자 cron을 확인하되 시스템 cron 스풀도 직접 조사한다.
• ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'로 프로세스 이름과 실제 실행 경로가 일치하는지 확인한다.
• 사용자 홈의 .local/share/.gvfsd와 .cache/fontconfig, /tmp의 .kw_, .fc-, .chrony- 계열 경로를 조사한다.
• grep -ril 'x_trace_' var/report/ 결과와 결제 실패 알림의 비정상적 증가, 관련 요청 로그를 같은 시간축에서 대조한다.
• find pub/media -name '*.php'로 미디어 영역의 PHP 파일을 찾고 정상 확장 기능이 만든 파일과 구분한다.

웹셸은 같은 취약점을 이용한 별도 공격자가 상품 이미지 캐시에 설치한 사례로, Rust 백도어와 동일한 도구로 단정해서는 안 된다. 또한 chronyd 변종 중에는 cron 항목 없이 재실행된 사례가 있으므로 빈 crontab이나 알려진 파일명 하나의 부재만으로 침해가 없었다고 판단할 수 없다.

암호화 키 뒤에 외부 자격 증명도 교체한다

Commerce 암호화 키는 통합 토큰, 결제 게이트웨이 자격 증명과 높은 권한의 자동화 토큰을 보호한다. 그러나 공격자가 키 또는 복호화된 값을 이미 가져갔다면 새 암호화 키는 외부에 남은 복사본을 무효화하지 못한다. Commerce 설정에서 값을 다시 저장하는 작업과 각 서비스의 기존 비밀을 폐기하는 작업이 모두 필요한 이유다.

자격 증명 교체는 취약 경로를 닫고 패치 상태를 확인한 뒤 수행한다. 이미 침해된 호스트에서는 악성 프로세스를 그대로 둔 채 새 비밀을 입력하면 다시 노출될 수 있으므로, 격리와 조사 결과를 반영해 깨끗한 배포 환경에서 진행해야 한다.

1. 핫픽스 적용을 검증한 뒤 유지보수 모드를 켠다.
2. Commerce on Cloud에서는 vendor/bin/ece-tools cron:disable로 cron을 중지한다.
3. Commerce 암호화 키와 모든 관리자 계정 비밀번호를 교체한다.
4. System > Extensions > Integrations에서 REST·SOAP·GraphQL 통합 토큰을 비활성화하고 다시 발급한다.
5. 연결된 애플리케이션의 OAuth client secret을 해당 서비스에서 폐기·재발급한다.
6. 결제 게이트웨이의 API 자격 증명을 공급자 콘솔에서 교체한다.
7. 데이터베이스 비밀번호, SSH·배포 키, cron 및 시스템 권한 서비스 계정을 교체한다.
8. 배송·세금·기타 서드파티 확장 기능의 API 키를 각 제공처에서 다시 발급한다.
9. 캐시를 비우고 cron을 다시 활성화한 뒤 유지보수 모드를 해제한다. Commerce on Cloud는 새 데이터베이스 자격 증명을 반영하도록 재배포한다.

교체 순서는 서비스 의존 관계와 함께 관리해야 한다. 새 결제 키를 Commerce와 주문 후처리·환불·정산 시스템에 배포하고 연결을 확인한 뒤 구 키를 폐기해야 장애를 줄일 수 있다. 다만 침해가 확인된 비밀을 편의를 위해 장기간 함께 활성화해서는 안 된다.

완료 기준은 Applied 표시 하나가 아니다

현재 확인된 상태는 CVE-2026-75650이 인증 없이 임의 코드 실행으로 이어질 수 있고, 실제 악용이 패치 공개 전에 시작됐다는 것이다. 공개된 정보만으로 특정 공격 주체를 단정할 수 없으며, 알려진 프로세스 이름과 파일 경로도 관측된 변종에 한정된다.

대응 완료 여부는 전 노드의 핫픽스 적용, 침해 조사와 증거 보존, 발견된 백도어·웹셸·지속성 제거, 암호화 키 및 외부 자격 증명의 원 발급처 교체를 함께 확인해 판단해야 한다. 마지막으로 주문·결제·환불·통합 작업이 새 자격 증명으로 정상 작동하는지 검증하고, 새 변종이나 침해 지표가 공개되면 기존 조사 범위를 다시 대조해야 한다.