CVE-2026-66906 in Camel
요약
\~에 의해 VulDB • 2026. 08. 24.
Apache Camel Azure Storage Blob 컴포넌트에서의 상대 경로 트래버설 취약점.
이 문제는 Apache Camel의 다음 버전에서 영향을 미칩니다: 4.0.0 이상 4.14.9 미만, 4.15.0 이상 4.18.4 미만, 4.19.0 이상 4.22.0 미만입니다.
camel-azure-storage-blob 컴포넌트는 downloadBlobToFile 연산을 통해 Azure Storage blob을 로컬 파일 시스템으로 다운로드할 수 있으며, 이는 fileDir 엔드포인트 옵션에 의해 지정된 디렉토리에 파일을 작성합니다. 이 옵션은 프로듀서와 컨슈머 모두에서 사용 가능하다고 문서화되어 있습니다. BlobOperations.downloadBlobToFile는 로컬 대상 경로를 생성하기 위해 Azure SDK가 보고한 대로 remote blob 이름을 그대로 사용하여 fileDir과 결합(new File(fileDir, client.getBlobName()))하고, 이를 Lexical normalization(구문 정규화) 없이 검증도 수행하지 않은 채로 SDK의 다운로드 호출에 직접 전달했습니다. blob 이름은 라우트 제어 데이터가 아닙니다: 컨슈머는 BlobConsumer.createBatchExchangesFromContainer에서 컨테이너를 열거하며, 이는 각 항목마다 BlobItem.getName()에서 반환된 이름을 그대로 사용하여 하나의 exchange를 생성합니다(기본적으로 이름 필터링을 적용하지 않음). 따라서 부모 디렉토리 세그먼트(parent-directory segments)를 포함하는 blob 이름은 구성된 fileDir 외부의 위치로 해석되어, 소비되는 컨테이너에 존재하는 이름에 영향을 줄 수 있는 누구나 Camel 프로세스의 권한으로 선택한 위치에 파일을 생성하거나 덮어쓸 수 있습니다. 프로세스가 작성할 수 있는 내용에 따라 다운로드 디렉토리 밖의 파일 덮어쓰기는 해당 파일의 무결성 손실을 넘어선 위험을 초래할 수 있습니다. Azure Storage blob 컨테이너는 blob 이름이 불투명한 키인 평면 네임스페이스(flat namespace)를 사용하므로, 이러한 세그먼트를 포함한 이름은 그대로 저장되고 나열됩니다. fileDir 옵션은 일반적인 공통 그룹 구성 매개변수이며 보안 마커가 없으므로, 그 값이 격리 경계로 강제되지 않는다는 신호는 사용자에게 제공되지 않았습니다. Camel의 다른 파일 다운로드 컨슈머들(camel-file, camel-ftp, camel-smb, camel-mina-sftp 및 camel-azure-files)은 이미 경로 세그먼트 경계 검사를 사용하여 로컬 다운로드를 구성된 디렉토리로 제한했습니다; 그러나 camel-azure-storage-blob의 다운로드 경로는 해당 작업에 포함되지 않았습니다.
사용자는 이 문제를 수정한 버전 4.22.0으로 업그레이드하는 것이 권장됩니다. 사용자가 4.14.x LTS 릴리스 스트림을 사용 중이라면 4.14.9로 업그레이드할 것을 제안합니다. 사용자가 4.18.x 릴리스 스트림을 사용 중이라면 4.18.4로 업그레이드할 것을 제안합니다. 즉시 업그레이드가 불가능한 배포 환경에서는 regex 엔드포인트 옵션을 사용하여 컨슈머가 처리할 이름에 제약을 가하는 것이 좋습니다. 이 옵션은 나열된 각 blob 이름에 전체 문자열 일치(full-string match)로 적용되므로, 단순한 단일 세그먼트 이름만 허용되고 exchange 생성 전에 경로 구분자나 부모 디렉토리 세그먼트를 포함하는 모든 이름이 필터링됩니다. prefix 옵션을 추가로 설정하여 서버 측에서 목록을 좁힐 수도 있으며, 두 가지가 모두 설정된 경우 regex가 우선하며 prefix는 무시됨에 유의하십시오. 또는 신뢰할 수 없는 컨테이너에서 downloadBlobToFile 연산을 피하고, 원격 나열에서 가져온 이름 대신 라우트 자체가 제어하는 파일명으로 페이로드를 작성하십시오. 심층 방어(defence in depth) 차원에서 외부에서 쓰기 가능한 컨테이너의 blob 이름을 신뢰할 수 없는 입력으로 간주하고 이를 기반으로 로컬 파일 시스템 경로를 유도하지 마십시오.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.