CVE-2026-24734, 아파치 톰캣 OCSP 해지 우회

CVE-2026-24734는 극적인 헤드라인을 장식하는 톰캣 결함이 아닙니다. 인증되지 않은 공격자에게 원격 코드 실행 권한을 넘겨주지 않습니다. 이 취약점은 잘못된 HTTP 요청을 메모리 손상으로 전환하지 않습니다. 대신 클라이언트 인증서에 의존하는 서버가 여전히 자체 해지 검사를 신뢰할 수 있는지 여부라는 보다 조용하고 기본적인 보안을 보장합니다. Apache의 권고에 따르면 Tomcat Native와 Tomcat의 OpenSSL FFM 경로가 OCSP 응답자를 사용할 때 OCSP 응답에 대한 확인 또는 최신성 확인을 완료하지 않았다고 합니다. 그 결과 올바른 환경에서는 인증서 해지를 우회할 수 있는 간단하고 위험한 결과를 초래합니다. Apache는 이 문제를 보통으로 표시한 반면, NVD 및 GitHub의 자문 데이터베이스는 CVSS 3.x 심각도를 높게 지정했습니다. (Google 그룹)

이러한 구분이 중요한 이유는 실제 위험을 잘못 인식하기 쉽기 때문입니다. 이는 일반적인 "모든 Tomcat HTTPS가 깨졌다"는 문제가 아닙니다. Tomcat의 자체 OCSP 문서는 OCSP 검사를 클라이언트 인증서 및 OpenSSL 지원 커넥터 구성의 하위 집합에 연결합니다. 문서화된 모델에서 Tomcat은 기관 정보 액세스 확장에 있는 OCSP 응답자 URI로 클라이언트 제공 인증서의 유효성을 검사하며, 이 기능은 같은 문서의 다른 곳에서 설명하는 일반 JSSE 구현이 아닌 OpenSSL JSSE 경로, OpenSSL FFM 경로 및 APR/네이티브 커넥터에 대해 구현되어 있습니다. 실제로 가장 위험도가 높은 배포는 B2B API, 내부 관리자 플레인, 파트너 통합, 디바이스 ID 또는 권한 있는 서비스 간 인증에 대한 액세스 제어 경계로 mTLS를 사용하는 배포입니다. (아파치 톰캣)

Apache의 자체 공개 추적도 주목할 가치가 있습니다. 이 문제는 2025년 11월 2일에 Tomcat 보안 팀에 보고되었습니다. 2026년 1월에 Tomcat Native 및 Tomcat 9, 10.1, 11.0에 대한 수정 릴리스가 제공되었고, 2026년 2월 17일에 공개 권고가 이어졌습니다. 이 시기는 조정된 공개를 위한 정상적인 시기입니다. 더 중요한 공학적 시사점은 이 코드 영역의 OCSP 처리가 초기 수정 이후에도 계속 발전하고 있다는 것입니다. 2026년 3월, Apache는 클라이언트 인증서 인증이 소프트 장애를 비활성화한 경우에도 때때로 소프트 장애가 발생하는 또 다른 OCSP 관련 문제인 CVE-2026-29145를 공개했습니다. 여기서 얻은 교훈은 단순히 "최소 패치 버전만 적용하고 넘어가라"는 것이 아닙니다. 해지 적용 경로는 박스 체크가 아닌 재테스트가 필요하다는 것입니다. (아파치 톰캣)

CVE-2026-24734 한눈에 보기

Apache와 NVD는 다음과 같이 영향을 받는 범위를 식별합니다. Tomcat Native의 경우, 버전 1.3.0부터 1.3.4, 2.0.0부터 2.0.11이 영향을 받으며 1.3.5 및 2.0.12에서 수정됩니다. Apache Tomcat의 경우 11.0.0-M1~11.0.17, 10.1.0-M7~10.1.51, 9.0.83~9.0.114가 영향을 받으며 11.0.18, 10.1.52, 9.0.115에서 수정이 이루어집니다. NVD는 또한 수명이 다한 이전 Tomcat Native 범위, 특히 1.1.23~1.1.34 및 1.2.0~1.2.39도 영향을 받는 것으로 알려져 있다고 언급합니다. GitHub의 자문 데이터베이스는 이 문제를 다음과 같은 임베디드 Java 패키지 범위에 추가로 매핑합니다. org.apache.tomcat.embed:tomcat-embed-core 그리고 org.apache.tomcat:tomcat-coyote이는 모든 취약한 배포가 VM의 독립 실행형 Tomcat 서버처럼 보이는 것은 아니라는 점을 상기시켜주는 유용한 정보입니다. (nvd.nist.gov)

구성 요소	영향을 받는 버전	고정 버전	운영 참고 사항
Tomcat Native 1.3.x	1.3.0 ~ 1.3.4	1.3.5 이상	APR/네이티브 커넥터의 OCSP 경로
Tomcat Native 2.0.x	2.0.0 ~ 2.0.11	2.0.12 이상	OpenSSL 지원 기본 경로
Tomcat 11	11.0.0-M1 ~ 11.0.17	11.0.18 이상	영향을 받는 FFM OpenSSL 경로
Tomcat 10.1	10.1.0-M7 ~ 10.1.51	10.1.52 이상	영향을 받는 FFM OpenSSL 경로
Tomcat 9	9.0.83 ~ 9.0.114	9.0.115 이상	영향을 받는 FFM OpenSSL 경로
EOL 네이티브 라인	1.1.23~1.1.34, 1.2.0~1.2.39	향후 지원되지 않음	마이그레이션은 죽은 나뭇가지에 매달리는 것보다 안전합니다.

심각도 이야기는 실제로 유익한 방식으로 약간 지저분합니다. Apache의 권고에서는 이 문제를 보통으로 분류합니다. NVD는 NVD 강화의 7.5 높음 벡터와 CISA-ADP의 7.4 높음 벡터를 별도로 나열합니다. Snyk는 밀접하게 관련된 패키지 레코드를 CWE-863 스타일의 문구로 분류하여 잘못된 권한 부여로 영향을 설명하는 반면, Apache와 NVD는 불완전한 유효성 검사 및 OCSP 응답 처리를 중심으로 취약점을 설명합니다. 이러한 차이는 모순이라기보다는 관점의 변화입니다. 코드 수준에서 이 버그는 불완전한 응답 유효성 검사에 관한 것입니다. 시스템 수준에서는 해지된 자격 증명이 여전히 수락되어 여전히 액세스를 승인할 수 있다는 점이 영향을 미칩니다. (Google 그룹)

아파치 톰캣 OCSP 해지 우회 설명

CVE-2026-24734가 중요한 이유를 이해하려면 OCSP가 활성화되었을 때 Tomcat이 수행하는 작업을 정확히 파악하는 것이 도움이 됩니다. Tomcat의 SSL/TLS 설명서에 따르면 클라이언트 제공 인증서의 상태를 확인하기 위해 OCSP 지원이 존재한다고 나와 있습니다. 이 기능에 대해 지원되는 커넥터 제품군이 나열되어 있습니다: NIO 또는 NIO2와 org.apache.tomcat.util.net.openssl.OpenSSLImplementationNIO 또는 NIO2와 함께 org.apache.tomcat.util.net.openssl.panama.OpenSSLImplementation및 OCSP가 활성화된 Tomcat Native 빌드가 있는 APR/네이티브 HTTP 커넥터를 사용합니다. 동일한 문서에 따르면 일반 JSSE 구현을 사용하거나 JSSE 구성 스타일을 사용하는 경우 OCSP가 지원되지 않습니다. 이 범위 정의는 매우 중요합니다. 이는 취약점이 특정 신뢰 경로, 즉 OpenSSL 지원 Tomcat 구성에서 클라이언트 인증서의 서버 측 유효성 검사에 있다는 것을 의미합니다. (아파치 톰캣)

일반적인 mTLS 배포에서 클라이언트는 TLS 핸드셰이크 중에 인증서를 제시합니다. 서버는 인증서가 신뢰할 수 있는 발급자에 대한 체인인지 여부만 알면 됩니다. 또한 해당 인증서가 발급된 이후 해지되었는지 여부도 알아야 합니다. OCSP는 거의 실시간으로 이 질문에 답하는 표준 방법 중 하나입니다. 디바이스가 폐기되어 디바이스 인증서가 해지된 경우, 관계가 종료되어 파트너 인증서가 해지된 경우 또는 클라이언트 개인 키가 손상된 것으로 의심되는 경우, 신뢰하는 서비스는 해당 클라이언트 인증서를 거부해야 합니다. 해지 확인을 우회할 수 있으면 해당 인증서를 기반으로 구축된 액세스 제어 모델을 신뢰할 수 없게 됩니다. (아파치 톰캣)

그렇기 때문에 특정 환경에서는 다른 환경보다 더 큰 영향을 받습니다. 일반 TLS에 Tomcat을 사용하지만 클라이언트 인증서가 필요하지 않은 공개 웹사이트는 정식 피해자가 아닙니다. 승인된 클라이언트 인증서의 소유자만 허용하는 파트너 API가 그렇습니다. mTLS를 통해 머신 ID를 적용하는 내부 운영 영역, 인증서를 통한 산업 시스템 온보딩 장치 또는 인증서 소유가 조직 회원 자격의 기본 증명으로 취급되는 게이트웨이도 마찬가지입니다. 이러한 모든 설계에서 해지는 외형적인 기능이 아닙니다. 더 이상 신뢰해서는 안 되는 ID에 대한 킬 스위치입니다. 이 스위치를 우회할 수 있게 되면 사고 봉쇄, 오프보딩, 키 침해 대응이 모두 저하됩니다. (아파치 톰캣)

피해야 할 쉬운 개념적 실수도 있습니다. "인증서"라는 단어 때문에 많은 독자가 서버 인증서를 검증하는 브라우저에 대해 생각하게 됩니다. 하지만 여기서는 그런 것이 중심이 아닙니다. Tomcat의 OCSP 기능 설명서는 이 메커니즘이 클라이언트가 제공한 인증서의 유효성을 검사한다고 명시하고 있습니다. 즉, 이 취약점은 브라우저가 어떤 서버 인증서를 수락하는지에 관한 것이 아니라 누가 접속하는지에 관한 것입니다. 다시 말해, CVE-2026-24734는 mTLS 사용 서버 배포에서 인증 및 권한 부여 경계 실패이지 임의의 방문자에 대한 일반적인 HTTPS 기밀성 위반이 아닙니다. (아파치 톰캣)

OCSP 유효성 검사가 잘못되기 쉬운 이유

OCSP를 상태 레이블로 줄이면 간단해 보입니다. 인증서가 정상인지, 해지되었는지 또는 알 수 없는지 물어보세요. 답변을 읽습니다. 계속 진행하세요. 이 멘탈 모델은 위험할 정도로 불완전합니다. RFC 6960은 전체 CRL을 요구하지 않고 디지털 인증서의 현재 상태를 확인하기 위한 프로토콜로 OCSP를 정의합니다. 동일한 RFC는 다음과 같은 의미를 설명합니다. 이 업데이트, 다음업데이트, producedAt및 취소 시간. 또한 논스 확장은 리플레이 공격을 방지하기 위해 요청과 응답을 암호화하여 바인딩한다고 명시되어 있습니다. 이러한 세부 사항은 선택 사항이 아닙니다. 이러한 세부 사항은 단순히 형식만 잘 갖춘 것이 아니라 OCSP 응답을 신뢰할 수 있게 만드는 요소의 일부입니다. (datatracker.ietf.org)

RFC 6960은 다음과 같이 말합니다. 이 업데이트 는 응답자가 표시된 상태가 정확하다고 알고 있는 가장 최근의 시간입니다. 다음업데이트 는 최신 정보를 사용할 수 있는 시간 또는 그 이전입니다. 미묘하지만 중요한 규칙이 추가됩니다. 다음업데이트 가 현지 시간보다 빠른 응답은 신뢰할 수 없는 것으로 간주해야 하며, 응답이 이 업데이트 가 현지 시간보다 늦으면 신뢰할 수 없는 것으로 간주해야 합니다. RFC는 또한 다음과 같은 경우 다음업데이트 가 설정되어 있지 않으면 응답자는 사실상 최신 해지 정보를 항상 사용할 수 있다고 말하는 것입니다. 즉, 구현에서 "상태 필드에서 양호하다고 했으니 이제 끝났습니다."라고 OCSP 처리를 안전하게 줄일 수 없다는 뜻입니다. 시간 의미론은 신뢰 결정의 일부입니다. (datatracker.ietf.org)

OpenSSL의 자체 문서에서도 프로토콜 용어가 아닌 라이브러리 용어로 동일한 점을 지적하고 있습니다. 프로토콜이 아닌 OCSP_check_validity() 문서에 따르면 함수 검사 이업데이트 그리고 다음 업데이트를 사용하여 시계 왜곡에 대한 구성 가능한 여유를 허용하고 응답의 최대 기간을 제한할 수 있습니다. 또한 OpenSSL 설명서에서는 애플리케이션이 일반적으로 인증서 상태를 검색한 다음 유효성을 확인한다고 설명하며 다음과 같은 경우 명시적으로 경고합니다. 다음업데이트 가 없는 경우, 최대 연령 제한이 적용되지 않는 한 오래된 응답이 유효한 것으로 보일 수 있습니다. OpenSSL은 또한 OCSP_basic_verify() 를 기본 응답이 올바르게 서명되었는지, 서명자 인증서가 유효성을 검사할 수 있는지 확인하는 메커니즘으로 사용합니다. 다시 말하지만, 패턴은 분명합니다. 신뢰할 수 있는 OCSP 응답에는 최소한 상태 조회, 서명 확인, 서명자 유효성 검사 및 새로 고침 로직이 필요합니다. (docs.openssl.org)

논스는 다른 이유로 중요합니다. RFC 6960에 따르면 논스는 리플레이를 방지하기 위해 요청과 응답을 바인딩합니다. 이러한 바인딩이 없으면 기술적으로 파싱이 가능한 응답이 현재 트랜잭션에 대한 잘못된 응답일 수 있습니다. 해지 상태가 빠르게 변경되거나 공격자가 이전에 관찰된 자료를 재생할 수 있는 환경에서는 이론적으로 문제가 되지 않습니다. 요청-응답 바인딩이 없는 최신성은 많은 팀이 생각하는 것보다 약합니다. 최신성이 없는 서명 검증 역시 팀이 생각하는 것보다 약합니다. 세 가지 속성이 모두 일치해야 합니다. (datatracker.ietf.org)

이러한 폭넓은 관점은 CVE-2026-24734가 "단순한 OCSP 에지 케이스"가 아닌 이유를 설명합니다. 이는 ID 시스템에서 반복되는 구현 함정의 구체적인 예입니다. 엔지니어는 종종 체인 유효성 검사 및 기본 인증서 구문 분석에 주의를 기울이고 해지를 보완 단계로 취급합니다. 실제로 해지는 ID 결정 자체의 일부입니다. 올바르게 체인에 연결되었지만 해지된 인증서는 덜 성공한 것이 아닙니다. 실패입니다. 이러한 인증서를 허용하는 모든 구현 차이는 인증서를 감싸고 있는 전체 mTLS 정책의 의미를 약화시킵니다. (아파치 톰캣)

패치에서 아파치가 변경한 사항

CVE-2026-24734를 이해하는 가장 빠른 방법은 수정 사항을 살펴보는 것입니다. Apache의 Tomcat 커밋 e76e9ea 의 제목은 "JSSE와 일치하도록 OpenSSL에 대한 OCSP 검사 확장"입니다. 이 커밋은 짧은 권고 텍스트보다 더 명확하게 드러나는데, OpenSSL FFM 경로에서 어떤 검사가 누락되었고 어떤 검사가 추가되었는지 정확히 보여주기 때문입니다. 변경 사항은 외관상의 변화가 아닙니다. 요청-응답 논스 유효성 검사, 응답 서명 및 서명자 확인, 명시적 유효성 검사 등을 삽입합니다. 이 업데이트 그리고 다음업데이트구성 가능한 OCSP 시간 초과 처리 및 구성 가능한 OpenSSL 확인 플래그를 지원합니다. (GitHub)

가장 중요한 추가 사항 중 하나는 OCSP_check_nonce(ocspRequest, basicResponse). 이 패치는 논스 불일치를 잘못된 OCSP 응답으로 처리하고 확인 컨텍스트에 설정된 오류와 함께 알 수 없는 상태를 반환합니다. 이는 RFC 6960에서 논스를 요청과 응답 사이의 리플레이 방지 바인딩으로 정의하기 때문에 중요합니다. 이전에 구현이 해당 바인딩을 확인하지 않고 응답을 수락했다면 응답이 실제로 요청에 속하는 것인지 완전히 확인하지 않은 것입니다. (GitHub)

이 패치에는 다음과 같은 기능도 추가되었습니다. OCSP_basic_verify(basicResponse, certStack, X509_STORE_CTX_get0_store(x509ctx), state.ocspVerifyFlags). OpenSSL 문서 OCSP_basic_verify() 를 사용하여 응답이 올바르게 서명되었는지, 서명자 인증서가 신뢰할 수 있는 저장소와 제공된 중개자를 사용하여 유효성을 검사하는 것으로 간주합니다. 이는 단순히 상태 필드를 추출하는 것에 비해 보증 기능이 크게 업그레이드된 것입니다. A 좋은 상태는 신뢰할 수 없거나 잘못 유효성이 검사된 응답자의 해지된 클라이언트 인증서를 TLS 핸드셰이크를 통해 허용할 수 있는 근거가 아닙니다. 패치의 오류 처리는 기본 확인 실패를 다음과 같이 매핑하여 해당 로직을 반영합니다. X509_V_ERR_OCSP_서명_실패. (GitHub)

마찬가지로 중요한 것은 최신성 검사입니다. 차이점에 반영된 이전 코드 경로는 이전에는 단일 응답을 얻은 다음 현재 패치에서 볼 수 있는 전체 시간 유효성 검사 흐름 없이 상태를 반환했습니다. 고정 코드 추출 이 업데이트 그리고 다음업데이트을 누른 다음 OCSP_check_validity() 아직 유효하지 않은 응답을 감지하기 위해 한 번, 만료된 응답을 감지하기 위해 한 번, 다음과 같이 명시적으로 매핑하여 두 번 사용합니다. X509_V_ERR_OCSP_NOT_YET_VALID 그리고 X509_V_ERR_OCSP_HAS_EXPIRED. OpenSSL의 문서에 따르면 OCSP_check_validity() 는 이러한 타임스탬프를 평가하고 응답 연령을 제한하는 기능을 담당합니다. 즉, 패치는 단순히 위생만 개선하는 것이 아닙니다. 이 패치는 OCSP 응답을 여전히 신뢰할 수 있는지 여부를 결정하는 신뢰 시맨틱을 복구합니다. (GitHub)

구성 측면의 추가 사항도 의미가 있습니다. 이 커밋은 다음에 대한 지원을 도입합니다. OCSP_TIMEOUT 그리고 OSCP_VERIFY_FLAGS 을 OpenSSL FFM 코드 경로에 추가하고, Tomcat의 구성 참조에서 이제 다음을 문서화합니다. ocspVerify 에 확인 플래그를 전달하는 속성으로 OCSP_기본_확인 를 사용하여 OpenSSL 기반 TLS를 구현할 수 있습니다. 또한 다음을 문서화합니다. ocspSoftFail기본값은 false즉, 소프트 실패를 명시적으로 사용하도록 설정하지 않는 한 OCSP 검사 실패는 TLS 핸드셰이크에 실패해야 합니다. 이러한 노브는 진공 상태에서 존재하지 않습니다. 이는 아파치가 이 수정 사항을 한 줄의 버그 수리가 아니라 OCSP 처리를 명시적이고 구성 가능하며 의도한 보안 모델에 더 잘 부합하도록 하기 위한 광범위한 노력의 일환으로 처리했음을 보여줍니다. (GitHub)

톰캣 네이티브 측에서도 비슷한 이야기를 들려줍니다. 2026년 1월에 릴리스 노트에 따르면 Native 2.0.12 및 1.3.5가 릴리스되어 OCSP 응답에 대한 검증을 확대하고 OCSP 동작을 구성하는 옵션이 추가되었습니다. 그 후 2026년 2월과 3월에는 소프트 장애가 APR/네이티브 커넥터에서 올바르게 작동하도록 OCSP 처리의 추가 오류를 제거하는 변경을 포함하여 추가적인 네이티브 강화 작업이 계속되었습니다. 이 이후 작업은 CVE-2026-29145가 되었습니다. 이 순서가 중요한 이유는 코드 영역이 단순히 한 번 패치되고 끝나는 것이 아니라 더 엄격하고 일관된 OCSP 모델을 향해 적극적으로 수정되고 있었음을 보여주기 때문입니다. (아파치 톰캣)

CVE-2026-24734가 실제 공격 경로가 되는 경우

익스플로잇에 대해 가장 깔끔하게 생각하는 방법은 "톰캣에서 익스플로잇 문자열을 실행할 수 있을까?"가 아니라 "죽었어야 하는 클라이언트 ID를 제시해도 여전히 허용될 수 있을까?"입니다. 이 CVE가 중요한 환경에서 공격자의 자산은 한때는 유효했지만 더 이상 신뢰할 수 없는 클라이언트 인증서와 해당 개인 키인 경우가 많습니다. 직원이 퇴사했거나, 계약업체가 액세스 권한을 잃었거나, 디바이스가 폐기되었거나, 파트너 관계가 종료되었거나, 기타 사고로 인해 키가 노출되었기 때문에 이러한 일이 발생할 수 있습니다. 건강한 시스템에서는 해지 시 해당 문이 닫힙니다. 취약한 시스템에서는 서버가 여전히 문을 열어둘 수 있습니다. (Google 그룹)

현실적인 예로는 상호 TLS로 보호되는 파트너 API를 들 수 있습니다. 파트너의 인증서는 침해 또는 계약 종료 후 해지됩니다. 파트너 또는 현재 이전 개인 키를 보유하고 있는 사람은 즉시 액세스 권한을 잃어야 합니다. 신원 결정을 시행하는 Tomcat 에지가 영향을 받는 범위에 있고 취약한 OCSP 경로에 의존하는 경우, 인증서 해지 결정이 실패할 수 있습니다. 액세스는 더 이상 인증 기관의 최신 신뢰 상태가 아니라 서버의 불완전한 OCSP 응답 해석에 의해 제어됩니다. 그렇기 때문에 일부 에코시스템에서는 이 문제를 단순한 입력 유효성 검사 용어가 아닌 권한 부여 용어로 설명합니다. 결함은 유효성 검사 로직에 존재하지만, 운영 결과는 실패해야 하지만 실패하지 않는 신뢰 결정입니다. (nvd.nist.gov)

동일한 패턴이 내부 서비스 메시 및 mTLS를 전송 기능으로 사용하기보다는 멤버십 테스트에 더 많이 사용하는 머신 투 머신 플랫폼에도 적용됩니다. 많은 팀은 인증서가 비공개 PKI 아티팩트이고 엔드포인트가 내부에 있기 때문에 위협이 더 작을 것이라고 가정합니다. 그 반대가 사실일 수도 있습니다. 내부 mTLS는 종종 관리 기능, 오케스트레이션 시스템, 민감한 데이터 경로 또는 측면 이동 초크포인트에 대한 게이트 역할을 합니다. 해지된 클라이언트 자격 증명이 여전히 인증되는 경우, 부분적인 발판, 오래된 디바이스 자료 또는 유출된 키를 가진 공격자가 찾고자 하는 바로 그 틈새를 노리는 것입니다. 네트워크 위치가 "내부"라고 해서 시스템이 잘못된 신뢰 의미론으로부터 보호되는 것은 아닙니다. (아파치 톰캣)

이 CVE가 설명하지 않는 것은 클라이언트 인증서 OCSP 검사를 사용하지 않는 일반 공개 Tomcat 사이트의 익명의 원격 침해입니다. 그렇기 때문에 "네트워크를 통해 취약한 Tomcat 서버"와 같은 포괄적인 헤드라인은 여기서 도움이 되지 않습니다. CVSS의 네트워크 공격 벡터는 사전 권한 없이 네트워크 인증 경로를 통해 결함을 행사할 수 있다는 것을 반영하는 것이지, 모든 일반 인터넷 기반 Tomcat 배포가 동일하게 노출된다는 것을 의미하지는 않습니다. 이 차이는 여러 배포에 걸쳐 패치 긴급성을 분류할 때 중요합니다. 팀은 인증서 해지가 실시간 액세스 제어 경계로 작동해야 하는 시스템의 우선순위를 정해야 합니다. (nvd.nist.gov)

영향을 받을 가능성이 있는 사람과 그렇지 않은 사람

CVE-2026-24734에 과잉 대응하는 가장 빠른 방법은 모든 Tomcat 인스턴스를 동일하게 취약한 것으로 취급하는 것입니다. 과소 대응하는 가장 빠른 방법은 "Tomcat Native"를 별도의 제품으로 명시적으로 설치하지 않았으므로 안전하다고 가정하는 것입니다. 실제 노출은 버전, 커넥터 구현, 인증서-인증 모델 및 OCSP 사용의 조합에 따라 달라지기 때문에 두 가지 지름길 모두 실패합니다. (nvd.nist.gov)

네 가지 조건이 일치하는 배포는 가장 위험도가 높은 버킷에 속합니다. 첫째, 취약한 Tomcat 또는 Tomcat Native 버전 범위를 사용합니다. 둘째, APR/네이티브, OpenSSL JSSE 또는 OpenSSL 파나마 FFM 구현과 같이 Tomcat의 OCSP 기능 지원과 일치하는 OpenSSL 지원 커넥터 경로를 사용합니다. 셋째, 실제로 OCSP에 의존하는 방식으로 클라이언트 인증서 유효성 검사를 수행합니다. 넷째, 클라이언트 인증서는 OCSP 응답자 URI를 가지고 있는데, Tomcat의 문서에 따르면 기관 정보 액세스 확장에 포함된 응답자 URI를 사용하여 클라이언트 인증서의 유효성을 검사한다고 되어 있기 때문입니다. 이러한 요소 중 하나라도 누락되면 실질적인 위험은 급격히 감소합니다. (아파치 톰캣)

이러한 OpenSSL 지원 OCSP 검사가 없는 일반 JSSE 배포는 아파치가 이 CVE에 대해 설명한 취약한 경로와 일치하지 않는 것으로 보입니다. 이러한 결론은 Tomcat의 자체 기능 범위에 근거한 것입니다. OCSP 지원 문서에는 커넥터 유형이 나열되어 있으며 OCSP는 다음과 같이 명시적으로 지원되지 않는다고 명시되어 있습니다. org.apache.tomcat.util.net.jsse.JSSEImplementation 또는 JSSE 구성 스타일. 모든 JSSE 배포가 모든 인증서 유효성 검사 버그에 영원히 영향을 받지 않는다고 말하는 것과는 다릅니다. 이것은 단지 CVE-2026-24734에 대해 설명한 취약한 경로를 가장 주의 깊게 읽는 것입니다. (아파치 톰캣)

임베디드 Java 애플리케이션은 특별한 주의가 필요합니다. 많은 팀이 서버 패키지를 생각하지만 실제 운영 환경에서는 Tomcat이 임베디드된 Spring Boot 애플리케이션을 사용합니다. GitHub의 자문 데이터베이스는 다음에서 취약한 범위를 추적합니다. 톰캣-임베드-코어 그리고 톰캣-코요테 패키지, 즉 소프트웨어 구성 분석, 빌드 매니페스트 및 종속성 트리가 노출 검토에 포함된다는 의미입니다. 한 팀에서 /opt/tomcat 설치하지 않고도 애플리케이션 아티팩트에 취약한 코드 경로를 가지고 있을 수 있습니다. (GitHub)

따라서 가장 빠른 실질적인 분류 질문은 "Tomcat을 실행할 것인가?"가 아니라 "영향을 받는 버전 범위 중 하나에서 OpenSSL 지원 커넥터를 통해 OCSP 지원 인증서 해지를 사용하여 Tomcat에서 mTLS 클라이언트 인증을 종료하는 위치는 어디인가?"입니다. 이 질문은 더 좁고, 더 실행 가능하며, 실제 폭발 반경에 더 가깝습니다. (아파치 톰캣)

사용 환경의 노출을 확인하는 방법

버전 인벤토리에서 시작하세요. 독립 실행형 Tomcat 설치의 경우 먼저 런타임 트레인과 패치 레벨을 확인합니다. 임베디드 애플리케이션의 경우 종속성 매니페스트와 잠금 파일을 검사합니다. 컨테이너화된 워크로드의 경우, 이미지 콘텐츠와 애플리케이션의 번들 라이브러리를 검사하세요. 요점은 단순히 "어딘가에 톰캣이 있다"는 것을 찾는 것이 아닙니다. 각 워크로드를 Apache와 NVD가 실제로 영향을 받는다고 표시한 버전 범위에 매핑하는 것입니다. (nvd.nist.gov)

기존 설치의 간단한 첫 번째 패스는 다음과 같습니다:

# 독립 실행형 Tomcat 버전
$CATALINA_HOME/bin/catalina.sh 버전

# 네이티브 라이브러리 존재 여부 찾기
find "$CATALINA_HOME" "$CATALINA_BASE" -iname '*tcnative*' -o -iname 'libtcnative*' 2>/dev/null

# 컨테이너 이미지 또는 패키지 인벤토리
rpm -qa | grep -Ei 'tomcat|tcnative'
dpkg -l | grep -Ei 'tomcat|tcnative'

임베디드 Java 애플리케이션의 경우, 자문 데이터베이스가 서버 릴리스뿐만 아니라 패키지 좌표에 CVE를 매핑하기 때문에 종속성 검사도 마찬가지로 중요합니다. (GitHub)

# Maven
mvn -q dependency:tree | grep -E 'org\.apache\.tomcat|tomcat-embed-core|tomcat-coyote'

# Gradle
./gradlew 의존성 | grep -E 'org\.apache\.tomcat|tomcat-embed-core|tomcat-coyote'

다음으로 애플리케이션이 OCSP용 커넥터 제품군 Tomcat 문서를 사용하고 있는지 확인합니다. Tomcat의 SSL/TLS 가이드에는 관련 커넥터 유형과 구성 스타일이 나와 있습니다. APR/네이티브의 징후를 찾고 있습니다, OpenSSL 구현또는 파나마 OpenSSL 구현과 인증서 확인 설정 및 OCSP 관련 구성이 필요합니다. 빠른 구성 스윕으로 몇 분 안에 해결되는 경우가 많습니다.아파치 톰캣)

grep -RInE 'Http11AprProtocol|OpenSSLImplementation|openssl\.panama|ocspEnabled|ocspSoftFail|ocspVerify|certificateVerification|sslImplementationName' \.
  "$CATALINA_BASE/conf" "$CATALINA_HOME/conf" 2>/dev/null

Tomcat의 자체 OCSP 커넥터 예제는 관련 구성이 어떻게 생겼는지에 대한 좋은 기준이 됩니다. 이 문서에는 다음과 같은 APR/네이티브 커넥터가 나와 있습니다. 인증서 확인="필요" 아래에 구성된 인증서와 SSLHostConfig로 설정한 다음, OCSP 응답자 프로세스가 OpenSSL로 시작됩니다. ocsp 도구를 사용해 보세요. 서버에 해당 모델과 유사한 것이 없다면 CVE-2026-24734가 긴급한 문제일 확률은 낮습니다. 만약 그렇다면 계속 파헤쳐야 합니다. (아파치 톰캣)

문서화된 패턴에 가까운 예제는 다음과 같습니다:

구성 후, 사용 중인 클라이언트 인증서가 실제로 기관 정보 액세스 확장에 OCSP 응답자 URI를 가지고 있는지 확인합니다. Tomcat의 OCSP 가이드에 따르면 인증서에 해당 응답자 위치가 인코딩되어 있어야 한다고 합니다. 그렇지 않으면 의도한 OCSP 유효성 검사 경로가 활성화되지 않을 수도 있습니다. (아파치 톰캣)

openssl x509 -in client.crt -noout -text | sed -n '/권한 정보 액세스/,+5p'

마지막으로, 애플리케이션이 보안 경계로 클라이언트 인증서 인증에 실제로 의존하는지 확인하세요. 많은 제품군에서 TLS는 모든 곳에서 사용하지만 mTLS는 커넥터, 경로 또는 서비스의 일부에서만 사용하도록 설정되어 있습니다. CVE-2026-24734의 비즈니스 영향은 인증서 수락이 의미 있는 작업을 수행할 수 있는 권한과 동일시되는 곳에서 발생합니다. 관리 플레인, 파트너 엔드포인트, 디바이스 온보딩 서비스, 내부 API 및 머신 ID를 인벤토리화하여 해당 문구가 사실인지 확인하세요. 이러한 범위 설정은 일반적으로 원시 호스트 수보다 더 중요합니다. (아파치 톰캣)

CVE-2026-24734에 대한 안전한 실험실 검증

이 문제를 검증하는 올바른 방법은 프로덕션 환경에 임의로 적용하는 것이 아닙니다. 제어하는 실험실에서 신뢰 결정을 재현한 다음 패치 적용 전과 후의 동작을 비교하는 것입니다. Tomcat의 설명서는 이미 대부분의 빌딩 블록을 제공합니다: OCSP 지원 인증서를 만드는 방법, OCSP 지원 커넥터를 구성하는 방법, OpenSSL을 사용하여 기본 OCSP 응답기를 시작하는 방법. 여기서 해야 할 일은 이러한 부분을 제어된 해지 수락 테스트로 전환하는 것입니다. (아파치 톰캣)

인증서 생성 측에서는 기관 정보 액세스 확장을 통해 발급된 인증서에 OCSP 응답자 URI를 포함하는 OpenSSL CA 구성으로 시작합니다. Tomcat의 설명서에는 관련 줄이 다음과 같이 표시됩니다. authorityInfoAccess = OCSP;URI:http://127.0.0.1:8088. 이는 장식적인 확장이 아닙니다. 이것은 Tomcat이 클라이언트 인증서 상태에 대해 어디로 문의해야 하는지 아는 방법입니다. 그 후, 문서화된 흐름은 개인 키를 만들고, CSR을 만들고, 서명하고, 결과 인증서를 확인합니다. (아파치 톰캣)

# 개인 키 만들기
openssl genrsa -aes256 -out ocsp-cert.key 4096

# CSR 만들기
openssl req -config openssl.cnf -new -sha256 \.
  -key ocsp-cert.key -out ocsp-cert.csr

# CSR 서명
openssl ca -config openssl.cnf -extensions ocsp -days 375 -notext \.
  -md sha256 -in ocsp-cert.csr -out ocsp-cert.crt

# AIA/OCSP에 대한 인증서 검사
openssl x509 -noout -text -in ocsp-cert.crt

서버 측에서는 문서화된 OCSP 지원 경로와 일치하는 Tomcat 커넥터를 사용합니다. 공식 문서에 있는 APR/네이티브 예제를 미러링하려면 APR 프로토콜을 사용하세요. FFM 경로를 구체적으로 테스트하려면 해당 기능을 지원하는 Java 버전에서 문서화된 OpenSSL 파나마 구현을 사용하세요. 중요한 점은 테스트 환경이 Tomcat에서 OCSP가 지원한다고 밝힌 커넥터 제품군 중 하나와 유사해야 한다는 것입니다. 그렇지 않으면 이 CVE가 실제로 다루는 코드 경로를 검증할 수 없습니다. (아파치 톰캣)

Tomcat의 문서에서도 기본 OpenSSL 응답자 명령어를 제공합니다:

openssl ocsp -port 127.0.0.1:8088 \.
  -text -sha256 -index index.txt \.
  -CA ca-chain.cert.pem -rkey ocsp-cert.key \.
  -rsigner ocsp-cert.crt

이를 통해 유용한 실습 순서는 간단합니다. 먼저, 테스트 CA에서 클라이언트 인증서를 발급하고 해당 인증서를 보유한 클라이언트가 mTLS 핸드셰이크를 완료하고 보호된 엔드포인트에 도달할 수 있는지 확인합니다. 둘째, CA 인덱스에서 해당 클라이언트 인증서를 해지하고 그에 따라 OCSP 응답자 상태를 업데이트합니다. 셋째, 취약한 빌드와 고정 빌드에 대해 정확히 동일한 연결 시도를 다시 실행합니다. 문제는 Tomcat이 흥미로운 것을 기록하는지 여부가 아닙니다. 문제는 현재 해지된 클라이언트 인증서가 여전히 허용되는지 여부입니다. 이것이 바로 CVE-2026-24734의 신뢰 결정에 관한 것입니다. (아파치 톰캣)

방어형 테스트 클라이언트는 다음과 같이 간단할 수 있습니다. openssl s_client 클라이언트 인증서와 키를 사용합니다:

openssl s_client \
  -connect tomcat-lab.example:8443 \.
  -cert revoked-client.crt \.
  -key revoked-client.key \
  -CAfile ca-chain.cert.pem \.
  -state -tlsextdebug

결과를 신중하게 처리하세요. 해지 후 핸드셰이크 실패는 정상적으로 예상되는 결과입니다. 해지된 인증서와 핸드셰이크에 성공하면 실패 조건입니다. 테스트 중에 더 강력한 관찰 가능성을 원한다면 Tomcat의 SSL/TLS 가이드에서 전용 TLS 핸드셰이크 디버그 로거를 활성화할 것을 권장합니다. logging.properties와 같은 로거 이름을 사용하여 org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE 또는 org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE 를 기록합니다. 이 로깅을 통해 "CVE-2026-24734가 발생했습니다"라고 마술처럼 알려주지는 않지만 일반적인 TLS 구성 오류와 검증하려는 특정 신뢰 결과를 구별하는 데 도움이 될 수 있습니다. (아파치 톰캣)

org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE
org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE

여기서 한 가지 실질적인 주의가 중요합니다. Tomcat의 문서에 따르면 OCSP를 사용할 때는 인증서에 인코딩된 응답자가 실행 중이어야 합니다. 이는 당연하게 들리지만 테스트 해석에 영향을 미칩니다. 응답자를 사용할 수 없는 경우, 소프트 실패 동작 및 시간 초과 동작이 결과의 일부가 됩니다. 이것이 바로 나중에 다음과 같은 OCSP 강화 작업을 하는 이유입니다. ocspSoftFail, ocspVerify, 시간 초과 처리 및 2026년 3월 CVE-2026-29145 수정 사항을 검증하는 동안 계속 확인해야 합니다. 팀이 맑은 날의 사례만 유효성을 검사하면 시스템이 깨진 신뢰 경로에서 다른 신뢰 경로로 이동할 수 있습니다. (아파치 톰캣)

방어자가 감지할 수 있는 항목과 일반적으로 감지할 수 없는 항목

CVE-2026-24734는 IOC가 풍부한 취약점이 아닙니다. 액세스 로그를 조회할 수 있는 정식 익스플로잇 URI가 없습니다. "해지된 인증서가 수락되었습니다."라고 외치는 명백한 애플리케이션 예외도 없습니다. 많은 환경에서 위험한 신호는 실패 신호와 반대되는 신호로, 조직에서 실패해야 한다고 생각하는 연결이 성공하는 것입니다. 따라서 탐지가 일반적인 로그 분석에서 제어 유효성 검사 및 시스템 간 증거로 전환됩니다. (Google 그룹)

가장 좋은 즉각적인 방어 기술은 능동적 검증입니다. 수명 주기를 제어하는 소규모의 테스트 클라이언트 인증서 집합을 구축합니다. 하나를 해지합니다. 핸드셰이크를 시도합니다. 거부를 확인합니다. 업그레이드, 인증서 저장소 변경, 커넥터 변경, Java 업그레이드 및 OCSP 응답자 변경 후에 반복합니다. 이러한 스타일의 테스트는 SIEM이 범용 원격 분석에서 미묘한 신뢰 실패를 추론할 때까지 기다리는 것보다 더 가치가 있습니다. RFC 6960과 OpenSSL의 유효성 모델은 모두 최신성과 요청-응답 바인딩이 신뢰 결정의 일부임을 명확히 합니다. 변경 후에도 스택이 여전히 이러한 의미를 적용하는지 확인할 수 있는 유일한 신뢰할 수 있는 방법은 해당 의미를 다시 실행하는 것입니다. (datatracker.ietf.org)

수동적 원격 분석도 여전히 역할이 있지만 간접적입니다. PKI 또는 IAM 신뢰 소스는 클라이언트 인증서가 해지되었다고 말하지만 애플리케이션 측 액세스 로그, 게이트웨이 로그 또는 다운스트림 감사 기록에는 여전히 해당 인증서 ID에 연결된 인증된 세션이 성공적으로 표시되는 경우, 이러한 불일치는 의미 있는 것입니다. 성숙한 상점에서는 인증서 인벤토리, 해지 기록 및 애플리케이션 액세스 기록이 충분히 비교 가능해야 이러한 종류의 편차를 포착할 수 있습니다. 요점은 Tomcat이 완벽한 "해지 우회" 경고를 내보낸다는 것이 아닙니다. 요점은 제어 플레인이 누군가가 눈치채지 못하게 죽은 자격 증명이 성공적인 인증 경로에 계속 나타나기 어렵게 만들어야 한다는 것입니다. (datatracker.ietf.org)

톰캣의 핸드셰이크 디버그 로깅은 핸드셰이크가 실패하거나 진행 중인 위치를 보여주고 인증서 유효성 검사 문제가 일반적인 TLS 노이즈로 축소되는 경우가 많기 때문에 선별하는 동안 유용합니다. 완전한 탐지 전략은 아니며 모든 곳에서 영원히 켜두어서는 안 됩니다. 하지만 확인 기간, 인시던트 검토 또는 통제된 재테스트 중에 방어자는 일반 요청 로그보다 OCSP 관련 동작에 대해 더 나은 렌즈를 제공합니다. (아파치 톰캣)

Apache Tomcat OCSP 경로에 대한 수정 및 강화

최소한의 해결 방법은 고정 버전 이상으로 이동하는 것입니다. 즉, 사용 중인 열차에 따라 최소 Tomcat Native 1.3.5 또는 2.0.12와 Apache Tomcat 9.0.115, 10.1.52 또는 11.0.18이 필요합니다. 하지만 "또는 이후"는 중요한 작업을 수행하고 있습니다. Apache는 최초 공개 이후에도 OCSP 관련 수정 사항을 계속 배포했습니다. 클라이언트 인증서를 의미 있는 접근 제어로 취급하는 팀의 경우, 첫 번째 패치된 빌드를 영원히 사용하는 것보다 최신 유지 관리 릴리스로 이동하는 것이 더 신중한 자세입니다. (nvd.nist.gov)

NVD에서 여전히 영향을 받는 것으로 알려진 오래된 수명이 종료된 네이티브 브랜치를 사용 중인 경우 영웅 패치를 적용할 수 없습니다. 취소 적용은 핵심 아이덴티티 로직입니다. 이미 과거에 OCSP 문제가 있는 것으로 알려진 데드 브랜치를 실행하는 것은 나중에 강화 작업의 이점이 없는 동시에 사고 대응 중에 가장 실패하기 쉬운 기술적 부채입니다. 마이그레이션이 일반적으로 더 안전하고 궁극적으로 더 저렴한 해답입니다. (nvd.nist.gov)

업그레이드 후 해지된 인증서로 다시 테스트합니다. 이것은 평범하게 들리지만 팀이 건너뛰는 가장 중요한 단계입니다. 버전 범프는 공급업체가 수정 사항을 제공했음을 알려줄 수 있습니다. 환경이 생각한 대로 고정 경로를 실행하고 있는지, OCSP 응답자가 예상한 시맨틱을 반환하고 있는지, 다른 변경 후에도 커넥터 선택 및 구성이 여전히 일치하는지 여부는 알려주지 않습니다. 해지된 인증서를 다시 테스트하지 않고 패치를 수락하는 것은 신뢰 가정이며 증명이 아닙니다. (GitHub)

OCSP 정책에 대해 명시적으로 설명하세요. Tomcat의 구성 참조 문서 ocspSoftFail 그리고 ocspVerify패치 작업을 통해 FFM 경로에서 시간 초과 및 확인 플래그에 대한 지원이 추가되었습니다. 즉, 보안에 중요한 동작이 "OCSP가 켜져 있음"으로 완전히 포착되지 않습니다. 팀은 소프트 장애 허용 여부, 허용되는 타임아웃 동작, 신뢰 저장소 및 확인 플래그의 의도적 설정 여부, 응답자가 사용할 수 없거나 늦을 때 시스템이 어떻게 작동해야 하는지를 문서화해야 합니다. 이러한 선택 사항에 대한 모호함은 실수로 프로덕션 보안 정책으로 전환될 수 있습니다. (아파치 톰캣)

제어를 보완하면 업그레이드를 배포하는 동안 노출을 줄일 수 있지만 해지 적용을 수정하는 것을 대신할 수는 없습니다. 가장 가치가 높은 인터페이스에서는 네트워크 노출 범위 축소, 명시적 애플리케이션 계층 인증, 수명이 짧은 클라이언트 인증서 및 빠른 인증서 교체 워크플로우와 mTLS를 결합하세요. 이러한 제어는 해지 처리가 일시적으로 불완전하더라도 부실하거나 손상된 인증서의 가치를 감소시키기 때문에 중요합니다. 해지된 인증서가 실제로 죽었다는 누락된 보증은 복원하지 않습니다. 고정되고 확인된 신뢰 경로만이 그렇게 합니다. (datatracker.ietf.org)

여기에는 종종 간과되는 워크플로 각도가 있습니다. 어려운 부분은 커넥터를 테스트하기 위한 하나의 셸 명령을 찾는 것이 아닙니다. 자산 범위 지정, 버전 인벤토리, 커넥터 핑거프린팅, 인증서 검사, 재테스트, 증거 수집을 릴리스, 인증서 로테이션 또는 PKI가 변경될 때마다 함께 묶어두는 것입니다. Penligent의 공개 자료는 사람이 제어하는 에이전트 워크플로, 대규모 Kali 도구 표면에 대한 원클릭 액세스, 연결된 루프로서의 검증 및 보고를 강조합니다. 실제로 이러한 버그가 발생한 후 방어자에게 필요한 작업 형태는 단순한 패치가 아니라 실제로 중요한 시스템에서 취약한 신뢰 경로가 사라졌다는 반복 가능한 증거입니다. (penligent.ai)

CVE-2026-24734를 더 중요하게 만드는 관련 CVE는 다음과 같습니다.

CVE-2026-24734를 심각하게 받아들여야 하는 이유 중 하나는 이 문제가 고립되어 있지 않다는 것입니다. 톰캣 네이티브의 보안 기록에는 해지 적용에 영향을 준 이전의 OCSP 관련 문제가 포함되어 있어, 이는 무작위적인 일회성 문제가 아니라 인증서 상태 처리가 미묘하게 잘못되기 쉽다는 것을 상기시켜 줍니다. Apache의 Native 보안 페이지는 이 계보를 한 곳에 정리해 놓았기 때문에 특히 유용합니다. (아파치 톰캣)

CVE-2017-15698은 톰캣 네이티브의 OCSP 검사 누락이었습니다. Apache는 클라이언트 인증서의 AIA 확장자를 구문 분석할 때 커넥터가 127바이트보다 긴 필드를 올바르게 처리하지 않아서 OCSP 검사를 건너뛰었다고 말합니다. 그 영향은 직접적이었습니다. OCSP 검사를 실행했다면 거부되어야 하는 클라이언트 인증서가 대신 수락될 수 있었습니다. 이는 CVE-2026-24734와는 다른 구현 버그이지만 주제는 동일합니다. 해지 로직은 보안에 중요하며 겉보기에 이차적인 구문 분석 또는 유효성 검사 오류로 인해 무력화될 수 있습니다. (아파치 톰캣)

CVE-2018-8019와 CVE-2018-8020은 같은 방향으로 진행되었습니다. 한 경우에는 잘못된 OCSP 응답이 잘못 처리되어 해지된 클라이언트 인증서가 잘못 식별될 수 있었습니다. 다른 한 건은 인증서 상태 목록이 포함된 OCSP 사전 생성 응답을 부적절하게 확인하여 상호 TLS가 필요한 연결에서 해지된 클라이언트 인증서가 통과할 수 있는 여지를 만들었습니다. 이러한 오래된 이슈는 올바른 본능을 훈련한다는 점에서 가치가 있습니다. OCSP 처리가 관련된 경우 구문이나 상태 필드에서 멈추지 마세요. 응답 권한, 응답 구조, 응답 최신성 및 평가 중인 정확한 인증서 ID가 모두 올바르게 처리되고 있는지 확인해야 합니다. (아파치 톰캣)

그런 다음 CVE-2026-24734가 나왔는데, 이는 네이티브 및 FFM 경로에서 불완전한 검증 및 최신성 검사를 수정합니다. 그리고 얼마 지나지 않아 CVE-2026-29145가 나타나며, 아파치는 다음과 같이 설명합니다. CLIENT_CERT 인증이 일부 시나리오에서 소프트 장애가 비활성화되어 있어도 예상대로 OCSP 검사에 실패하지 않았습니다. 이러한 후속 문제는 원래의 수정이 잘못되었다는 증거가 아닙니다. 이는 운영 엣지 케이스에서 OCSP 동작이 여전히 까다롭다는 증거이며, 방어 팀은 "한 번 패치했다"고 해서 "영원히 해결된 것"으로 간주하지 말고 전체 신뢰 경로를 검증해야 합니다. (아파치 톰캣)

클라이언트 인증서를 많이 사용하는 팀의 경우, OCSP 제품군 외부에서 발생한 Tomcat의 인증서 확인 우회 문제에서 또 다른 교훈을 얻을 수 있습니다. 아파치는 가상 호스트 매핑과 관련된 클라이언트 인증서 확인 우회로 CVE-2025-66614를 공개했고, 나중에 해당 영역의 불완전한 수정 사항으로 CVE-2026-32990을 공개했습니다. 직접적인 메커니즘은 CVE-2026-24734와 다르지만 운영 메시지는 동일합니다. 커넥터 동작, 호스트 매칭 및 해지 로직이 잘못 구현되거나 구성될 경우 모두 권한 부여 실패로 이어질 수 있으므로 Tomcat의 인증서 기반 신뢰 경계를 계속 검토할 필요가 있습니다. (아파치 톰캣)

CVE	면적	여기서 중요한 이유	실습 레슨
CVE-2017-15698	OCSP 확인 생략	AIA 구문 분석 버그로 인해 OCSP를 완전히 건너뛸 수 있음	"OCSP 사용"이 "OCSP 적용"을 의미한다고 가정하지 마세요.
CVE-2018-8019	잘못된 OCSP 응답 처리	해지된 클라이언트 인증서가 잘못 식별될 수 있습니다.	응답 형식 처리는 인증 정확성의 일부입니다.
CVE-2018-8020	사전 제작된 OCSP 응답 처리	해지된 클라이언트 인증서는 여전히 인증할 수 있습니다.	캐시되거나 번들로 제공되는 응답 로직은 엄격한 유효성 검사가 필요합니다.
CVE-2026-24734	불완전한 검증 및 신선도 검사	해지 우회 가능	시그니처, 논스, 신선함이 모두 중요합니다.
CVE-2026-29145	소프트 장애 동작 엣지 사례	CLIENT_CERT 인증이 여전히 소프트 실패할 수 있습니다.	행복한 경로뿐만 아니라 에지 조건을 패치한 후 다시 테스트하기

패치 후 증거, 보고 및 재테스트

수정이 완료되면 다른 엔지니어, 감사자 또는 미래의 본인이 추측 없이 세 가지 질문(어떤 시스템이 영향을 받았는지, 무엇이 변경되었는지, 어떤 정확한 테스트에서 해지된 인증서 경로가 이제 실패하는지)에 답할 수 있을 정도로 증거가 충분할 때까지 작업이 완료되지 않았습니다. 즉, 중요한 커넥터 구성, 테스트에 사용된 인증서 ID, 해지 이벤트, 핸드셰이크 전후의 동작, 각 실행 중 Tomcat 또는 Tomcat Native의 정확한 버전 상태를 보존해야 합니다. 좋은 해결 증거가 구체적이지 않으면 유용하지 않습니다. (아파치 톰캣)

바로 이 지점이 AI 지원이 도움이 되기도 하고 해가 되기도 하는 지점입니다. "업그레이드 및 재테스트 성공"이라는 모호한 AI 생성 노트는 증거가 될 수 없습니다. 강력한 펜테스트 또는 검증 보고서에는 일반적인 모델 산문보다는 명확한 위치, 구체적인 영향 설명, 재현 단계 및 이를 뒷받침하는 아티팩트가 필요합니다. 이러한 사고 방식이 바로 CVE-2026-24734에 대한 패치 후 검증에 필요한 것입니다. 좋은 기록은 단순히 이미 한 신뢰 결정을 다른 엔지니어가 재연할 수 있도록 해야 합니다. (penligent.ai)

CVE-2026-24734의 진정한 교훈

CVE-2026-24734는 많은 시스템이 인증서 신뢰를 실제로는 정적인 속성으로 취급하는 일반적인 보안 습관을 노출하기 때문에 유용한 취약점입니다. 인증서가 잘 만들어지고 올바른 발급자가 서명했지만 발급자가 인증서를 취소했기 때문에 신뢰할 수 없을 수 있습니다. OCSP는 그 실시간 결정을 TLS 핸드셰이크에 전달해야 합니다. 구현이 응답자를 올바르게 확인하지 않거나, 요청과 응답을 올바르게 바인딩하지 않거나, 새로 고침을 올바르게 적용하지 않으면 시스템은 더 이상 실시간 신뢰 결정을 내리지 않습니다. 오래된 결정을 내리고 있는 것입니다. (datatracker.ietf.org)

그렇기 때문에 이 CVE는 헤드라인 프로필이 시사하는 것보다 더 많은 주의를 기울여야 합니다. 클라이언트 인증서 없이 일반 HTTPS를 종료하는 데 Tomcat을 사용하는 팀에게는 이 버그가 별다른 문제가 되지 않는 패치 항목일 수 있습니다. mTLS를 실제 경계로 사용하는 팀에게는 조직이 말했을 때 해지된 ID가 정말 사라지는지 직접적으로 테스트할 수 있는 문제입니다. 아파치는 이 문제를 해결했습니다. 남은 작업은 취약한 신뢰 경로가 존재했던 위치를 파악하고, 현재 지원되는 버전으로 이동하고, 해지된 인증서로 유효성을 검사하고, PKI, 커넥터 스택 또는 ID 경계가 변경될 때마다 이 작업을 계속 수행하는 등 방어자의 몫입니다. (Google 그룹)

추가 읽기 및 참고 자료

• CVE-2026-24734, 영향을 받는 버전, CVSS 및 참조 세트에 대한 NVD 항목입니다. (nvd.nist.gov)
• 심각도, 영향을 받는 버전, 완화 조치 및 Joshua Rogers에 대한 크레딧이 포함된 Apache 권고 텍스트. (Google 그룹)
• CVE-2026-24734 및 이후 OCSP 관련 후속 CVE-2026-29145에 대한 아파치 톰캣 9 보안 페이지 항목. (아파치 톰캣)
• CVE-2026-24734 및 이후 OCSP 관련 후속 CVE-2026-29145에 대한 아파치 톰캣 10.1 보안 페이지 항목. (아파치 톰캣)
• CVE-2026-24734 및 이후 OCSP 관련 후속 CVE-2026-29145에 대한 아파치 톰캣 11 보안 페이지 항목. (아파치 톰캣)
• CVE-2026-24734 및 CVE-2017-15698, CVE-2018-8019, CVE-2018-8020을 포함한 이전 OCSP 계보에 대한 Apache Tomcat Native 보안 페이지입니다. (아파치 톰캣)
• 2026년 1월의 수정 릴리스와 이후 릴리스에서 계속되는 OCSP 관련 진화를 보여주는 Apache Tomcat 릴리스 노트. (아파치 톰캣)
• 지원되는 커넥터 제품군, 클라이언트 인증서 포커스, AIA 요구 사항, 커넥터 예제, 응답자 시작 및 핸드셰이크 로깅을 다루는 Tomcat SSL/TLS OCSP 문서입니다. (아파치 톰캣)
• 다음에 대한 Tomcat 커넥터 구성 참조 ocspEnabled, ocspSoftFail및 ocspVerify. (아파치 톰캣)
• 다음에 대한 OpenSSL 문서 OCSP_기본_확인, OCSP_check_validity상태 추출 및 응답 연령 처리를 지원합니다. (docs.openssl.org)
• OCSP 시맨틱을 위한 RFC 6960은 다음과 같습니다. 이 업데이트, 다음업데이트, producedAt및 논스. (datatracker.ietf.org)
• 아파치 톰캣 수정 커밋 e76e9ea를 클릭하면 OpenSSL FFM 경로에 추가된 논스, 서명 및 최신성 검사를 보여줍니다. (GitHub)
• 톰캣 네이티브 후속 커밋 69a977d이는 최초 공개 이후에도 OCSP 경화가 계속된 이유를 설명하는 데 도움이 됩니다. (GitHub)
• 상담원 워크플로, 도구 액세스, 확인 및 보고와 관련된 공개 제품 정보를 제공하는 펜리전트 홈페이지입니다. (penligent.ai)
• 보안 제어에 일회성 가정이 아닌 반복적인 공격 검증이 필요한 광범위한 사례를 통해 AI 방어에 지속적인 모의 침투 테스트가 필요한 이유를 보여주는 프로젝트 Glasswing. (penligent.ai)
• 보안 보고에서 증거 품질, 재현 세부 정보 및 지원 아티팩트에 대한 실용적인 지침은 AI 펜테스트 보고서를 얻는 방법을 참조하세요. (penligent.ai)