Adobe Commerce 템플릿 엔진 코드 실행(CVE-2026-75650)｜영향 범위와 대응

실제 악용이 확인된 인증 전 코드 실행

Adobe는 2026년 9월 7일 APSB26-146을 공개하면서 CVE-2026-75650이 실제 공격에 이용되고 있다고 밝혔습니다. 취약점은 Adobe Commerce와 Magento Open Source의 템플릿 엔진에서 특수 요소를 적절히 무력화하지 못하는 문제로 분류됐고, 공격에 계정 인증이 필요하지 않습니다. 성공하면 취약한 설치 환경에서 임의 코드를 실행할 수 있어 관리자 화면만 보호하는 접근 제어나 계정 다중 인증만으로는 위험을 닫을 수 없습니다. 인터넷에서 상거래 요청을 받는 애플리케이션 노드 전체가 우선 확인 대상입니다.

이번 공지는 일반적인 분기별 누적 업데이트가 아니라 CVE-2026-75650 전용 핫픽스를 제시합니다. 운영자는 제품 이름만 보고 적용 여부를 판단하기보다 Adobe Commerce, Commerce B2B, Magento Open Source를 구분하고 각 인스턴스가 어느 2.4 계열과 2026년 8월 기준 릴리스에 속하는지 대조해야 합니다. 웹 노드가 여러 대이거나 배포 이미지와 자동 확장 템플릿을 함께 쓰는 환경에서는 한 노드의 패치 완료가 전체 서비스의 완료를 뜻하지 않습니다. 동일한 코드가 배포되는 원본 이미지와 대기 노드까지 범위에 넣어야 합니다.

제품 계열별 영향 범위

Adobe Commerce는 2.4.4부터 2.4.9까지 각 계열의 2026년 8월 릴리스와 그 이전 버전이 영향 목록에 들어갑니다. Commerce B2B는 1.3.3, 1.3.4, 1.4.2, 1.5.2, 1.5.3 계열의 2026년 8월 릴리스와 그 이전이 포함됩니다. Magento Open Source는 2.4.6부터 2.4.9까지 각 계열의 2026년 8월 릴리스와 그 이전이 대상입니다. 같은 2.4 숫자가 보여도 B2B 모듈 사용 여부와 제품 계열이 다르면 확인해야 할 패키지와 운영 경로가 달라집니다.

자산 목록에는 고객에게 노출되는 대표 도메인뿐 아니라 관리자 전용 노드, 배치·인덱싱 노드, 재해복구 대기 환경, 임시 스테이징, 자동 확장용 이미지도 포함하는 편이 안전합니다. 로드밸런서 뒤에서 트래픽을 받지 않는 노드라도 이후 복구나 확장 과정에서 다시 투입될 수 있기 때문입니다. 컨테이너 기반 배포라면 실행 중인 컨테이너와 다음 배포에 쓰일 이미지 태그를 따로 확인하고, 가상머신 이미지라면 패치 전 스냅샷에서 새 인스턴스가 생기지 않도록 배포 절차를 함께 잠가야 합니다.

VULN-39341 전용 핫픽스

Adobe Experience League 안내는 영향 제품에 VULN-39341 핫픽스를 적용하도록 요구합니다. 제공 파일은 Commerce on Cloud, 온프레미스 Adobe Commerce, Magento Open Source에 맞춰 Composer 패치 절차로 적용됩니다. 공지에 기재된 시험 대상 릴리스와 실제 운영 버전을 대조하고, 목록 밖 조합에 임의로 적용하기보다 지원 경로를 통해 호환성을 확인해야 합니다. 패치 파일의 출처와 무결성을 검증한 뒤 변경관리 기록에 대상 인스턴스, 적용 시각, 배포 산출물의 해시와 승인자를 남기면 재배포 과정에서 누락을 줄일 수 있습니다.

배포 전에는 주문, 장바구니, 결제, 세금·배송 연동, 관리자 로그인, API와 GraphQL 호출, cron 작업을 대표하는 회귀 시험을 준비합니다. 스테이징 검증이 끝나면 유지보수 창을 정해 모든 운영 노드에 같은 패치를 배포하고, 로드밸런서에서 제외했던 노드가 패치 전 상태로 다시 합류하지 않는지 확인합니다. 캐시와 생성 코드, 정적 콘텐츠가 여러 계층에 남는 구조라면 패치 적용 후 각 계층을 정해진 순서로 갱신해야 합니다. 단순히 파일을 복사한 결과만 보지 말고 서비스 경로가 새 코드로 응답하는지 검증하는 과정이 필요합니다.

암호화 키와 연동 자격증명 교체

Adobe는 핫픽스 적용만으로 대응을 끝내지 않고 암호화 키와 관련 자격증명을 교체하도록 안내합니다. Commerce 암호화 키는 통합 토큰, 결제 게이트웨이 자격증명, 시스템 권한 자동화 토큰을 보호하는 데 쓰입니다. 키만 바꾸어도 외부 서비스가 이미 발급한 비밀값 자체는 무효화되지 않으므로 관리자 비밀번호, REST·SOAP·GraphQL 통합 토큰, OAuth 클라이언트 비밀, 결제사 API 자격증명, 데이터베이스 계정, SSH·배포 키, 배송·세금 확장 기능의 API 키까지 발급처에서 각각 새 값으로 교체해야 합니다.

교체 작업은 핫픽스 적용 뒤 유지보수 모드에서 cron 실행을 멈춘 상태로 진행하는 순서가 제시됐습니다. 이유는 구형 비밀값을 사용하는 작업이 교체 중 다시 실행되거나, 일부 노드가 이전 키를 들고 데이터에 접근하는 혼선을 막기 위해서입니다. 새 비밀값을 비밀관리 시스템과 배포 파이프라인에 반영한 다음 캐시를 비우고 cron을 재개하며 유지보수 모드를 해제합니다. 결제와 주문 연동은 실패가 매출과 고객 경험으로 이어지므로 각 외부 공급자별 성공 응답을 실제 운영 경로에서 확인해야 합니다.

적용 완료를 판정하는 방법

완료 판정은 패치 파일 존재 여부, 배포 노드의 실제 적용 상태, 서비스 기능 검증을 나누어 기록합니다. Adobe Commerce on Cloud 안내는 Quality Patches Tool 상태에서 VULN-39341이 Applied로 표시되는지 확인하는 절차를 제공합니다. 온프레미스나 별도 배포 체계에서는 동일한 목적을 달성할 수 있도록 배포 산출물과 실행 노드의 파일 상태를 비교하고, 새로 만들어지는 노드가 수정된 이미지에서 시작하는지 확인해야 합니다. 자동 확장 그룹과 재해복구 템플릿까지 같은 기준을 통과해야 자산 전체의 조치가 끝난 것입니다.

기능 검증은 홈페이지 응답만으로 끝내지 않습니다. 장바구니 생성과 갱신, 회원·비회원 주문, 결제 승인과 취소, 관리자 작업, 인덱서와 cron, 주요 통합 API를 순서대로 확인합니다. 그 뒤 웹 애플리케이션과 운영체제 로그에서 비정상 템플릿 처리, 예기치 않은 파일 변경, 새 관리자·통합 토큰, 외부 전송 오류를 검토합니다. 조사와 복구가 동시에 진행된다면 증거 보존용 로그와 디스크 사본을 먼저 확보하고, 운영 복구본과 분석본을 분리해야 변경 과정이 기존 흔적을 덮지 않습니다.

자격증명 교체의 완료 여부도 항목별로 따로 증명해야 합니다. Commerce 암호화 키를 교체한 시각, 관리자 계정의 비밀번호 변경, 통합별 토큰 재발급, 결제·배송·세금 공급자의 구형 키 폐기, 데이터베이스와 배포 계정의 새 비밀값 반영을 하나의 변경표에 연결합니다. 새 값으로 정상 거래가 수행됐다는 사실과 이전 값으로 더는 인증되지 않는다는 사실을 함께 확인해야 실제 무효화가 끝났다고 볼 수 있습니다. 외부 공급자가 키 폐기와 새 키 발급을 다른 화면에서 처리한다면 두 작업의 기록을 모두 보관하고, 비밀관리 시스템에 남은 이전 버전이 자동 롤백이나 재배포 과정에서 다시 주입되지 않도록 배포 이력도 점검합니다.

여러 상점과 브랜드가 한 Commerce 기반을 공유한다면 기술 인스턴스와 업무 영향 범위를 함께 연결해야 합니다. 한 코드베이스를 쓰더라도 도메인별 결제사, 관리자 그룹, 통합 토큰과 배포 창이 다를 수 있으므로 대표 상점 하나의 시험 결과를 전체 환경에 그대로 적용하기 어렵습니다. 자산별 담당자와 연동 공급자를 지정하고, 패치·키 교체·기능 시험·로그 검토 네 단계가 모두 끝난 상점만 완료로 표시합니다. 이렇게 해야 취약한 대기 노드나 사용 빈도가 낮은 관리 상점이 정상 운영 화면 뒤에 남는 일을 줄일 수 있습니다.

운영팀용 우선순위

1. 외부에서 접근 가능한 Commerce·Magento 인스턴스와 모든 배포 원본을 제품 계열별로 분류합니다.
2. 공식 경로에서 VULN-39341 핫픽스를 확보하고 대표 기능을 포함한 스테이징 회귀 시험을 수행합니다.
3. 로드밸런서 뒤 노드와 자동 확장 이미지까지 같은 변경으로 배포한 뒤 적용 상태를 증명합니다.
4. 암호화 키와 관리자·통합·결제·데이터베이스·배포 자격증명을 발급처에서 새 값으로 교체합니다.
5. 주문·결제·API·cron 기능과 보안 로그를 재검토하고 변경 기록을 자산별로 남깁니다.

CVE-2026-75650은 인증 전 공격과 실제 악용, 전용 핫픽스라는 세 조건이 겹친 긴급 사안입니다. 패치 배포 속도만큼 중요한 것은 어떤 노드와 자격증명까지 영향 범위에 넣었는지 입증하는 일입니다. 제품 계열을 정확히 나누고, 모든 실행·대기 노드에 동일한 수정 상태를 만든 뒤, Commerce가 보관하거나 사용하는 비밀값을 공급자 측에서 무효화하는 순서로 대응해야 합니다.