아파치 톰캣 취약점이란 무엇인가: 탐지, 해결 방법 및 팁

주요 내용

• Tomcat의 위험 요소 대부분은 구형 빌드나 지원 종료된 빌드에 존재하는, 패치가 적용되지 않은 알려진 CVE에서 비롯됩니다.
• CVE-2025-24813이나 Ghostcat과 같은 영향력이 큰 취약점은 발동되기 위해 특정 위험 설정이 필요합니다.
• 탐지는 먼저 실행 중인 모든 Tomcat 버전과 어떤 위험한 설정이 활성화되어 있는지 파악하는 것부터 시작됩니다.
• 가능한 곳은 업그레이드하고, 불가능한 곳은 구성 설정을 통해 위험을 완화하며, EOL 빌드는 절대 노출시키지 마십시오.

한 개발팀이 파일 업로드 기능을 지원하기 위해 Tomcat의 기본 서블릿에 쓰기 권한을 허용하고, 이를 배포한 뒤 다음 작업으로 넘어갑니다. 이들이 간과한 점은 부분 PUT이 기본적으로 활성화되어 있다는 사실로, 이로 인해 CVE-2025-24813의 전제 조건 중 하나가 이미 갖춰진 상태가 됩니다. 만약 해당 애플리케이션이 기본 저장 위치에서 Tomcat의 파일 기반 세션 영속화 기능을 사용하고, 우연히 역직렬화에 악용될 수 있는 라이브러리를 포함하고 있다면, 그 결과 인증되지 않은 원격 코드 실행이 발생하게 됩니다. CISA는 2025년 4월 1일부터 이 취약점을 ‘알려진 악용 취약점(Known Exploited Vulnerabilities)’ 목록에 등재해 왔습니다.

이것이 바로 Tomcat 사고 뒤에 숨겨진 반복되는 패턴입니다. 기발한 새로운 공격인 경우는 드뭅니다. 대개는 구버전에서 해결되지 않은 채 방치된 알려진 문제이거나, 아무도 다시 검토하지 않은 위험한 설정 때문입니다.

이 가이드에서는 위험 요소, 알아두어야 할 CVE, 그리고 서버를 탐지하고, 패치를 적용하며, 보안을 강화하는 방법을 단계별로 설명합니다.

Apache Tomcat 취약점으로 인한 위험은 무엇인가요?

Tomcat은 가장 널리 배포된 자바 서블릿 컨테이너 중 하나이기 때문에, 항상 공격의 표적이 되고 있습니다. 취약점이 발견되면 그 여파가 단 한 대의 서버에만 국한되는 경우는 거의 없습니다.

최악의 경우는 원격 코드 실행으로, 공격자가 호스트에서 임의의 명령을 실행하는 것입니다. 그보다 한 단계 낮은 수준은 정보 유출로, 인증 절차 없이 web.xml, 소스 코드 또는 구성 비밀 정보와 같은 파일이 열람되는 경우입니다. 그 다음으로는 콘텐츠 삽입이 있는데, 이는 악성 데이터가 업로드된 파일이나 세션 데이터에 삽입되는 것을 말합니다. 또한, 침해당한 Tomcat 인스턴스는 네트워크의 나머지 부분으로 측면 이동을 위한 편리한 교두보가 됩니다.

현실 점검: “업그레이드했으니 문제없다”는 생각은 일부 인스턴스가 지원 종료된 브랜치를 실행 중이라면 무의미해집니다. Tomcat 8.5는 2024년 3월 31일에 업스트림 지원이 종료되었으며, CVE-2025-24813에 대한 업스트림 수정 패치를 한 번도 받지 못했습니다. EOL 이후 패치를 제공하는 벤더가 없다면, 다른 서버에 아무리 많은 패치를 적용하더라도 해당 서버들은 계속해서 보안 취약점에 노출된 상태로 남게 됩니다.

Apache Tomcat의 일반적인 취약점

Tomcat의 CVE는 몇 가지 주요 주제를 중심으로 분포되어 있습니다. 안전하지 않은 요청 처리, 프로토콜 신뢰, 경로 해결, 인증 로직, 그리고 보안이 취약한 암호화 기본 설정 등이 그 대부분을 차지합니다. 다음은 알아두면 좋은 CVE 목록으로, Apache에서 공개한 영향을 받는 버전과 수정된 버전이 함께 기재되어 있습니다.

CVE-2025-24813 (부분적 PUT 원격 코드 실행)

이 사례는 경로 동등성 버그와 안전하지 않은 역직렬화를 결합한 것으로, 전제 조건은 구체적이지만 전적으로 현실적입니다. 기본 서블릿에서 쓰기 기능이 활성화되어 있어야 하는데, 이는 기본적으로 비활성화되어 있습니다. 부분 PUT이 활성화되어 있어야 하며, 이는 기본적으로 활성화되어 있습니다.

해당 애플리케이션은 기본 저장 위치에서 Tomcat의 파일 기반 세션 영구 저장 기능을 사용해야 합니다. 또한, 이 애플리케이션에는 역직렬화 공격에 악용될 수 있는 라이브러리가 포함되어 있어야 합니다. 이 네 가지 조건이 모두 충족되면, 공격자는 부분 PUT 요청을 통해 직렬화된 페이로드를 준비한 뒤, 일치하는 JSESSIONID를 포함하는 후속 요청을 보내 실행을 유발할 수 있습니다.

이 취약점은 2025년 3월 10일에 공개되었으며, CISA는 2025년 4월 1일에 이를 ‘알려진 악용 취약점’ 목록에 추가했습니다.

CVE-2020-1938 (Ghostcat)

Ghostcat은 AJP 커넥터의 파일 읽기 및 포함 취약점으로, 과거에는 포트 8009에서 활성화되어 제공되었으며 모든 구성된 주소에 바인딩되어 있었습니다. 해당 포트에 접근할 수 있는 원격의 인증되지 않은 공격자는 WEB-INF 및 META-INF 디렉터리를 포함하여 웹 애플리케이션 내 어디서든 임의의 파일을 반환할 수 있었으며, Tomcat이 애플리케이션 내의 모든 파일을 JSP로 처리하도록 유도할 수 있었습니다. 애플리케이션이 업로드된 파일을 웹 애플리케이션 내부에 저장하는 경우, 이 취약점은 코드 실행으로 이어질 수 있습니다. 이 취약점에 대한 수정 사항은 7.0.100, 8.5.51 및 9.0.31 버전에 반영되었으며, 해당 버전부터 아파치는 기본 server.xml 파일에서 이 커넥터를 주석 처리하고, 기본 바인드 주소를 루프백으로 변경하며, AJP 비밀 키 사용을 필수로 지정했습니다. 이 취약점은 2022년 3월 3일부터 KEV 카탈로그에 등재되어 있습니다.

CVE-2025-55752 (디렉터리 트래버설)

Rewrite Valve의 한 회귀 오류로 인해, URL이 디코딩되기 전에 정규화된 재작성 URL이 생성되었습니다. 재작성 규칙이 쿼리 매개변수를 URL로 이동시키는 경우, 공격자는 요청 URI를 조작하여 /WEB-INF/ 및 /META-INF/에 대한 보호 조치를 우회할 수 있었으며, PUT 메서드가 활성화된 경우 코드 실행까지 가능했습니다. Apache 측은 PUT 메서드가 일반적으로 신뢰할 수 있는 사용자로만 제한되기 때문에 이러한 조합이 발생할 가능성은 낮다고 밝혔지만, 이 사례는 여전히 참고할 가치가 있습니다. 이는 한 릴리스에서 수정된 내용이 다른 릴리스에서 은연중에 다시 위험 요소를 초래할 수 있음을 보여줍니다.

CVE-2026-29146 (EncryptInterceptor 패딩 오라클)

기본 설정이 오히려 취약점이 될 수 있다는 점을 다시 한번 상기시켜 주는 사례입니다. 클러스터 트래픽을 암호화하는 데 사용되는 EncryptInterceptor는 기본적으로 패딩 오라클 공격에 취약한 CBC 모드로 설정되어 있었습니다. 이 인터셉터를 기본 암호 모드로 실행하는 모든 배포 환경은 관리자가 특별한 설정을 선택하지 않았더라도 잠재적으로 노출될 위험이 있었습니다. TuxCare의 Endless Lifecycle Support가 적용되는 버전의 경우, CVE 트래커에서 버전별로 백포트된 수정 사항이 추적되며, 이를 통해 수정 사항이 적용된 지원 대상 릴리스를 정확히 확인할 수 있습니다.

CVE-2026-34486 (EncryptInterceptor 우회)

CVE-2026-29146에 대한 수정 사항은 9.0.116, 10.1.53 및 11.0.20에 포함되었으나, 이로 인해 EncryptInterceptor가 완전히 우회될 수 있는 오류가 발생했습니다. 여기서 Tomcat 11 버전에 주목하십시오. 이 수정 프로그램은 11.0.19용으로 작성되었으나, 해당 릴리스 투표가 부결되어 11.0.20이 실제로 다운로드할 수 있는 첫 번째 빌드가 되었습니다. 정확히 이 세 가지 릴리스가 영향을 받았으며, 9.0.117, 10.1.54 및 11.0.21에서 이 문제가 해결되었습니다. CISA는 2026년 8월 4일에 이 취약점을 KEV 카탈로그에 추가했으므로, 첫 번째 수정판에서 업그레이드를 중단한 클러스터는 아직 업그레이드가 완료되지 않은 것입니다.

CVE-2026-55957 (GSSAPI 인증 우회)

JNDIRealm이 GSSAPI를 사용하여 바인드를 인증하도록 구성되었을 때, 공격자는 올바른 비밀번호 없이도 인증을 통과할 수 있었습니다. 무차별 대입 공격도, 도난당한 인증 정보도 필요하지 않았습니다. 단순히 인증 로직이 검증 절차를 제대로 적용하지 못했을 뿐입니다. 이상한 점은 이 문제의 경과입니다. 수정 사항은 9.0.102, 10.1.39, 11.0.5 버전에 조용히 반영되었으나, 이 문제는 1년 이상이 지난 2026년 6월 29일에야 비로소 공개되었습니다. 9.0.100, 10.1.36 또는 11.0.4 이하 버전을 사용 중이라면 주의가 필요합니다. 이보다 최신 버전은 CVE 번호가 부여되기 전부터 이미 해당 문제가 해결되었습니다.

CVE-2026-43512 (다이제스트 인증 “null” 비밀번호)

이 취약점의 발생 원인은 믿기 힘들 정도로 단순합니다. Tomcat의 Digest 인증기는 구성된 Realm에 존재하지 않는 사용자 이름에 대해 “null”이라는 문자열을 유효한 비밀번호로 인정했습니다. 따라서 시스템에 등록되지 않은 사용자라도 이 문자열을 추측하기만 하면 인증을 통과할 수 있었습니다. 이 취약점이 미치는 영향 범위는 Digest 인증 뒤에 무엇이 배치되어 있는지에 따라 달라지지만, 취약점을 유발하기 위한 전제 조건은 매우 간단합니다. 이 취약점은 2026년 5월 12일에 공개되었으며, 9.0.118, 10.1.55 및 11.0.22 버전에서 수정되었습니다.

알고 계셨나요? 2025년 3월, 팔로알토 네트웍스는 CVE-2025-24813 및 이와 관련된 두 가지 Apache Camel 취약점과 연관된 125,856건의 스캔, 탐색 및 공격 시도를, 해당 취약점이 공개된 지 3주 만에 70개국 이상에서 발생한 것으로 확인되어 차단했습니다.

Apache Tomcat 취약점을 탐지하고 평가하는 방법

탐지는 대부분 자산 파악의 문제입니다. 발견하지 못한 것은 패치를 적용할 수 없으며, 대규모 환경에서는 목록에 한 번도 포함되지 않은 Tomcat 인스턴스가 쌓이는 경향이 있습니다. 다음 세 단계를 순서대로 진행하십시오.

모든 인스턴스와 버전에 대한 인벤토리 작성

임베디드 Tomcat 서버를 실행하는 Spring Boot 애플리케이션 등, Tomcat을 임베드한 애플리케이션을 포함하여 모든 Tomcat 배포 항목을 찾아보세요. 폴더 이름이 아닌 정확한 버전을 기록해 두세요. 설치 파일은 복사되거나 이름이 변경될 수 있으므로, 경로 정보만으로는 정확한 버전을 파악할 수 없습니다.

전문가 팁: 설치 경로를 추측하기보다는 번들에 포함된 버전 확인 스크립트를 실행하세요. $CATALINA_HOME/bin/version.sh를 실행하면 정확한 Tomcat 및 JVM 버전이 출력되며, 이는 실제 평가에 필요한 데이터입니다.

버전을 알려진 CVE와 매핑

각 버전을 NVD, 해당 브랜치에 대한 Tomcat 보안 권고 사항, 그리고 CISA의 KEV 카탈로그와 대조하여 확인하십시오. KEV에 등재된 항목은 모두 현재 악용되고 있는 것으로 간주하여 처리 우선순위를 최우선으로 높여야 합니다.

위험한 구성 플래그를 확인하십시오

일부 Tomcat CVE는 특정 설정이 활성화된 경우에만 문제가 발생합니다. 기본 서블릿의 readonly 속성이 false로 설정되어 있는지, allowPartialPut이 활성화되어 있는지, AJP 커넥터에 접속 가능한지, 그리고 JNDIRealm, Digest 인증 또는 EncryptInterceptor가 사용 중인지 여부를 확인하십시오. 이러한 구성 여부가 단순히 존재하는 CVE와 실제로 악용 가능한 CVE를 구분하는 기준이 됩니다.

Apache Tomcat 취약점을 수정하고 패치하는 방법

수정된 릴리스가 존재할 경우 Tomcat에 패치를 적용하는 것은 대개 간단합니다. 어려운 점은 업그레이드가 불가능한 서버나, 이미 지원이 종료된 버전을 사용 중인 서버의 경우입니다.

패치가 적용된 릴리스로 업그레이드하기

적극적으로 유지 관리되는 브랜치의 경우, 고정 버전으로 전환하고 위 표에 기재된 CVE별 수정 횟수를 목표치가 아닌 최소 기준으로 삼으십시오. 해당 브랜치의 최신 릴리스 버전으로 업데이트하십시오. 현재 기준으로 9.0.121, 10.1.59 또는 11.0.25가 해당됩니다. 특정 CVE에 대한 최소 수정 사항만 적용하고 중단할 경우, 그 이후에 공개된 모든 수정 사항을 그대로 떠안게 됩니다. CVE-2026-29146이 바로 이를 경고하는 사례입니다. 이 CVE에 대한 초기 수정 사항은 9.0.116, 10.1.53, 11.0.20에 포함되었으나, 이 세 릴리스 모두 패치 우회 취약점인 CVE-2026-34486에 취약한 것으로 밝혀졌기 때문에, 실제 최소 기준은 9.0.117, 10.1.54 또는 11.0.21입니다.

TuxCare의 Apache Tomcat용 CVE 트래커는 특정 구버전이나 지원 종료(EOL) 버전에 어떤 CVE가 영향을 미치는지 확인하는 데 유용합니다.

아직 업그레이드를 할 수 없는 경우 구성상의 완화 조치를 적용하십시오

버전 업그레이드를 미뤄야 한다면, 구성 계층에서 악용 경로를 차단하십시오. 기본 서블릿에 대해 `readonly`를 `true`로 설정해 두십시오. 이는 기본값이며, 이를 통해 `writable-servlet` 전제 조건이 자동으로 제거됩니다. 쓰기 작업이 정말로 필요한 경우, 애플리케이션에서 부분 업로드가 필요하지 않은 곳에서는 allowPartialPut을 false로 설정하십시오. 이 매개변수는 8.5.100 및 그 이전 9.0 빌드를 포함하여 수년 동안 존재해 왔으므로, 패치가 적용되지 않은 서버에서도 실제로 사용할 수 있는 옵션입니다. 또한 AJP 커넥터를 사용하지 않는다면 비활성화하고, 사용하는 경우에는 프록시가 실제로 필요로 하는 인터페이스에 바인딩하고 비밀 키를 할당하십시오.

주의: 부분 PUT은 기본적으로 활성화되어 있지만, 파일 기반 세션 지속성은 활성화되어 있지 않으며, 쓰기 가능한 기본 서블릿도 활성화되어 있지 않습니다. 누군가가 파일 업로드 기능을 위해 기본 서블릿을 쓰기 가능으로 전환하는 순간, 비기본 전제 조건 중 하나가 충족됩니다. 기본 저장 위치에 파일 기반 세션 지속성을 추가하고, 역직렬화에 악용될 수 있는 라이브러리를 결합하면 CVE-2025-24813의 전체 공격 체인이 활성화됩니다. “쓰기 허용” 설정을 단순한 편의 기능 스위치가 아닌 보안상의 결정으로 간주하고, 해당 설정을 검토하는 동안 나머지 두 가지 조건에 대해서도 철저히 점검하십시오.

수동 또는 자동 패치 적용 방식을 선택하고 EOL 버전을 처리하세요

패치 방식은 함대 규모, 준수해야 할 변경 관리 요건의 정도, 그리고 해당 버전에 대해 업스트림에서 여전히 수정 사항이 제공되는지 여부에 따라 달라집니다.

Tomcat은 상당히 독립적인 서블릿 컨테이너이며, 대부분의 보안 권고 사항은 Catalina, Coyote, Jasper와 같은 Tomcat 자체 구성 요소를 대상으로 합니다. 그러나 프로덕션 환경에서는 JDK와 애플리케이션에 포함된 모든 라이브러리를 지속적으로 모니터링해야 합니다. 이러한 종속성들 자체에도 취약점이 존재하기 때문입니다. CVE-2025-24813과 같은 사례에서, 번들된 라이브러리는 안전하지 않은 역직렬화를 코드 실행으로 전환하는 가젯 체인을 제공하는 원인이기도 합니다.

현재 실행 중인 빌드에 업스트림 수정 사항이 더 이상 반영되지 않을 때, 바로 이때 TuxCare의 Apache Tomcat ‘무한 라이프사이클 지원’이 빛을 발합니다. 이 서비스는 TuxCare 리포지토리에서 제공되는 고정된 Tomcat 릴리스에 CVE 수정 사항을 역포트하므로, 테스트하지 않은 버전으로 업그레이드할 필요 없이 기존 환경을 그대로 유지할 수 있습니다. 현재 지원 범위는 선별된 Tomcat 7, 8.5, 9.0 및 10.1 릴리스, 즉 7.0.109, 8.5.100, 9.0.46, 9.0.50, 9.0.75, 9.0.83, 9.0.87, 9.0.90, 9.0.100, 10.1.18, 10.1.42이며, 문서에는 최신 지원 매트릭스가 수록되어 있습니다. 이 범위가 중요한 이유는 문제가 단순히 브랜치의 지원 종료 시점에 그치지 않기 때문입니다. Tomcat 7과 8.5는 모두 지원 종료 시점을 훨씬 지났으며, 8.5는 2024년 3월 31일, Tomcat 9.0은 2027년 3월 31일로 지원 종료가 발표되었습니다. 하지만 구버전인 9.0이나 10.1 릴리스에 고정된 애플리케이션은 해당 브랜치의 후속 릴리스에서 Apache가 추가하는 수정 사항을 적용받지 못합니다.

간단히 말해서, 사용 중인 Tomcat 버전에 여전히 업스트림 패치가 제공된다면 정해진 주기에 따라 업그레이드해야 합니다. 지원 종료(EOL) 상태이거나, 고정된 버전이 업스트림에서 이미 넘어간 경우라면, 공급업체가 지원하는 패치를 적용하거나 마이그레이션을 계획해야 합니다. 패치를 적용하지 않은 상태로 운영하는 것은 선택지가 아닙니다.

Apache Tomcat 보안을 위한 모범 사례

Tomcat의 보안을 강화하는 것은 복잡한 제어 수단을 도입하는 것보다, 안전한 기본 설정을 그대로 유지하고, 사용하지 않는 기능은 비활성화하며, 노출된 부분은 철저히 통제하는 데 더 중점을 둡니다. 몇 가지 일관된 습관만으로도 흔히 발생하는 취약점 대부분을 막을 수 있습니다.

지원되는 버전을 계속 사용하십시오

Tomcat과 JDK 모두 보안 패치가 계속 제공되는 버전을 유지하십시오. 업스트림에서 더 이상 지원하지 않는 빌드의 경우, Apache Tomcat의 ‘무기한 라이프사이클 지원(Endless Lifecycle Support)’을 통해 강제 마이그레이션 없이도 패치를 지속적으로 제공받을 수 있습니다.

커넥터 잠금 및 기본 서블릿

Tomcat의 노출된 표면에 최소 권한 원칙을 적용하십시오. 특별한 사유가 없는 한 기본 서블릿을 읽기 전용으로 유지하고, 사용하지 않는 경우 부분 PUT을 비활성화하며, 신뢰할 수 없는 네트워크에서 AJP에 접근할 수 없도록 반드시 설정하십시오.

알아두면 좋은 팁: AJP를 사용하는 경우, 커넥터를 신뢰할 수 있는 프록시가 실제로 필요로 하는 인터페이스에 바인딩하고, 네트워크 계층에서 해당 인터페이스에 대한 접근을 제한하며, 비밀 키를 설정하세요. Ghostcat이 그토록 위험한 이유는, 기본 설치 시 해당 포트가 10년 넘게 열려 있었기 때문이었습니다.

Tomcat을 리버스 프록시 뒤에 배치하고 모니터링하세요

대부분의 생산 환경 배포에서는 애플리케이션 커넥터를 직접 노출하지 말고, Tomcat 앞에 보안이 강화된 리버스 프록시를 배치하십시오. 샘플 애플리케이션은 제거하고, 관리자 애플리케이션을 계속 사용할 경우 이에 대한 접근을 엄격히 제한하십시오. 액세스 로그를 주시하여 비정상적인 파일 요청, 특히 /WEB-INF/ 경로를 탐색하거나 예상치 못한 PUT 요청을 보내는 경우를 확인하십시오.

TuxCare로 Apache Tomcat을 안전하게 보호하세요

아파치 톰캣의 취약점은 스스로 드러나는 경우가 거의 없습니다. 누군가가 서버를 스캔하기 전까지는 기본 설정이나 지원 종료된 버전에 조용히 숨어 있습니다. 해결 방법은 지루할 수 있지만 확실합니다. 현재 실행 중인 환경을 파악하고, 수정 패치가 있는 부분은 패치를 적용하며, 패치가 없는 부분은 위험을 완화하고, 절대로 지원이 종료된 빌드를 노출된 상태로 두지 마십시오. 업스트림에서 더 이상 지원하지 않는 릴리스를 계속 사용 중이라면, TuxCare가 아파치 톰캣을 위해 어떻게 ‘끝없는 라이프사이클 지원(Endless Lifecycle Support)’을 제공하는지 확인해 보십시오.

요약

기사 이름

아파치 톰캣 취약점이란 무엇인가: 탐지, 해결 방법 및 팁

설명

Apache Tomcat 서버를 안전하게 보호하세요! 취약점을 파악하고, 패치를 적용하며, 강력한 보안을 위한 모범 사례를 따르는 방법을 알아보세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고