
CVE-2026-80343에 대한 실행 가능한 개념 증명으로, camel-netty-http 보안 제약 조건의 대소문자 구분 우회 취약점이며, Spring Boot 및 Quarkus 재현 환경과 수정 검증을 포함합니다.
camel-netty-http 보안 제약이 요청 경로를 구성된 컨텍스트 경로와 대소문자를 구분하여 비교한 반면, 요청을 엔드포인트로 디스패치하는 라우팅은 동일한 규칙을 적용하지 않았던 Apache Camel 취약점에 대한 실행 가능한 개념 증명(PoC) 재현 도구입니다. 구성된 값과 대소문자가 다른 모든 경로에 대해 두 비교가 불일치합니다. 외부 호출자가 컨텍스트 경로 세그먼트의 문자 대소문자를 변경하면 보안 제약이 해당 경로를 보호 대상으로 인식하지 못하게 되지만, 요청은 여전히 동일한 엔드포인트로 디스패치됩니다. 제약이 건너뛰어지고 보호된 라우트가 이를 충족하지 않은 채 도달됩니다 — 자격 증명, 사전 접근 권한, 특별한 구성이 필요하지 않습니다.
| 런타임 | 디렉터리 | 스택 |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-netty-http 4.22.0 (영향받음; 수정 버전 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-netty-http 3.29.0 (Camel 4.15.0, 영향받음; 수정 대조군 3.40.0 / Camel 4.22.1) |
netty-http 컨슈머가 컨텍스트 경로 /app에서 수신 대기하며, 엔드포인트 기준 /secret을 거부하는 인증기로 보호하는 SecurityConstraintMapping에 의해 보호됩니다. 아래 두 요청 모두 자격 증명을 포함하지 않습니다:
GET /app/secret (구성된 대소문자) → 제약이 이를 보호 대상으로 인식 → 401.GET /App/secret (컨텍스트 경로 대소문자 변경) → 핸들러의 extractTarget은 대소문자를 구분하는 startsWith에서만 컨텍스트 경로를 제거하므로, 제거가 건너뛰어지고 제약이 해당 경로를 보호 대상으로 인식하지 못함 → 라우터는 여전히 이를 /app 엔드포인트로 디스패치 → 200 및 보호된 본문, 인증 없이 반환.수정된 빌드에서는 두 요청 모두 401을 반환합니다.
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
영향받는 빌드에서의 예상 출력:
Configured case GET /app/secret -> status 401, body:
Altered case GET /App/secret -> status 200, body: PROTECTED-ADMIN-DATA: reached the protected endpoint
>>> PROVEN: /app/secret is correctly rejected (401), but /App/secret bypassed the security constraint ...
| 속성 | 값 |
|---|---|
| 구성 요소 | camel-netty-http |
| CWE | CWE-178 (대소문자 구분 부적절 처리) |
| 심각도 | HIGH |
| 공격 벡터 | 컨텍스트 경로 대소문자가 구성된 엔드포인트 경로와 다른 요청 |
| 영향 | 보안 제약 건너뜀; 인증 없이 보호된 라우트 도달 |
| 영향받는 버전 | 4.0.0부터 4.18.5 이전, 4.19.0부터 4.22.1 이전 |
| 수정 버전 | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24412 |
| 크레딧 | Claude Security Scan Tool |
권고: https://camel.apache.org/security/CVE-2026-80343.html
보안 제약과 컨텍스트 경로 처리가 이제 경로를 일관되게 비교합니다(컨텍스트 경로에서 대소문자 구분 없이). 따라서 대소문자가 변경된 요청은 구성된 대소문자 형태와 정확히 동일하게 보호 대상으로 인식되며 동일한 인증을 받습니다.
업그레이드가 가능할 때까지 netty-http 보안 제약에만 의존하지 말고 라우트 자체에서 권한 부여를 적용하거나, 보안 검사 전에 요청 경로의 대소문자를 정규화하십시오.
이 저장소는 교육 및 방어 목적으로 게시됩니다: Apache Camel 사용자가 취약점을 이해하고, 영향을 받는지 확인하며, 업그레이드가 문제를 해결하는지 검증할 수 있도록 돕기 위함입니다. 소유하거나 운영하지 않는 시스템에 이 자료를 사용하지 마십시오.