CVE-2026-49364 (Apache ActiveMQ Artemis 클러스터 인증 우회) 분석

2026-10-19 · ##웹·서버 ##인증우회

분류: CVE · 웹·서버 · 인증우회 · CVE-2026-49364 · [표준]

클러스터를 이루는 메시징 브로커들은 서로를 처음 찾아낼 때부터 신뢰 관계를 맺습니다. 문제는 “찾아내는 것”과 “인증하는 것”이 같은 순간에 일어나지 않을 때 생깁니다. Apache ActiveMQ Artemis는 브로커가 클러스터 피어를 discovery(자동 탐색)로 찾아 처음 연결을 맺는 바로 그 핸드셰이크 구간에서, 상대가 누구인지 확인하기 전에 관리자 자격증명이 오갈 수 있는 틈을 남겼습니다. 그 결과 네트워크에 발만 걸칠 수 있으면 로그인 없이도 클러스터 관리 자격증명을 가로챌 수 있었습니다.

개요

Apache ActiveMQ Artemis(및 그 전신 격인 Apache Artemis 배포판)는 자바 기반 오픈소스 메시지 브로커로, 대규모 시스템에서 여러 브로커 노드를 묶어 클러스터로 운용합니다. 이번 취약점은 노드가 클러스터에 새로 합류할 때 상대 브로커를 찾는 discovery(브로드캐스트/디스커버리 그룹) 기능과, 그렇게 찾은 상대와 맺는 초기 연결 핸드셰이크 구간에 있습니다. 네트워크에 인접한 인증되지 않은(pre-auth) 공격자가 이 핸드셰이크 과정에 끼어들어 클러스터 관리 자격증명을 탈취할 수 있습니다(CWE-306, 중요 기능에 대한 인증 누락).

영향 범위: Apache Artemis 2.50.0 ~ 2.56.0, Apache ActiveMQ Artemis 1.0.0 ~ 2.44.0.
수정 버전: 2.57.0.
CWE: CWE-306 (Missing Authentication for Critical Function).
CVSS: 3.1 기준 9.1 (Critical), 벡터 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — 세 개의 독립 집계 소스에서 일치 확인.
선행조건: 인증 불필요, 네트워크 인접(같은 클러스터 discovery 네트워크 세그먼트에 도달 가능해야 함). 공격 복잡도 낮음, 사용자 상호작용 불필요.
영향: 기밀성·무결성 High, 가용성 영향 없음(A:N) — 자격증명 탈취를 통한 관리 권한 획득이 핵심이지, 이 결함 자체가 직접 서비스를 마비시키진 않습니다.
발견자: Domenico Francesco Bruscino로 표기되어 있습니다. ⚠️미확인 — GitHub 커밋 작성자 brusdev와 동일인으로 추정되나 명시적으로 확인되지 않았습니다.
공개일: 2026-09-10 (Apache 공식 메일링리스트 공지 + oss-security 미러).

한 줄 요약: “누구인지 확인하기 전에 이미 자격증명이 오간다” — discovery로 찾은 상대와의 첫 악수(handshake)가 인증보다 먼저 자격증명을 흘려보낸 것이 핵심입니다.

기술 배경 — 클러스터는 어떻게 서로를 찾고 신뢰하는가

Artemis 클러스터는 브로커가 늘어날 때마다 사람이 일일이 주소를 등록해주지 않아도 되도록 discovery 메커니즘을 둡니다. 브로커가 멀티캐스트나 UDP 브로드캐스트로 “나 여기 있다”를 주기적으로 알리면, 다른 노드가 이를 듣고 자동으로 피어 목록에 추가합니다. 그 다음 실제로 클러스터 링크를 맺으려면 발견된 상대와 연결 핸드셰이크를 거쳐야 합니다 — 이 단계에서 프로토콜 버전을 맞추고, (설계상으로는) 서로가 신뢰할 수 있는 상대인지 확인한 뒤 세션을 시작합니다.

문제는 이 핸드셰이크가 “탐색”과 “인증”을 분리된 두 단계로 엄격히 나누지 않을 때 생깁니다. discovery는 애초에 누구나 들을 수 있는 채널(브로드캐스트)을 전제로 하는 편의 기능이라 그 자체로는 신원을 보증하지 않습니다. 그래서 discovery로 찾은 상대와 처음 세션을 트는 순간에, 자격증명이 오가기 전에 상대가 정말 클러스터의 일원인지를 확인하는 절차가 반드시 있어야 합니다. 이 확인이 빠지거나 뒤늦게 일어나면, discovery 채널에 접근할 수 있는 네트워크상의 누구든 “나도 클러스터 노드다”라고 나타나 핸드셰이크에 끼어들 수 있는 문을 얻습니다.

CVE 분석 요약 — 어느 판단이 원인인가

Apache 공식 보안 공지는 근본 원인을 “인증되지 않은 네트워크 인접 공격자가 discovery를 활용해 초기 클러스터 연결 핸드셰이크 중 클러스터 관리 자격증명을 탈취할 수 있다”고 서술합니다. 2.56.0 → 2.57.0 사이의 공개 커밋 이력에서, 이 서술과 내용이 정확히 맞아떨어지는 보안 커밋 두 건이 확인됩니다.

“Improve Core connection handshake” — 레거시 CheckFailoverMessage/CheckFailoverReplyMessage(페일오버 확인용 평문 패킷)를 ConnectMessage/ConnectResponseMessage로 교체하고, 연결 단계에 선택적 인증을 추가했습니다. 클러스터 링크·JMS·관리 클라이언트 경로에서 자격증명 전파를 ServerLocator/ClientSessionFactory 계층에서 명시적으로 처리하도록 바꾼 것으로 보입니다.
“Disable discovery by default” — discovery(브로드캐스트/디스커버리 그룹)를 별도 설정(discovery-enabled 등)으로 명시적으로 켜지 않으면 기본값을 비활성화로 바꿨습니다. 즉 이전에는 별다른 설정 없이도 discovery 채널이 열려 있었다는 뜻입니다.

⚠️미확인(팩트체크 대상) — 이 두 커밋이 CVE-2026-49364를 고친 “공식 지정 패치”인지는 Apache 공지문에 명시적인 커밋/PR 링크로 확인되지 않았습니다. 같은 2.57.0 릴리스에서 컴패니언 취약점 CVE-2026-49362(인증 전 임의 durable 큐 생성)·CVE-2026-49363(인증 전 SUBSCRIBE_TOPOLOGY 요청으로 클러스터 노드 정보 노출)도 함께 패치됐기 때문에, 세 CVE와 각 커밋의 1:1 대응 관계는 정확히 갈라지지 않습니다. 커밋의 전체 40자 SHA 값·정확한 파일별 변경 라인도 이 초안 단계에서는 원문 diff를 직접 바이트 대조하지 않았으므로 확정하지 않습니다.

그래도 서술된 동작을 개념적으로 재구성하면 다음과 같은 흐름입니다. 실제 코드를 그대로 옮긴 것이 아니라, 공개된 커밋 메시지와 CVE 설명을 바탕으로 한 단순화입니다.

// 개념용 단순화, 실제 원본 코드 아님 (커밋 diff 라인 단위 미대조 — ⚠️미확인)
// 패치 전: 핸드셰이크가 신원 확인보다 먼저 자격증명 처리 경로를 연다고 추정
void onDiscoveredPeer(PeerInfo peer) {
    // discovery로 찾은 상대에게 곧바로 연결을 시도
    Connection conn = connect(peer.getAddress());

    // (패치 전 추정) 클러스터 관리 자격증명이 담긴
    // CheckFailoverMessage류 패킷이, 상대가 진짜 클러스터 멤버인지
    // 별도로 검증하기 전에 오갈 수 있었던 것으로 보인다
    conn.send(new CheckFailoverMessage(clusterAdminCredentials));
}

패치 이후에는 (a) discovery 자체가 기본 비활성화되어 공격 표면이 줄고, (b) 연결 핸드셰이크가 ConnectMessage 기반으로 재설계되어 선택적 인증을 거치도록 바뀐 것으로 보입니다. 다만 정확히 “몇 번째 패킷에서 어떤 검증이 빠졌었는가”는 이 초안에서 라인 단위로 단정하지 않습니다.

공격 시나리오 · 영향도 + 대응방안

공격 시나리오 (단계 압축, 완성형 페이로드 없음):

공격자가 Artemis 클러스터의 discovery 채널(브로드캐스트/디스커버리 그룹)에 도달 가능한 네트워크 위치를 확보합니다(같은 세그먼트 또는 라우팅 가능한 인접 구간).
클러스터 노드인 것처럼 discovery에 응답하거나, discovery로 알려진 실제 노드에 스스로 연결을 시도해 초기 연결 핸드셰이크에 끼어듭니다.
이 단계에서 오가는 클러스터 관리 자격증명을 가로챕니다. 로그인 절차 없이 이뤄지는 교환이므로 별도의 인증 우회가 필요 없습니다.

영향도: 확인된 결과는 클러스터 관리 자격증명의 노출입니다(C:H/I:H). 이 자격증명을 손에 넣으면 클러스터 관리 수준의 권한으로 메시징 인프라(큐·토픽 구성 등)를 조작할 수 있을 것으로 예상됩니다(우리 분석·추정 — CVSS 벡터의 High/High 등급이 근거이나, 정확히 어떤 관리 오퍼레이션까지 가능한지는 1차출처에 세부 열거가 없습니다). A:N(가용성 영향 없음)이므로 이 결함 자체가 직접 브로커를 마비시키진 않습니다. 실제 익스플로잇 관측 여부는 이 글의 리서치 범위에서 확인되지 않았습니다(⚠️미확인).

대응방안:

근본: Apache Artemis/ActiveMQ Artemis를 2.57.0 이상으로 업데이트합니다.
차선(즉시 업데이트 불가 시):
- discovery(브로드캐스트/디스커버리 그룹)를 명시적으로 비활성화하거나, 반드시 필요하다면 discovery 트래픽을 신뢰된 네트워크 세그먼트로 격리합니다.
- 클러스터 노드 간 통신 포트를 방화벽으로 제한해, 클러스터 멤버가 아닌 호스트가 discovery·연결 핸드셰이크 트래픽에 접근하지 못하게 합니다.
- 가능하다면 클러스터 연결에 TLS 및 명시적 인증을 설정해, 핸드셰이크 자체를 신뢰 채널로 강제합니다.
탐지 관점: 클러스터 관리 포트로 향하는 예상치 못한 소스 IP의 연결 시도, 특히 정식 클러스터 노드 목록에 없는 호스트로부터의 discovery 응답이나 연결 핸드셰이크 패킷을 감시합니다.

결론

클러스터가 서로를 찾는 방식(discovery)과 서로를 믿는 방식(인증)은 다른 문제입니다. 둘을 같은 한 번의 악수 안에 뭉쳐두면, 상대가 누구인지 묻기도 전에 열쇠부터 건네주는 셈이 됩니다.

이 부류의 결함이 반복되는 이유는 분명합니다. 분산 시스템에서 편의를 위해 만든 자동 탐색 기능은, 그 자체로 신원을 보증하지 않는다는 사실을 잊는 순간 인증 우회의 입구가 됩니다. discovery는 “누가 클러스터에 있는지”를 알려줄 뿐 “그 상대를 믿어도 되는지”는 알려주지 않는데, 초기 연결 핸드셰이크가 이 둘을 혼동하면 자격증명이 인증보다 먼저 오가는 순서 역전이 생깁니다. 이 결함은 같은 릴리스에서 함께 드러난 CVE-2026-49362(인증 전 임의 큐 생성)·CVE-2026-49363(인증 전 토폴로지 정보 노출)과 같은 뿌리 — pre-auth 상태에서 처리되는 프로토콜 경로가 지나치게 많은 일을 한다는 패턴 — 를 공유합니다. 이 한 틈은 discovery 기본 비활성화와 핸드셰이크 재설계로 닫혔지만, “탐색과 인증을 분리하라”는 교훈은 다음 클러스터 프로토콜, 다음 자동 디스커버리 기능에서 또 시험대에 오릅니다. 그래서 우리는 도구가 아니라 방법을 남깁니다.

References / 참고자료

Apache Software Foundation, “CVE-2026-49364” 공식 보안 공지 — 이 글이 재구성한 1차 정본(취약점 설명·영향 버전·수정 버전). https://artemis.apache.org/security-advisories.data/CVE-2026-49364-announcement.txt
Apache Software Foundation, Security Advisories — Artemis — 공식 보안 공지 색인. https://artemis.apache.org/components/artemis/security
Apache Mailing List, “[SECURITY] CVE-2026-49364” 공지 스레드 — 공개일·배포 채널 확인. https://lists.apache.org/thread/4qbgcz3k38q30bfbf7hphtomrdc8l8n8
GitHub, apache/activemq-artemis 커밋 “Improve Core connection handshake” — 연결 핸드셰이크 재설계 근거(⚠️CVE와의 1:1 매핑은 공식 확인 안 됨, 팩트체크 대상). https://github.com/apache/activemq-artemis/commit/51b0674
GitHub, apache/activemq-artemis 커밋 “Disable discovery by default” — discovery 기본 비활성화 변경 근거(⚠️동일 매핑 유보). https://github.com/apache/activemq-artemis/commit/cb012ac
Strix.ai, “CVE-2026-49364: Apache Artemis Missing Authentication (CVSS 9.1)” — CVSS 벡터·CWE 교차 확인. https://www.strix.ai/cve/CVE-2026-49364
OpenCVE, CVE-2026-49364 상세 — CWE·공개일 교차 확인. https://app.opencve.io/cve/CVE-2026-49364

이 글은 위 원 자료를 우리 관점에서 다시 쓰고 논평을 더한 것입니다. 특정 문장·코드를 그대로 옮기지 않았으며, 자세한 재현 절차는 원문을 참고하세요. 커밋 “Improve Core connection handshake”·“Disable discovery by default”가 CVE-2026-49364의 공식 지정 패치인지는 Apache 공지문에 명시적으로 링크되어 있지 않아, 정황상 강한 신뢰도로 추정했을 뿐 확정하지 않았습니다. ⚠️미확인 표시가 붙은 주장(커밋과 CVE의 1:1 매핑·전체 SHA 값·라인 단위 코드 대조·발견자 신원)은 발행 전 독립 팩트체크로 1차출처 대조가 끝나야 확정됩니다.