Apache CXF 지원 종료(EOL): 버전, 지원 현황 및 향후 조치

주요 내용

• Apache CXF 3.5.x 및 그 이전 버전은 지원 종료되었으며, Apache 측에서 더 이상 보안 패치를 제공하지 않을 예정입니다.
• 현재 4.1.x와 4.2.x만이 최신 릴리스 라인입니다. 3.6.x와 4.0.x는 모두 계획된 최종 릴리스를 완료했습니다.
• EOL CXF는 현재 알려진 패치되지 않은 CVE를 의미하며, 향후 발견되는 문제에 대해서는 아파치 측에서 어떠한 수정도 제공하지 않음을 뜻합니다.
• 선택지는 CXF 4.x로 업그레이드하거나, 아예 교체하거나, 당분간 확장 지원 서비스를 이용해 패치를 계속 적용받는 것입니다.

Spring XML 시절부터 운영되어 온 Java 서비스 스택을 보유하고 있다면, 그 어딘가에 Apache CXF가 포함되어 있을 가능성이 꽤 높습니다. 이 CXF는 SOAP 엔드포인트와 JAX-RS API 한두 개, 그리고 어쩌면 수년 동안 아무도 열어보지 않은 WS-Security 통합 기능을 조용히 처리하고 있을 것입니다. 게다가 현재 사용 중인 버전에 대한 패치 제공이 한참 전에 중단되었을 가능성도 적지 않습니다.

3.5.x 계열 및 그 이전 버전의 모든 CXF 릴리스는 지원 종료(EOL)가 지났으며, 이는 아파치 프로젝트 측에서 더 이상 보안 패치를 제공하지 않는다는 것을 의미합니다.

이 글에서는 더 이상 지원되지 않는 CXF 버전이 무엇인지, 이것이 보안 및 규정 준수 현황에 실제로 어떤 영향을 미치는지, 그리고 4.x로 업그레이드하거나, CXF를 완전히 교체하거나, 연장 지원을 통해 시간을 벌 수 있는 등 여러분이 선택할 수 있는 세 가지 현실적인 대안에 대해 자세히 설명합니다.

Apache CXF의 지원 종료 시점이 도래했나요?

아파치는 CXF에 대한 고정된 지원 종료(EOL) 일정을 공개하지 않습니다. 실제로는 ‘롤링 모델’ 방식으로 운영됩니다. 즉, 아파치가 적극적으로 릴리스하고 있는 브랜치들이 프로젝트의 다운로드 페이지에 게시되며, 새로운 버전이 출시될 때마다 이전 버전들은 목록에서 제외되어 더 이상 수정되지 않습니다. 현재 해당 페이지에는 CXF 4.2.x가 최신 브랜치(JDK 17 기준, Jakarta EE 11)로 표시되어 있으며, 그 바로 다음으로 4.1.x(JDK 17, Jakarta EE 10)가 나열되어 있습니다. 3.6.x 계열은 이미 아파치가 명시적으로 ‘마지막 계획된 릴리스’라고 밝힌 3.6.11을 출시했으며, 4.0.x 계열도 4.0.11을 끝으로 종료되었습니다. 두 계열 모두 향후 수정 사항을 기대할 수 있는 브랜치가 아닙니다.

3.5.x 이하 버전의 모든 지원은 종료되었습니다. Apache는 3.5.x 계열의 마지막 유지보수 릴리스(3.5.11)를 출시한 후 다음 단계로 넘어갔으며, 더 이상 백포트나 CVE 수정 사항 등 어떤 업데이트도 제공되지 않습니다. 만약 여러분의 Maven 또는 Gradle 빌드에서 여전히 org.apache.cxf를 3.5.x 이하 버전으로 고정하고 있다면, 여러분은 EOL 소프트웨어 를 프로덕션 환경에서 실행하고 있는 셈입니다. 누군가가 이를 지적했든 그렇지 않았든 상관없이 말입니다.

유의해야 할 Apache CXF 단종(EOL) 버전 및 지원 현황

아파치는 일부 런타임과 달리 CXF에 대해 공식적인 “활성 LTS” 및 “유지보수 LTS” 종료일을 발표하지 않습니다. 지원 여부는 현재 사용 중인 브랜치에 따라 결정되므로, 아래 표에서는 존재하지 않는 마일스톤을 임의로 설정하는 대신 각 브랜치를 해당 JDK 기준 버전, 네임스페이스 및 아파치 다운로드 페이지상의 현재 상태와 연결하여 정리했습니다.

CXF 지점	JDK 기준 / 네임스페이스	Apache 지원 현황
4.2.x	JDK 17 / Jakarta EE 11 (jakarta.*)	현재, 최신
4.1.x	JDK 17 / Jakarta EE 10 (jakarta.*)	현재
4.0.x	JDK 11 / Jakarta EE 9.1 (jakarta.*)	최종 예정된 릴리스(4.0.11)가 배포되었으며, 이제 아카이브로 이동되었습니다.
3.6.x	JDK 11 / Java EE 8 (javax.*)	최종 예정된 릴리스가 배포되었습니다 (3.6.11)
3.5.x	JDK 8 / Java EE 8 (javax.*)	지원 종료 (최종 릴리스: 3.5.11)
3.4.x 및 그 이전 버전	JDK 8 / javax.*	Lifecycle 종료

주의: javax.*에서 jakarta.*로의 전환은 정확히 3.x와 4.x의 경계에서 이루어집니다. 이는 단순히 설정 플래그를 켜고 끄는 문제가 아닙니다. 바로 이 점이 CXF 3에서 CXF 4로의 업그레이드가 단순한 버전 업데이트가 아닌 본격적인 마이그레이션 프로젝트로 변모하는 가장 큰 이유입니다.

Apache CXF의 지원 종료(EOL)가 귀사의 Java 서비스 스택에 미치는 의미

지원 종료(EOL)된 CXF 버전을 사용하는 것은 어딘가의 스프레드시트에 적힌 추상적인 정책 문제가 아닙니다. 이는 세 가지 구체적인 측면에 변화를 가져옵니다. 바로 계속 미해결 상태로 남아 있는 CVE, 여러분이 전혀 알 기회조차 없는 CVE, 그리고 CXF가 함께 끌고 다니는 라이브러리들입니다.

공개적으로 수정 방법이 문서화된, 패치되지 않은 CVE

CVE는 이미 공개된 상태이며, 브랜치의 버전이 오래될수록 해당되는 취약점이 더 많아집니다.

CVE-2022-46363 CXFServlet이 static-resources-list 및 redirect-query-check 속성이 함께 잘못 구성되어 있을 경우, 원격 디렉터리 열람 또는 코드 유출이 발생할 수 있습니다. NVD는 이 취약점에 7.5점을 부여했으며, 수정 패치는 3.5.5 및 3.4.10 버전에 반영되었습니다. CVE-2024-28752는 Aegis DataBinding(기본 데이터 바인딩 아님)을 사용하는 배포 환경에만 영향을 미치는 SSRF 취약점으로, NVD 점수는 9.3이며 4.0.4, 3.6.3, 3.5.8 이전 버전에 영향을 미칩니다. 이 두 패치 범위를 보면, 시간이 지남에 따라 역포트 범위가 어떻게 좁아지는지 알 수 있습니다. 2022년 수정 사항은 3.4.x와 3.5.x 모두에 적용되었지만, 2024년 수정 사항은 3.5.8에서 멈췄으며 3.4.x에는 전혀 적용되지 않았습니다. 브랜치가 더 오래된 버전일수록, 수정된 버전 목록에서 더 빨리 사라집니다.

그리고 이는 과거에만 국한된 문제가 아닙니다. 아파치(Apache)는 2026년 한 해에만 WS-Transfer 기능의 XXE 취약점, XKMS LDAP 저장소의 LDAP 인젝션 결함, 일련의 OAuth2 결함, 그리고 이전 JMS 관련 원격 코드 실행 문제에 대한 불완전한 수정 사항 등 총 14건의 새로운 CXF 보안 권고 사항을 발표했습니다. 현재 브랜치에는 이러한 수정 사항이 반영되지만, 지원이 종료된 브랜치에는 반영되지 않습니다.

이것이 바로 지원이 중단된 소프트웨어의 함정입니다. 취약점은 이미 문서화되어 있고, 패치는 공개되었으며, 커밋 내역에는 변경 내역이 그대로 기록되어 있습니다. 공격자들은 직접 무언가를 찾아낼 필요가 없습니다. 보안 권고문과 패치를 분석한 뒤, 여전히 취약한 버전을 실행 중인 시스템을 찾아내기만 하면 됩니다. 2026년 버라이즌 DBIR 에 따르면, 취약점 악용이 현재 가장 흔한 초기 접근 경로로, 침해 사고의 31%를 차지하며 전년도의 20%에서 증가했습니다. 이는 보고서가 발간된 지 19년 만에 처음으로 ‘자격 증명 악용’을 제치고 1위를 차지한 것입니다.

아파치가 귀하의 브랜치에 대해서는 절대 패치하지 않을 CVE 목록

더 큰 위험은 아직 눈에 띄지 않는 위험입니다. 브랜치가 EOL(지원 종료) 상태가 되면, 그 이후에 해당 코드에서 발견되는 문제는 아파치 측에서 더 이상 수정해 주지 않습니다.

내년에 CXF의 3.5.x 계열에 영향을 미치는 결함이 발견된다고 가정해 봅시다. 이 결함은 현재의 4.x 브랜치에서는 패치되지만, 그 외의 모든 곳에서는 별다른 조치 없이 그대로 방치됩니다. 여러분은 보안 권고문을 읽고 자신의 버전을 확인한 후, 해당 브랜치에 대한 패치된 릴리스가 아예 없다는 사실을 깨닫게 됩니다. 이 시점에서 긴급 마이그레이션이나 공급업체의 백포트 중 하나를 선택해야 하는데, 어느 쪽도 하룻밤 사이에 해결될 문제는 아닙니다.

이것이 바로 벤더 지원 패치가 메우려고 하는 격차라고 할 수 있습니다. TuxCare의 ‘Endless Lifecycle Support’  는 아파치가 이미 지원을 중단한 CXF 브랜치에 대해서도 지속적으로 보안 패치를 제공하고 있습니다. 이는 사용자가 아직 준비되지 않은 업그레이드를 강요받지 않고도 패치를 계속 받아볼 수 있는 방법입니다.

EOL된 CXF 버전과 그 종속성에 대해 현재 어떤 항목들이 추적되고 있는지 확인하려면, TuxCare CVE 트래커 를 이용하면 NVD를 직접 일일이 뒤지지 않고도 심각도 및 수정 상태에 따라 CXF 취약점을 필터링할 수 있습니다.

함께 따라오는 전이적 종속성

CXF는 단독으로 실행되지 않습니다. 이 라이브러리는 XML 파싱, StAX 스트리밍, XML 보안을 위한 라이브러리들을 불러오며, 이들 각각은 주의해야 할 고유한 CVE 이력을 가지고 있습니다.

CXF가 EOL 버전에서 고정되면, 해당 종속성들도 함께 고정되는 경향이 있습니다. 이 문제는 CXF 자체를 넘어, 고정된 빌드가 최종적으로 채택한 구형 라이브러리 버전들까지 파급됩니다. 우리는 아파치 카멜 과 아파치 스트러츠(Apache Struts) 배포에서도 같은 패턴을 목격한 바 있습니다. 이는 한동안 업데이트되지 않은 프레임워크에서 반복적으로 나타나는 현상입니다.

EOL 상태인 Apache CXF 실행으로 인해 영향을 받는 규정 준수 프레임워크

감사관들은 CXF가 “내부용”이든 “방화벽 뒤에” 있든 별로 신경 쓰지 않습니다. 지원이 중단된 소프트웨어는 대부분의 감사 프레임워크가 전제로 삼는 패치 적용 원칙을 위반하기 때문에, 그 자체로 감사 지적 사항으로 드러나는 경향이 있습니다. 바로 이 점이 EOL(지원 종료) 상태인 CXF가 사람들에게 골칫거리가 되는 이유입니다.

PCI DSS 4.x

PCI DSS 요구사항 6.3.3은 해당되는 중요 또는 고위험 보안 패치를 출시 후 1개월 이내에 설치하고, 그 외의 모든 해당 패치는 문서화된 위험 기반 일정에 따라 설치할 것을 요구합니다. 패치 소스가 없는 EOL(지원 종료) CXF 버전의 경우, 적용할 패치가 남아 있지 않아 두 가지 일정을 모두 준수할 수 없습니다. 카드 소지자 데이터 환경 내 어디에든 취약한 CXF 구성 요소가 존재한다면, 이러한 공백은 요구사항 6.3.3 위반 사항으로 이어질 수 있습니다. 규정 준수 도구는 해당 버전을 표시해 줄 수는 있지만, Apache에서 더 이상 지원하지 않는 버전에 대해서는 패치를 적용할 수 없습니다.

SOC 2

SOC 2의 보안 기준은 귀사가 제대로 작동하는 취약점 관리 프로세스가 있다고 가정합니다. 패치 소스를 구할 수 없는 소프트웨어는 이러한 기준에 부합하기 어렵습니다. 감사관들이 결국 묻게 되는 질문은 패치를 얼마나 빨리 적용하느냐가 아니라, 애초에 패치를 적용할 수 있느냐는 것입니다. 

FIPS 및 연방 정부 업무 부하

검증이 완료된 암호화 기술이 필요한 환경에서 작업하는 경우, EOL(지원 종료) 프레임워크는 전체 프로세스를 복잡하게 만듭니다. CXF의 라이프사이클 상태만으로는 FIPS 인증 모듈의 유효성을 무효화하지는 않지만, 동결된 프레임워크를 사용하면 더 이상 업데이트를 받을 수 없는, 즉 인증 상태가 만료된 암호화 라이브러리 버전에 묶이게 될 수 있습니다.

Apache CXF 지원 종료 후의 대안

여기에는 세 가지 실질적인 선택지가 있으며, 어떤 것이 옳은지는 현재와 향후를 비교했을 때 얼마나 많은 마이그레이션 위험을 감당할 수 있는지에 달려 있습니다. 이 중 ‘아무 조치도 취하지 않는 것’은 없습니다. 여러분의 브랜치가 EOL(지원 종료)된 날부터, 그것은 더 이상 현실적인 선택지가 아니게 되었습니다.

• 이번 분기에는 마이그레이션을 할 수 없지만 패치는 계속 적용해야 하나요? 연장 지원 서비스를 이용하세요.
• JDK 17을 사용하고 있고, 개발 시간을 할애할 여유가 있으신가요? 4.x 버전으로 업그레이드해 보세요.
• CXF를 거의 사용하지 않는다면, 아니면 어차피 플랫폼을 전환할 예정이라면? 교체하세요.

Apache CXF용 ‘Endless Lifecycle Support’를 활용하세요

애플리케이션을 재작성하지 않고도 당면한 위험을 즉시 해소할 수 있는 직접적인 방법은 공급업체가 지원하는 보안 지원입니다. TuxCare의 Endless Lifecycle Support(ELS) 는 3.5.x와 같이 아파치 측에서 완전히 단종한 브랜치를 포함하여, EOL(지원 종료) 상태인 Apache CXF에 대한 패치를 지속적으로 제공하며, 새로운 CVE가 발표될 때마다 수정 사항을 배포합니다. 현재 지원 범위는 특히 CXF 3.5.9 및 3.5.11을 대상으로 하며, 아파치의 최종 3.5.x 릴리스가 끝난 지 오래되었음에도 불구하고 두 버전 모두에 대한 CVE 패치가 여전히 제공되고 있습니다. 수정 프로그램은 TuxCare가 호스팅하고 서명된 리포지토리를 통해 배포되며, 이는 귀사가 이미 사용하고 있는 Maven 또는 Gradle 워크플로우와 통합됩니다.

대부분의 팀이 간과하는 부분은 바로 의존성 트리입니다. CXF에는 XML 파싱, 스키마 처리, 보안을 위한 런타임 라이브러리가 포함되어 있으며, 이러한 라이브러리들도 CXF 자체 코드만큼이나 패치가 필요합니다. TuxCare ELS는 추가 비용 없이 직접적 및 전이적 의존성을 모두 지원하므로, 의존성 트리 깊숙한 곳에 위치한 취약한 라이브러리가 패치되지 않은 채로 남아 있는 동안 프레임워크만 패치해야 하는 상황을 피할 수 있습니다.

이 방법은 마이그레이션 작업이 대규모 엔지니어링 작업에 해당하고 당장 일정을 잡을 수 없는 경우에 가장 적합합니다. 현재 버전을 유지하면 SOAP 및 REST 서비스를 재작성 없이 계속 운영할 수 있으며, 보안 침해의 압박을 받는 상황이 아닌 본인의 일정에 맞춰 업그레이드를 계획하는 동안에도 보안 패치를 지속적으로 적용받을 수 있습니다. 이는 최종 목적지가 아닌 과도기적인 단계입니다. 목표는 여전히 결국 최신 버전으로 업데이트하는 것이지만, 자신이 실제로 통제할 수 있는 조건에서 이를 달성하는 것입니다.

이 솔루션은 특히 두 가지 상황에 매우 적합합니다. 하나는 올해는 javax.*에서 jakarta.*로의 마이그레이션을 감당할 수 없는, 동결된 상태이지만 비즈니스에 필수적인 서비스이고, 다른 하나는 아직 아무도 마이그레이션 범위를 완전히 파악하지 못한 기존 코드베이스입니다. 두 경우 모두 ELS는 EOL(지원 종료)로 인해 잃게 되는 유일한 것, 즉 ‘시간’을 되찾아 줍니다.

Apache CXF 4.x로 업그레이드

장기적으로 볼 때 가장 깔끔한 해결책은 현재의 4.x 브랜치로 전환하는 것입니다. 엔지니어링 자원이 충분하고 런타임을 실제로 이전할 수 있다면, 이것이 올바른 선택입니다.

여기에는 두 가지 문제가 있습니다. 첫째, CXF 4.x는 jakarta.* 네임스페이스에서 실행되므로, 애플리케이션 코드 내의 모든 javax.ws.rs, javax.xml.ws 및 관련 임포트 문구를 해당 네임스페이스로 옮겨야 하며, 기존 javax.* API를 기반으로 구축된 모든 종속성은 jakarta와 호환되는 버전으로 업그레이드하거나 대체해야 합니다. 둘째, JDK 기준 버전이 크게 변경되었습니다. CXF 4.0.x는 JDK 11을 기준으로 하는 반면, 4.1.x와 4.2.x는 JDK 17을 요구합니다. Eclipse Transformer와 같은 도구를 사용하면 네임스페이스 재작성 작업의 상당 부분을 자동으로 처리할 수 있지만, 구성 파일 내의 리플렉션이나 문자열 기반 요소는 수동으로 검토해야 합니다. 이 작업을 오후 한나절 만에 끝낼 수 있는 일이 아니라 하나의 프로젝트로 접근하십시오.

최신 브랜치에 대한 한 가지 주의사항: Apache 측에 따르면, 현재 4.2.x 릴리스는 Undertow의 알파 빌드에 의존하고 있으므로, Undertow와의 통합 기능이 아직 안정적이지 않을 수 있습니다. 만약 사용 중인 스택에 Undertow가 포함되어 있다면, 당분간은 4.1.x 버전을 사용하는 것이 더 안전합니다.

CXF를 대체 프레임워크나 접근 방식으로 교체하기

CXF가 스택의 극히 일부만 담당하고 있다면, 이를 교체하는 것이 4.x 버전으로 완전히 마이그레이션하는 것보다 오히려 수고가 덜 들 수 있습니다. 주로 REST 엔드포인트를 운영하는 팀들은 때때로 Spring Boot 기반의 Spring MVC나 WebFlux로 전환하거나, Jersey나 RESTEasy와 같은 JAX-RS 구현체로 이동하기도 합니다. 솔직히 말해, SOAP과 WS-Security를 많이 사용하는 팀들에게는 그렇게 깔끔한 전환 경로가 많지 않습니다. 애초에 CXF가 바로 그러한 워크로드를 위해 설계되었기 때문이며, 이것이 바로 해당 팀들이 원치 않음에도 불구하고 CXF를 더 오랫동안 사용하게 되는 이유입니다.

이 작업을 진행하기로 결정하기 전에, 해당 작업의 난이도에 대해 스스로 솔직하게 평가해 보십시오. 프레임워크를 교체한다는 것은 서비스 경계를 재정의하는 것이며, 이에 수반되는 모든 테스트 작업도 수행해야 합니다. 만약 광범위한 WSDL 계약, WS-Security 정책, 또는 MTOM 첨부 파일이 포함되어 있다면, “그냥 프레임워크만 바꾸면 된다”는 식의 생각은 실제 필요한 작업량을 훨씬 과소평가하는 경우가 많습니다.

TuxCare를 통해 EOL 이후에도 Apache CXF의 보안을 유지하세요

지원 종료(EOL)된 Apache CXF를 계속 사용하는 것은 서서히 커지는 위험입니다. 공식 CVE가 공개되거나 감사를 통해 하룻밤 사이에 긴급 상황이 발생하기 전까지는 아무 문제 없이 잘 작동합니다. 지금 당장 업무에 지장을 주는 마이그레이션을 진행할지, 아니면 노출된 위험을 묵인한 채 가만히 있을지 선택할 필요는 없습니다.

확장 지원 서비스를 이용하면 본인의 일정에 맞춰 업그레이드를 계획하는 동안 현재 버전에 대한 패치 적용을 계속 받을 수 있으며, 4.x 버전으로의 마이그레이션이나 프레임워크 교체를 통해 준비가 되는 대로 이 특정 EOL 문제를 해결할 수 있습니다. 유일하게 항상 좋지 않은 결과로 이어지는 방법은 방치하는 것입니다. 먼저 각 옵션의 비용을 산정해 보는 것부터 시작하세요부터 시작하거나, TuxCare가 오픈 소스 소프트웨어용 ELS에서 TuxCare가 레거시 오픈소스 스택을 어떻게 광범위하게 안전하게 관리하는지 살펴보십시오.

자주 묻는 질문