🔍 CVE-2026-78162

0.0
CVSS Score
UNKNOWN
2026-10-19
2026-10-20 04:17
✅ 완료

🇰🇷 한글 설명

Apache Camel의 camel-hazelcast 컴포넌트에서 신뢰할 수 없는 데이터의 역직렬화 취약점이 발견되었습니다. 특정 설정 경로에서 Hazelcast 인스턴스 생성 시 Java 역직렬화 필터가 적용되지 않아, 공격자가 조작된 객체를 전송할 경우 원격 코드 실행(RCE)이 가능합니다.

💡 쉬운 설명

해커가 특수하게 만든 데이터를 보내면 프로그램이 이를 잘못 읽어 들여 해커의 명령어를 실행할 수 있는 보안 구멍이 있습니다. 이 문제는 Apache Camel이라는 도구를 사용할 때 발생할 수 있습니다.

🇺🇸 원문 (English)

Deserialization of Untrusted Data vulnerability in Apache Camel. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The camel-hazelcast component applies a default Hazelcast JavaSerializationFilterConfig to the instances it creates from its own configuration, a protection introduced by CVE-2026-43865. That change did not reach two of the configuration paths Camel builds itself, so those paths continued to create Hazelcast instances whose Java deserialization is unrestricted. ReplicatedHazelcastAggregationRepository extends HazelcastAggregationRepository but overrides doStart() without calling super.doStart(), keeping its own copy of the bootstrap block, and therefore never received the filter: a route using it without supplying a hazelcastInstance starts a Hazelcast member that deserializes values read from the backing ReplicatedMap with no class restriction. HazelcastDefaultComponent#getOrCreateHzClientInstance() builds its own ClientConfig when hazelcastMode=client is selected and neither a referenced ClientConfig nor hazelcastConfigUri is supplied, and likewise applied no filter, so client-mode endpoints behaved differently from node-mode endpoints for an otherwise identical configuration. In both cases an attacker able to publish into the Hazelcast cluster that the affected instance is attached to can cause a serialized Java object of their choosing to be deserialized inside Hazelcast's own serialization layer, before Camel processes the exchange, resulting in remote code execution. Hazelcast clusters have neither authentication nor TLS enabled by default. Selecting client mode is a topology choice rather than a security option, so neither path required the deployment to opt in to unsafe behaviour. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, supply an explicit Hazelcast configuration carrying a JavaSerializationFilterConfig, or inject a pre-built HazelcastInstance, since a user-supplied configuration is never overwritten by Camel. Alternatively set the JVM-wide filter -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* and enable Hazelcast cluster authentication and TLS to restrict who can reach the cluster.

📍 영향받는 시스템

Apache Camel 4.0.0 ~ 4.18.4, 4.19.0 ~ 4.22.0

⚔️ 공격 벡터

Hazelcast 클러스터에 접근 가능한 공격자가 조작된 직렬화 객체를 게시하여 대상 시스템의 역직렬화 레이어에서 실행

🛡️ 대응 방법

Apache Camel을 4.23.0, 4.22.1 또는 4.18.5 이상의 버전으로 업그레이드하거나, 명시적인 Hazelcast JavaSerializationFilterConfig를 설정하십시오.

🔧 검증 코드

출력된 결과에서 Apache Camel의 버전을 확인하여 취약한 버전 범위에 해당하는지 체크합니다.

Shell / Script
mvn dependency:tree | grep camel-core

💻 영향받는 소프트웨어

Spring Data REST