CVE-2026-66907

요약

Apache Camel Google Storage 구성 요소의 상대 경로 탐색(Relative Path Traversal) 취약점입니다. 이 문제는 Apache Camel 4.0.0 이상 4.14.9 미만, 4.15.0 이상 4.18.4 미만, 4.19.0 이상 4.22.0 미만 버전에 영향을 미칩니다. camel-google-storage 컨슈머는 downloadFileName 옵션이 설정된 경우 Google Cloud Storage 객체를 로컬 파일시스템으로 다운로드합니다. 이 옵션은 폴더 또는 파일 이름으로 문서화되어 있으며, 해당 값에 표현식 토큰이 포함되어 있지 않으면 컨슈머는 객체 이름을 그 값에 추가하여 로컬 대상 경로를 구성합니다. evaluateFileExpression은 Exchange의 file-name 헤더를 원격 객체 이름으로 설정하고 downloadFileName + "/${file:name}"을 평가합니다. ${file:name} 토큰은 FileUtil.stripPath를 적용하는 ${file:onlyname}과 달리 file-name 헤더를 그대로 반환합니다. 결과 문자열은 문자열 정규화(lexical normalization) 없이, 그리고 대상 경로가 구성된 디렉터리 내에 유지되는지에 대한 검사 없이 new File(result)와 blob.downloadTo(file.toPath())에 직접 전달되었습니다. 객체 이름은 라우트 제어 데이터가 아닙니다. 컨슈머는 버킷을 나열하고 반환된 모든 blob을 순회하며 blob.getBlobId().getName()에서 얻은 이름 그대로 객체별로 하나의 exchange를 생성하며, 해당 이름을 제한할 수 있는 filter 옵션은 명시적으로 설정되지 않는 한 전혀 적용되지 않습니다. Google Cloud Storage 객체 이름은 불투명한 UTF-8 키로, 서비스는 이를 작성된 그대로 저장하고 나열하며 서버 측 정규화가 없습니다. 슬래시는 의사 디렉터리(pseudo-directory)를 위한 표시 규칙에 불과하므로, 상위 디렉터리 세그먼트를 포함하는 키는 왕복(round-trip)을 거쳐도 그대로 유지됩니다. 따라서 이러한 세그먼트를 포함하는 객체 이름은 구성된 downloadFileName 디렉터리 외부의 위치로 해석되었고, 소비 중인 버킷에 존재하는 이름에 영향을 줄 수 있는 사람이라면 누구든 Camel 프로세스의 권한으로 원하는 위치에 파일을 생성하거나 덮어쓸 수 있었습니다. 프로세스가 쓸 수 있는 대상에 따라, 다운로드 디렉터리 외부의 파일을 덮어쓰는 것은 해당 파일의 무결성 손실을 넘어 공격 범위를 확대할 수 있습니다. downloadFileName 옵션은 일반적인 컨슈머 매개변수이며 보안 표시를 지니지 않으므로, 그 값이 격리 경계로 강제되지 않고 있다는 점을 사용자에게 알려주는 신호는 없었습니다. 이 결함은 컨슈머에만 해당되며, 프로듀서에는 파일 다운로드 싱크가 없습니다. Camel의 다른 파일 다운로드 컨슈머(camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files 및 Azure Storage 다운로드 경로)는 이미 경로 세그먼트 경계 검사를 통해 로컬 다운로드를 구성된 디렉터리로 제한했습니다. camel-google-storage는 해당 작업에서 다루지 않은 마지막 객체 저장소 다운로드 싱크였습니다. 사용자는 이 문제를 해결한 4.22.0 버전으로 업그레이드할 것을 권장합니다. 4.14.x LTS 릴리스 스트림을 사용 중이라면 4.14.9로 업그레이드하는 것이 좋습니다. 4.18.x 릴리스 스트림을 사용 중이라면 4.18.4로 업그레이드하는 것이 좋습니다. 즉시 업그레이드할 수 없는 배포 환경에서는 filter 옵션을 단순한 단일 세그먼트 객체 이름만 허용하는 정규 표현식으로 설정하여, 경로 구분자나 상위 디렉터리 세그먼트를 포함하는 이름이 exchange 생성 전에 제외되도록 하십시오. 옵션을 설정하지 않으면 어떠한 필터링도 적용되지 않으며, 표현식은 전체 객체 이름과 대조된다는 점에 유의하십시오. 또는 downloadFileName에 원격 경로를 그대로 전달하지 않는 명시적 표현식을 지정하십시오. 예를 들어 암시적 ${file:name} 대신 ${file:onlyname} 기반의 표현식을 사용할 수 있습니다. 단, 표현식을 포함하는 downloadFileName은 라우트 작성자가 제어하는 것으로 간주되며 수정 사항에 추가된 격리 경계 검사의 적용을 받지 않는다는 점을 명심하십시오. 심층 방어 차원에서 외부에서 쓰기 가능한 버킷의 객체 이름은 신뢰할 수 없는 입력으로 취급하고, 이를 바탕으로 로컬 파일시스템 경로를 파생하지 마십시오.