Armeria 1.43.0 보안 업데이트: 경로 접두사 인증 우회 점검하기

경로 해석과 접근 제어가 같은 기준을 사용해야 한다는 개념을 표현한 생성형 이미지. 실제 Armeria 구조도나 제품 화면은 아니다.

보호할 URL 앞에 인증 데코레이터를 붙였고, 정상 주소로 접속하면 접근이 차단된다. 이 검사만으로 뒤에 연결된 파일 서버나 서블릿까지 같은 보호를 받는다고 결론 내리기는 어렵다. 앞단과 뒷단이 URL 경로를 다르게 해석하면, 같은 리소스로 가는 다른 표현이 인증 적용 범위를 벗어날 수 있기 때문이다.

2026년 11월 6일 공개된 Armeria 보안 공지 CVE-2026-121823은 이런 구성의 인가 우회를 다룬다. 공식 영향 범위는 Maven 패키지 com.linecorp.armeria:armeria 1.42.0 이하, 수정 버전은 1.43.0이다. 심각도는 High이며 CVSS v4.0 점수는 8.7이다. 아래에서는 공격 재현 대신 영향 조건, 실제 배포 버전 확인과 회귀 점검에 집중한다. 공식 보안 공지

어떤 구성을 먼저 확인해야 하나

공지의 영향 조건은 단순히 Armeria 의존성이 있다는 것보다 구체적이다. 다음 두 요소가 함께 있는 서버를 먼저 확인한다.

특정 경로 접두사에 decoratorUnder 등으로 인증·인가 데코레이터를 적용한다.

뒤의 FileService, TomcatService 또는 JettyService가 요청 경로를 정규화해 리소스를 찾는다.

Armeria와 연결된 Spring 컨트롤러도 이런 구성이라면 점검 대상에 포함될 수 있다. 반대로 Armeria를 클라이언트로만 쓰거나 다른 방식으로 인가를 강제한다는 이유만으로 이 구성과 같은 노출을 가정할 필요는 없다. 실제 요청 경로와 보호 지점을 확인해야 한다. 공지의 영향 조건

문제는 단일 점으로 된 경로 세그먼트를 앞단의 경로 매칭이 유지하는 동안, 뒤의 서비스가 이를 정리해 같은 리소스로 해석하는 데서 발생한다. 인증 토큰의 암호 알고리즘이 깨지는 문제가 아니라, 보호 정책을 적용할 경로를 서로 다르게 판단하는 문제다. 그러므로 정상 주소 하나에서 401이나 403이 나오는 것만으로 회귀 점검을 끝내지 않는다.

1.43.0은 요청을 고쳐 보내지 않고 거부한다

공식 릴리스 노트는 단일 점 경로 세그먼트가 포함된 요청을 400 Bad Request로 거부하도록 변경했다고 설명한다. 서버 요청 경로를 디코딩한 뒤 검사하는 코드에서도 이 동작을 확인할 수 있다. 1.43.0 릴리스 노트 · 수정 버전의 요청 경로 처리

따라서 배포 뒤 일부 비정상 경로가 이전과 달리 400으로 집계될 수 있다. 정상 요청의 실패와 패치가 의도대로 거부한 요청을 구분해 관측하는 편이 좋다. 수정된 Armeria 원본 서버에서는 해당 요청을 거부하는 것이 기대 동작이다. 프록시가 먼저 정규화하는 환경의 결과는 원본 서버 검증과 구분해 해석한다.

한 가지를 더 구분한다. 여기서 말하는 점 세그먼트는 경로의 한 구간 전체가 점인 경우다. 파일 확장자나 정상적인 숨김 파일 이름에 점이 있다는 이유로 전부 거부한다는 뜻은 아니다. 업스트림 테스트도 거부할 세그먼트와 정상 경로를 나눠 검증한다. 공식 회귀 테스트

선언한 버전과 실행 중인 버전을 따로 확인한다

먼저 빌드가 실제로 선택한 Armeria 버전을 확인한다. 직접 선언한 버전이 있어도 BOM, 상위 프레임워크나 전이 의존성의 제약이 선택 결과에 영향을 줄 수 있다.

Gradle JVM 프로젝트에서는 해당 애플리케이션 모듈의 runtimeClasspath를 확인한다. 다음은 신뢰하는 프로젝트에서 사용할 점검 예시이며, 이 글을 위해 실제 프로젝트에 실행한 명령은 아니다.

멀티 프로젝트라면 대상 모듈의 task 경로를 지정한다. runtimeClasspath가 없는 구성이라면 실제 실행 아티팩트에 대응하는 configuration을 선택해야 한다. dependencyInsight는 선택된 버전과 그 선택 이유를 살피는 도구다. Gradle 의존성 확인 안내

Maven 프로젝트는 의존성 트리를 좁혀 볼 수 있다.

이 필터는 Armeria 그룹의 의존성을 확인하기 위한 것이다. 출력에 나타난 모듈과 scope를 보고, 실제 배포에 사용한 프로파일도 맞춰야 한다. Maven dependency:tree 옵션

패치 버전이 선택됐다면 컨테이너나 배포 JAR을 다시 만들고 실행 중인 모든 인스턴스를 교체했는지 확인한다. 빌드 파일 수정, 새 이미지 생성, 운영 트래픽 전환은 서로 다른 완료 조건이다. 이전 인스턴스가 남아 있으면 새 인스턴스만 검사한 결과로 전체 배포를 안전하다고 판단할 수 없다.

회귀 검사는 거부와 정상 동작을 함께 본다

다음은 공식 수정 내용을 바탕으로 제안하는 점검 목록이다. 운영 데이터 대신 비공개 더미 리소스를 둔 승인된 테스트 환경에서 확인한다.

인증하지 않은 정상 보호 경로는 기존 인가 정책에 따라 차단되는가.

적절한 권한으로 요청한 정상 보호 경로는 계속 동작하는가.

공개 경로, 점이 포함된 정상 파일명과 .well-known 경로는 의도한 동작을 유지하는가.

공식 테스트의 문제 세그먼트와 인코딩 변형은 수정된 Armeria 원본 서버에서 400으로 거부되는가.

거부된 요청에서 보호 핸들러가 실행되지 않고 비공개 응답 본문도 나오지 않는가.

실제 프록시를 거치는 경로에서도 같은 보호가 유지되는가.

상태 코드만 수집하지 말고 핸들러 진입 여부와 응답 본문도 확인한다. 인증 실패 페이지가 200으로 반환되는 애플리케이션처럼 서비스별 응답 규칙이 다른 경우가 있기 때문이다.

또한 테스트 클라이언트나 프록시가 요청 경로를 먼저 정규화할 수 있다. 의도한 입력이 Armeria까지 도달했는지 확인하지 않으면 실제로는 다른 요청을 시험하게 된다. 원본 서버 검증은 승인된 내부 테스트 경로에서 진행하고, 검사를 위해 운영 원본을 인터넷에 새로 노출하지 않는다.

세미콜론 허용 설정은 별도 검토가 필요하다

allowSemicolonInPathComponent의 기본값은 false다. 수정 버전의 문서는 이를 true로 사용하는 Tomcat/Jetty 연동에서 경로 접두사 기반 인가에 의존하지 말라고 경고한다. 서블릿이 처리하는 matrix variable과 경로 매칭 사이의 차이를 별도로 고려해야 하기 때문이다. 1.43.0 Flags 문서의 경고

이 플래그를 사용하는 서비스는 사용 이유와 실제 처리 경로를 함께 검토한다. 1.43.0 설치를 모든 경로 해석 차이가 사라졌다는 보증으로 받아들이거나, 플래그를 무작정 바꾸는 것으로 애플리케이션 호환성 검사를 대신하지 않는다.

업데이트와 노출 대응의 완료 기준을 나눈다

대응의 기준은 1.43.0 또는 해당 수정이 포함된 후속 버전으로 업데이트하는 것이다. 즉시 배포하기 어렵다면 영향을 받는 경로의 외부 접근을 제한하거나, 실제 리소스를 처리하는 계층에서도 인가를 강제하는 방안을 검토할 수 있다. 이는 서비스별 검증이 필요한 방어 조치이며 공식 보증된 임시 패치로 제시하는 것은 아니다.

패치 배포가 과거 접근까지 되돌리지는 않는다. 영향 조건에 해당했다면 조직의 절차에 따라 관련 접근 기록과 인가 로그를 확인한다. 의심스러운 경로가 보인다는 사실만으로 침해가 확정되지는 않으며, 기록이 없다는 이유만으로 과거 노출이 없었다고 단정하기도 어렵다.

완료 기록에는 실행 아티팩트의 버전, 보호 경로와 연결 서비스, 원본·프록시 경유 회귀 결과, 남은 예외 설정을 함께 남기자. 다음에 라우팅이나 프록시를 바꿀 때도 같은 보안 경계를 다시 확인할 수 있다.

확인 기준은 2026년 11월 8일 한국시간의 공식 공지, 1.43.0 릴리스 노트와 태그 소스다. 실제 Armeria 서버나 사용자 환경에 대한 취약점 재현·배포·회귀 테스트는 수행하지 않았다. 위 명령과 점검 절차는 적용 시 검증해야 할 예시와 권고다.