Apache Tomcat CVE-2025-24813

이 블로그 글의 AI 요약으로 바로 가기

주요 요점:

CVE-2025-24813은 인증되지 않은 공격자가 Tomcat 서버에서 원격 코드 실행, 정보 유출 또는 콘텐츠 주입을 수행할 수 있게 할 수 있습니다. 단, 이는 기본 서블릿의 쓰기 권한이 활성화되어 있고(기본값은 비활성화됨) 몇 가지 다른 비기본 조건이 충족될 경우에만 해당됩니다.
영향을 받은 팀은 Tomcat 배포 현황을 파악하고, 보안 제약 조건이 적용되어 있는지 확인한 후, 가능한 한 빨리 패치된 버전으로 업그레이드해야 합니다.
업그레이드가 어렵거나 오래된 Tomcat 환경의 경우, 패치가 적용되지 않은 지원 종료 버전에 의존하기보다는 명확한 위험 완화 계획을 수립해야 합니다.

실제 운영 환경에서 Apache Tomcat 인스턴스를 관리하고 계신다면, CVE-2025-24813은 즉각적인 조치가 필요한 취약점 중 하나입니다. 이 취약점이 화려하거나 언론의 주목을 받고 있어서가 아니라, 의외로 흔히 볼 수 있는 구성 환경에서 실제로 악용될 수 있는 위험을 내포하고 있기 때문입니다.

이는 라즈베리 파이에서 디버그 모드로 Tomcat을 실행하는 사용자에게만 영향을 미치는 이론적인 극단적인 사례가 아닙니다. 우리는 실제 운영 환경에 영향을 미칠 수 있으며, 공격자가 애플리케이션 인프라에 침투할 발판을 마련해 줄 수도 있는 취약점에 대해 이야기하고 있습니다. CVE-2025-24813이 실제로 무엇인지, 누가 이에 대해 우려해야 하는지, 그리고 일주일을 위기로 몰아넣지 않으면서 이 문제를 해결하는 방법을 자세히 살펴보겠습니다.

CVE-2025-24813이란 무엇인가요?

CVE-2025-24813은 Apache Tomcat의 경로 동등성 취약점으로, 인증 없이 원격 코드 실행, 정보 유출 또는 업로드된 파일에 대한 콘텐츠 주입을 유발할 수 있습니다. 실질적으로, 취약한 Tomcat 인스턴스에 접근할 수 있는 공격자는 악성 파일을 업로드하고 Tomcat을 속여 이를 실행하게 만들 수 있으며, 이 과정에서 별도의 인증 정보가 필요하지 않습니다.

이 취약점은 Tomcat의 부분 PUT 처리 방식이 임시 파일 경로를 구성하는 방식에서 비롯됩니다. 원래 구현에서는 사용자가 제공한 파일 이름과 경로를 기반으로 임시 파일 이름을 생성하되, 경로 구분자를 점(.)으로 대체했습니다. Tomcat의 파일 기반 세션 지속 기능과 결합된 이 설계로 인해, 공격자는 조작된 Java 직렬화 페이로드를 세션 디렉터리에 업로드한 다음, 일치하는 JSESSIONID 쿠키를 포함한 후속 GET 요청으로 역직렬화를 유발할 수 있게 합니다. 그 결과 원격 코드 실행이 발생합니다.

특히 우려되는 점은 인증 절차가 필요하지 않으며, 페이로드를 Base64로 인코딩하여 일반적인 탐지 규칙을 회피할 수 있다는 사실입니다. 공격자가 파일 경로 충돌과 역직렬화 트리거를 파악하기만 하면, 공격은 기계적으로 이루어집니다.

하지만 이 취약점을 악용하려면 몇 가지 필수 조건이 충족되어야 합니다. 악용을 위해서는 다음 조건이 모두 충족되어야 합니다: 기본 서블릿에서 쓰기 권한이 활성화되어 있어야 합니다(기본적으로 비활성화되어 있음 – readonly 매개변수)에서 쓰기 권한이 활성화되어 있어야 합니다. conf/web.xml 파라미터를 false로 설정되어야 함), Tomcat이 파일 기반 세션 지속성(기본값 아님)을 사용하도록 구성되어 있어야 하며, 애플리케이션의 클래스패스에 공격자가 악용할 수 있는 역직렬화 가젯 체인이 포함되어 있어야 합니다. 아파치는 바로 이러한 이유로 이 CVE를 'Critical'이 아닌 'Important' 등급으로 처음 평가했습니다. 하지만 이러한 전제 조건이 모두 충족될 경우, 서버가 완전히 장악되는 심각한 영향을 미치며, CISA는 공개된 지 몇 주 만에 이를 '알려진 악용 취약점(Known Exploited Vulnerabilities)' 목록에 추가했습니다. –

어떤 Tomcat 버전이 영향을 받나요?

CVE-2025-24813은 Apache Tomcat의 여러 분기에 영향을 미치지만, 정확한 취약점 버전 범위는 사용 중인 주요 버전에 따라 다릅니다. 세부 내용은 다음과 같습니다:

Apache Tomcat 11.0.x 버전 11.0.0-M1부터 11.0.2까지 취약점이 있습니다. 이 문제는 11.0.3버전에 적용되었으므로, 패치를 받으려면 11.0.3 이상 버전을 사용해야 합니다.
Apache Tomcat 10.1.x 버전 10.1.0-M1부터 10.1.34까지 취약점이 있습니다. 수정 사항은 10.1.35 및 이후 릴리스에 포함되어 있습니다.
Apache Tomcat 9.0.x 버전 9.0.0.M1부터 9.0.98까지 취약점이 있습니다. 9.0.99 버전 이상이 필요합니다.
Apache Tomcat 8.5.x 이 CVE가 공개되기 전인 2024년 3월 31일에 지원 종료되었습니다. Apache Tomcat 프로젝트는 8.5 버전에 대한 커뮤니티 패치를 제공하지 않았으므로, 지원되는 브랜치로 마이그레이션하거나 상용 확장 지원 제공업체를 통해 보장을 받지 않는 한 모든 8.5.x 배포 환경은 영구적으로 취약한 상태에 놓이게 됩니다.

특히, Tomcat 8.5 및 그 이전 버전(8.0.x 및 7.0.x 브랜치)은 모두 지원 종료(EOL) 단계에 접어들었으며, CVE-2025-24813에 대한 커뮤니티 패치를 제공받지 못하게 됩니다. 이러한 버전을 사용 중이라면, 지원되는 버전으로 마이그레이션하거나 상용 확장 지원 제공업체를 통해 보안을 유지하는 것만이 유일한 선택지입니다. 두 가지 방법에 대해서는 잠시 후에 자세히 설명하겠습니다.

이 점에 유의해야 할 핵심은, 이 문제가 단순히 최신 베타 버전이나 잘 알려지지 않은 구성에만 국한되지 않는다는 것입니다. 이 취약점은 현재 실제 운영 환경에 활발히 배포되고 있는 주요 Tomcat 버전 전반에 걸쳐 있으며, 수많은 기업용 애플리케이션을 구동하는 검증된 9.0 및 8.5 버전도 포함됩니다.

악용 시나리오 이해하기

이 위험을 제대로 파악하려면, 이 취약점이 실제 운영 환경에서 언제, 어떤 방식으로 문제가 되는지 이해해야 합니다.

CVE-2025-24813의 악용 시나리오는 Tomcat의 기본 서블릿(직접적인 파일 요청을 처리하는 구성 요소)과, 클라이언트가 여러 번의 요청에 걸쳐 파일의 일부를 업로드할 수 있게 해주는 ‘부분 PUT(partial PUT)’ 기능에 초점을 맞추고 있습니다. 기본적으로 기본 서블릿은 읽기 전용이며 PUT 요청을 완전히 무시하므로, 대부분의 설치 환경에서는 이 취약점이 노출되지 않습니다. 이 취약점은 관리자가 명시적으로 readonly 매개변수를 false 로 설정했을 때만 악용될 수 있습니다. conf/web.xml에서 이 매개변수를

여기서 흥미로운 점은, 쓰기 기능이 활성화되어 있더라도 악용을 위해서는 추가적인 조건이 필요하다는 것입니다. Tomcat은 파일 기반 세션 지속성( FileStore 매니저를 사용해야 하며), 애플리케이션의 클래스패스에 역직렬화 가젯 체인이 포함되어야 하며, 공격자가 네트워크를 통해 업로드 엔드포인트에 접근할 수 있어야 합니다.

이러한 조건이 모두 갖춰지면 공격 체인은 매우 짧아집니다. 공격자는 직렬화된 Java 페이로드를 자신이 제어하는 경로로 업로드하는 부분 PUT 요청을 보냅니다. Tomcat의 부분 PUT 구현은 요청 URI를 임시 파일 이름으로 변환할 때 경로 구분자를 점(.)으로 대체하기 때문에, 업로드된 파일은 Tomcat이 나중에 세션 데이터를 검색할 위치에 정확히 저장됩니다. 이후 조작된 JSESSIONID 쿠키를 포함한 후속 GET 요청은 Tomcat이 파일을 역직렬화하고, 가젯 체인을 실행하며, 공격자에게 원격 코드 실행 권한을 부여하게 만듭니다. 어떤 단계에서도 인증이 필요하지 않습니다.

실질적으로 이는 “공격자가 엔드포인트를 하나 더 볼 수 있다”는 의미가 아닙니다. “공격자가 페이로드를 업로드하고, 요청을 하나 더 보내며, Tomcat 프로세스로서 코드를 실행한다”는 뜻입니다.

애플리케이션이 기본 서블릿에 대한 쓰기 권한을 허용하지 않거나 파일 기반 세션 영구 저장을 사용하지 않는다면, 이 CVE의 원격 코드 실행 경로에 노출되지 않습니다. 다만, 약간 다른 조건 하에서는 정보 유출이나 콘텐츠 주입 취약점에 노출될 가능성이 있으므로 패치를 적용하는 것이 여전히 올바른 조치입니다. 단, 패치 적용의 시급성은 전적으로 사용자의 구성에 따라 달라집니다.

위험 노출 정도 평가

패치 작업을 시작하기 전에, 사용자의 특정 Tomcat 배포 환경이 실제로 CVE-2025-24813의 영향을 받는지 여부를 잠시 확인해 보는 것이 좋습니다.

먼저, Tomcat 버전을 확인하세요. 당연한 말처럼 들리겠지만, 여러 Tomcat 인스턴스가 있는 복잡한 환경에서는 팀들이 전체 인벤토리를 제대로 파악하지 못하는 경우가 의외로 많습니다. 앞서 언급한 패치 적용 버전보다 오래된 버전을 사용 중이라면 잠재적인 보안 취약점에 노출될 수 있습니다. Docker 컨테이너에서 실행 중이거나, 마이크로서비스 배포 환경에 숨겨져 있거나, 다른 애플리케이션에 내장된 Tomcat 인스턴스들도 잊지 마십시오.
Second, review your security constraint configurations. Look at the ‘web.xml’ files (and any programmatic security configurations) for your deployed applications. Are you using ‘<security-constraint>’ elements to protect resources? Are you relying on Tomcat’s built-in authentication mechanisms? If the answer is yes, you need to treat this vulnerability seriously.
셋째, 배포 아키텍처를 검토해 보십시오. Tomcat 인스턴스가 인터넷에 직접 노출되어 있습니까, 아니면 리버스 프록시, API 게이트웨이 또는 기타 보안 계층 뒤에 위치해 있습니까? 다층 방어(defense in depth)는 언제나 바람직하지만, WAF나 리버스 프록시가 이 취약점으로부터 자동으로 보호해 준다고 가정해서는 안 됩니다. CVE-2025-24813을 악용하는 데 필요한 요청 조작은 이러한 보안 계층을 아무 문제 없이 통과할 수 있습니다.
마지막으로, 무엇을 보호하고 있는지 생각해 보십시오. 기술적으로 취약점이 있다고 해도, 실제 위험은 공격자가 보안 장치를 우회하여 어떤 정보에 접근할 수 있는지에 따라 달라집니다. 고객 데이터나 시스템 제어 기능에 접근할 수 있는 관리자 인터페이스라면 위험도가 매우 높습니다. 반면, 정제된 지표만 표시하는 내부 모니터링 엔드포인트라면 대응의 시급성은 달라집니다.

여기서 목표는 취약점을 경시하거나 패치 적용을 미루도록 설득하려는 것이 아닙니다. 특히 수십 개 또는 수백 개의 Tomcat 인스턴스를 관리하고 있는 경우, 위험 프로필을 파악하여 적절한 우선순위에 따라 대응 조치를 취할 수 있도록 하는 데 있습니다.

완화 조치 및 패치 적용 단계

CVE-2025-24813에 대한 가장 기본적이면서도 권장되는 해결책은 간단합니다. 바로 패치가 적용된 버전의 Apache Tomcat으로 업그레이드하는 것입니다. 하지만 실제 운영 환경에서 Tomcat을 관리해 본 사람이라면 누구나 알다시피, “그냥 업그레이드하면 된다”는 말은 말처럼 쉽지 않습니다.

원활한 업그레이드 경로

업그레이드가 문제없이 진행된다면, 그 과정은 다음과 같습니다:

모든 배포 환경에서 현재 Tomcat 버전을 확인하십시오 모든 배포 환경에서 확인하십시오. catalina.sh version 을 사용하거나 Tomcat 설치 디렉터리의 버전 번호를 확인하십시오. 최신 정보가 아닐 수 있는 문서나 운영 매뉴얼에만 의존하지 마십시오.
Apache Tomcat 공식 웹사이트에서 Apache Tomcat 공식 웹사이트에서 다운로드하십시오. Tomcat 11의 경우 11.0.3 이상 버전을, 10.1의 경우 10.1.35 이상 버전을, 9.0의 경우 9.0.99 이상 버전을 다운로드하십시오. 아직 Tomcat 8.5를 사용 중이라면 커뮤니티 패치가 제공되지 않으므로, 아래의 “즉시 업그레이드가 불가능한 경우”를 참조하십시오. 항상 공식 출처에서 다운로드하고, 임의의 미러 사이트나 타사 저장소에서는 절대 다운로드하지 마십시오.
먼저 비생산 환경에서 업그레이드를 테스트하십시오. 이는 불필요한 과민반응이 아니라 기본적인 운영 수칙입니다. Tomcat을 업그레이드하면 때때로 예상치 못한 동작 변화나 성능 특성이 나타날 수 있습니다. 애플리케이션이 여전히 정상적으로 작동하는지, 성능 지표가 적정 수준인지, 모니터링 및 로깅 통합 기능이 여전히 작동하는지 확인하십시오.
프로덕션 배포 계획을 수립하십시오. 배포 시간대, 트래픽 패턴, 롤백 절차를 고려하십시오. 로드 밸런서 뒤에 Tomcat을 실행 중인 경우 인스턴스를 하나씩 업그레이드할 수 있습니다. 제약이 더 많은 환경이라면 유지보수 시간이 필요할 수 있습니다. 만일의 사태에 대비해 검증된 롤백 계획을 마련해 두십시오.
업그레이드를 적용하고 업그레이드를 적용하고 패치된 버전이 실행 중인지 확인하십시오. 업그레이드가 성공했다고 단순히 가정하지 말고, 배포 후 버전 번호를 실제로 확인하십시오.

구성 기반 완화 조치

업그레이드가 근본적인 해결책이긴 하지만, 단기적으로 공격 위험을 줄일 수 있는 설정 변경 사항이 있을 수 있습니다. 보안 제약 조건을 검토하여 가능한 한 구체적이고 엄격하게 설정되어 있는지 확인하십시오. 지나치게 광범위한 URL 패턴이나 느슨하게 정의된 제약 조건은 공격 표면을 확대시킬 수 있습니다.

아키텍처에 리버스 프록시나 API 게이트웨이 구성 요소가 포함되어 있다면, 해당 수준에서 추가적인 인증 계층을 구현하는 것을 고려해 보십시오. 다시 말해, 이는 패치 작업을 대체할 수는 없지만, 다층 방어 체계를 강화하는 데 도움이 됩니다.

여러 웹 애플리케이션을 호스팅하는 Tomcat 인스턴스를 운영 중이라면, 어떤 애플리케이션이 배포되어 있는지, 그리고 그 모든 애플리케이션이 정말 필요한지 점검해 보십시오. 배포된 애플리케이션의 수를 줄이면 잠재적인 공격 표면도 축소됩니다.

운영상 고려 사항

패치 적용 과정에서 주의해야 할 몇 가지 실용적인 사항들은 다음과 같습니다:

재시작 요건. Tomcat을 업그레이드하려면 재시작이 필요합니다. 이는 무중단 배포를 위한 아키텍처를 구축하지 않은 경우 애플리케이션에 다운타임이 발생함을 의미합니다. 이에 따라 계획을 수립하십시오.
구성 파일 호환성. 대부분의 Tomcat 업그레이드는 기존 구성 파일과 하위 호환되지만, 항상 그런 것은 아닙니다. server.xml, web.xml또는 기타 구성 파일에 적용한 사용자 정의 사항에 각별히 주의하십시오.
JVM 버전 요구 사항. Tomcat 버전에 따라 필요한 Java 버전도 다릅니다. Tomcat 10.1은 Java 11이 필요하며, Tomcat 11은 Java 17 이상이 필요합니다. 이전 버전의 Tomcat에서 업그레이드하는 경우 JVM도 함께 업그레이드해야 할 수 있어 작업이 복잡해질 수 있습니다.
라이브러리 및 커넥터 호환성. Tomcat과 함께 JDBC 드라이버, JMS 커넥터 또는 기타 라이브러리를 사용하는 경우, 업그레이드하려는 버전과 호환되는지 확인하십시오. 이는 특히 오래된 엔터프라이즈 애플리케이션의 경우 중요합니다.
모니터링 및 APM 에이전트. Tomcat에 연동되는 모니터링 에이전트나 APM 도구를 사용 중인 경우, 업그레이드 후에도 정상적으로 작동하는지 확인하십시오. 일부 에이전트는 Tomcat 버전 변경에 민감할 수 있습니다.

업그레이드가 당장 불가능한 경우

현실적으로 생각해 봅시다. CVE가 공개되는 즉시 모든 업무를 중단하고 모든 Tomcat 인스턴스를 일괄적으로 업그레이드할 수 있는 조직은 많지 않습니다. 때로는 특정 Tomcat 버전이 번들로 제공되고 최신 버전을 지원하지 않는 벤더 제공 애플리케이션을 다루는 경우도 있습니다. 또, 구형 Tomcat 브랜치에서 레거시 애플리케이션을 실행 중이어서 업그레이드에 상당한 테스트와 검증이 필요한 경우도 있습니다. 때로는 단순히 자원이 부족하여 가장 중요한 인스턴스부터 우선순위를 두고 처리해야 하는 경우도 있습니다.

즉시 업그레이드할 수 없는 구형 Tomcat 버전을 사용 중인 팀을 위해, 이 간극을 메울 수 있는 확장 보안 지원 옵션이 마련되어 있습니다. TuxCare의 Endless Lifecycle Support(ELS)와 같은 서비스는 Apache 프로젝트로부터 더 이상 업데이트를 제공받지 못하는 구형 Tomcat 릴리스를 포함하여, 지원 종료된 소프트웨어 버전에 대해 지속적인 보안 패치를 제공합니다.

이는 적절한 패치 적용이나 최신 버전으로의 업그레이드를 대체할 수 있는 방법은 아닙니다. 다만 단계적 수정 계획의 일환으로 활용할 수 있는 실용적인 위험 완화 방안입니다. 즉시 마이그레이션할 수 없는 Tomcat 8.0 또는 7.0 인스턴스를 운영 중인 경우, 확장 지원 서비스를 통해 현실적인 일정에 맞춰 업그레이드 절차를 진행하는 동안 해당 시스템을 알려진 취약점으로부터 보호할 수 있습니다.

중요한 것은 이를 신중하게 계획하는 것입니다. 연장 지원을 이용하고 있다면, 추후 최신 Tomcat 버전으로 전환할 명확한 계획을 세워두십시오. 연장 지원이 기술적 부채를 무기한 미루는 핑계가 되어서는 안 됩니다.

이 CVE를 넘어: 탄력적인 Tomcat 배포 환경 구축

CVE-2025-24813은 하나의 취약점이지만, 더 큰 흐름의 일부에 불과합니다. Tomcat의 취약점은 꾸준히 발견되어 왔으며, 앞으로도 계속 발견될 것입니다. 중요한 것은 Tomcat에 다시 패치를 적용해야 할지 여부가 아니라, 다음 CVE가 공개되었을 때 이를 얼마나 신속하고 원활하게 처리할 수 있느냐는 점입니다.

즉, 신속한 패치 적용을 뒷받침하는 운영 관행을 구축해야 합니다. 여기에는 모든 Tomcat 배포 환경에 대한 명확한 현황 파악, 검증된 업그레이드 절차 마련, 정기적인 취약점 스캔 수행, 그리고 업데이트 테스트를 위해 프로덕션 환경을 그대로 반영한 스테이징 환경을 유지하는 것이 포함됩니다.

이는 또한 보안을 강화하는 아키텍처적 결정을 내리는 것을 의미합니다. 즉, 리버스 프록시 뒤에 Tomcat 인스턴스를 배치하고, 네트워크 분할을 구현하며, 롤링 업데이트를 용이하게 하는 컨테이너 오케스트레이션을 활용하고, Tomcat 프로세스 권한에 대해 최소 권한 원칙을 준수하는 것을 말합니다.

또한 이는 최신 정보를 꾸준히 파악해야 한다는 뜻입니다. Apache Tomcat 보안 메일링 리스트에 가입하세요. Tomcat 관련 취약점에 대해 CVE 데이터베이스를 주시하십시오. 취약점이 공개된 후에야 대응 방안을 마련하기 시작하지 마십시오.

실천하기

CVE-2025-24813은 심각한 문제이지만, 해결 가능한 문제이기도 합니다. 패치가 이미 제공되고 있으며, 완화 조치도 명확하고, 악용 조건이 충분히 구체적이어서 우선순위를 정할 때 합리적인 판단을 내릴 수 있습니다.

해당 취약점이 발견된 Tomcat 버전을 사용 중이며 보안 제약 조건을 통해 리소스를 보호하고 있다면, 이를 최우선 순위의 패치 작업으로 처리하십시오. 업그레이드를 테스트하고 배포 계획을 수립한 후 해당 인스턴스를 업데이트하십시오. 더 이상 패치를 제공받지 못하는 구형 Tomcat 버전을 사용 중이라면, 연장 지원 옵션을 검토하거나 마이그레이션 계획을 앞당기십시오.

CVE-2025-24813에 대한 최악의 대응은 이를 무시하고 별일 아니기를 바라는 것입니다. 최선의 대응은 취약점 노출 정도를 파악하고, 수정 작업의 우선순위를 정한 뒤, 체계적으로 패치를 적용하는 것입니다.

Tomcat 인스턴스는 애플리케이션 인프라의 일부입니다. 이를 안전하게 유지하는 것은 시간이 날 때나 하는 선택적인 작업이 아닙니다. 이는 시간과 관심, 자원을 투자해야 할 핵심 운영 책임입니다.

요약