CVE-2026-5430 (WSO2 API Manager JWT 서명검증 우회) 분석

01개요

CVE-2026-5430은 WSO2 API Manager(오픈소스 API 게이트웨이·관리 플랫폼)의 REST API(Admin/Publisher/DevPortal 등)가 사용하는 JWT(JSON Web Token) 인증에서, 지원되지 않는 서명 알고리즘의 토큰이 발생시키는 예외를 인증 인터셉터가 요청 거부로 연결하지 못하고 그냥 통과시키는 결함입니다. WSO2가 이 취약점에 매긴 자체 어드바이저리 번호는 WSO2-2026-5328로, CVE 번호(CVE-2026-5430)와는 다른 벤더 내부 식별자입니다.

공격자는 회원가입도 로그인도 필요 없이, RS256/RS384/RS512가 아닌 알고리즘으로 admin 클레임을 담은 JWT를 스스로 서명해 위조할 수 있습니다. 이 토큰이 인증을 우회해 통과하면, watchTowr의 표현대로 "모든 API 백엔드 엔드포인트와 그 자격 증명, 컨슈머 키·시크릿"까지 접근 범위에 들어갑니다.

발견자는 Hacktron Team이며, WSO2는 어드바이저리를 2026-05-03에 공개했습니다. 이후 2026-09-13, 위협 인텔리전스 업체 watchTowr의 허니팟 네트워크가 admin 권한이 박힌 위조 JWT가 실제로 유입되는 것을 포착해 실공격 관측(active in-the-wild exploitation)이 확인됐습니다.

CVSS: 9.8 (단일 테넌트, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) / 10.0 (멀티 테넌트, Scope Changed — S:C)

WSO2 어드비저리 자체엔 CWE가 명시되지 않았습니다. 보도매체 다수는 이를 CWE-347(부적절한 암호서명 검증)로 분류합니다 — 이 글이 소스 대조로 직접 짚는 더 정밀한 근본원인(CWE-703, 예외적 조건의 부적절한 처리)은 §04 참고.

02영향받는 버전

03기술적 배경 — CXF 인터셉터 체인과 "막지 않으면 통과"라는 기본값

WSO2 API Manager의 관리용 REST API(Admin·Publisher·DevPortal 등)는 Apache CXF의 JAX-RS 구현 위에서 동작합니다. CXF는 실제 리소스 메서드(예: 사용자 생성 API 구현체)를 호출하기 전, 여러 단계(Phase)별로 등록된 인터셉터를 순서대로 거치게 합니다 — 인증은 그중 PRE_INVOKE 단계에 등록된 OAuthAuthenticationInterceptor가 담당합니다.

이 인터셉터는 AbstractPhaseInterceptor를 상속하는데, 이 계열 인터셉터의 동작 방식이 이번 취약점의 핵심 전제입니다 — handleMessage()가 명시적으로 예외를 던지거나 체인을 중단시키지 않는 한, CXF는 이 인터셉터를 "통과"로 간주하고 다음 단계(결국 실제 리소스 메서드 호출)로 그대로 진행합니다. 즉 이 설계는 "의심되면 막는다(fail-closed)"가 아니라 "막으라고 말하지 않으면 통과시킨다(fail-open)"는 기본값 위에 서 있습니다.

인증 자체는 요청의 Authorization: Bearer <JWT> 헤더를 OAuthJwtAuthenticatorImpl.authenticate()가 받아, 서명 검증을 JWTValidatorImpl.validateSignature() → JWTUtil.verifyTokenSignature()로 위임하는 구조입니다. JWT 헤더에는 서명에 쓴 알고리즘(alg)이 자체 명시되는데, WSO2는 RS256·RS384·RS512(RSA 계열) 서명만 신뢰하도록 이 값을 검사합니다 — 그 외 알고리즘(예: 대칭키 HS256, 무서명 none 등)이면 검증을 거부해야 합니다.

여기까지 정리하면 이 API의 안전은 정확히 한 가지에 달려 있습니다 — 알고리즘 검증이 실패했을 때, 그 실패가 정말로 CXF 체인을 멈추는가. 다음 절에서 이 연결이 어디서 끊기는지 봅니다.

04취약점 발생 원인

이 취약점은 "서명 검증이 허술해서"가 아니라 "검증 실패를 처리하는 방식이 잘못돼서" 뚫립니다. 미흡점 세 개가 순서대로 맞물립니다 — 검증 로직(W1)은 실제로 이상 알고리즘을 정상적으로 거부하지만, 그 거부 신호를 받은 인터셉터(W2)가 신호를 소거해버리고, 이 소거가 완전한 우회로 이어지는 것은 CXF 인터셉터 체인의 기본 설계(W3) 때문입니다.

1"RSA 계열이 아니면 거부한다" — 서명 검증 자체는 실제로 이상 알고리즘을 거부한다

이 메서드는 truststore에서 인증서를 찾고, 그 인증서로 서명을 검증하기 전에 먼저 JWT 헤더의 알고리즘을 확인합니다. RSA 계열이 아니면 verifyTokenSignature(jwt, publicKey)(실제 암호학적 서명 검증)까지 가지도 않고, 그 자리에서 즉시 APIManagementException을 던집니다 — 이 자체는 정상적인 방어입니다.

wso2/carbon-apimgt 실제 소스(패치 전) — JWTUtil.java:107-131 · verifyTokenSignature(SignedJWT, String) (부모 커밋 52ae133).

왜 이렇게 됐나이 함수만 떼어 보면 완벽합니다 — RSA 계열이 아니면 실제 암호학적 검증까지 가지 않고 즉시 예외로 거부합니다. 붉게 표시한 부분(122-125행)이 바로 그 거부 지점입니다 — 다음 절의 질문은 "이 예외를 받은 쪽이 정말로 요청을 막는가"입니다.

2"예외가 났으니 거부됐겠지" — 인터셉터가 예외를 잡고 그냥 지나간다

W1의 예외는 곧바로 이 인터셉터로 올라오지 않습니다 — OAuthJwtAuthenticatorImpl.authenticate()가 JWTValidatorImpl.validateSignature()를 거쳐 JWTUtil.verifyTokenSignature()를 호출하고, 이 호출 경로의 어느 메서드도 APIManagementException을 흡수하지 않은 채 그대로 위로 전파합니다. 이 예외를 처음으로 catch하는 곳이 바로 인터셉터의 handleMessage()입니다.

wso2/carbon-apimgt 실제 소스(패치 전) — OAuthAuthenticationInterceptor.java:98-111 · handleMessage() (부모 커밋 52ae133).

왜 이렇게 됐나바로 위 throw new AuthenticationException(...) 분기(106행)는 뒤에서 볼 GlobalThrowableMapper가 401로 정확히 매핑합니다. 하지만 바로 아래 catch 블록(108-110행)은 똑같이 "인증 실패"인 상황인데도 예외를 로그만 남기고 삼킵니다. handleMessage()가 아무것도 던지지 않고 정상 종료되면, CXF의 PRE_INVOKE 인터셉터 체인은 "이 인터셉터를 통과했다"고 보고 다음 단계로 그대로 진행합니다. 참고로 이 파일에는 authenticator == null일 때 쓰이는 두 번째 인증 경로(147-149행 부근, authenticatorMap을 통해 기본 JWT/Opaque 인증을 수행하는 경로 — 이번 CVE의 실제 취약 경로)에도 완전히 동일한 패턴(로그만 남기고 아무것도 다시 던지지 않음)이 있었습니다. 패치는 이 두 catch 블록을 모두 고칩니다.

3"막지 않으면 통과" — 안전장치는 있었지만 신호가 거기까지 가지 않았다

CXF의 JAX-RS 계층에서 리소스 메서드 호출 중(또는 이번처럼 인터셉터 단계에서) 예외가 실제로 던져지면, ExceptionMapper인 GlobalThrowableMapper.toResponse()가 이를 받아 적절한 HTTP 상태 코드로 변환합니다. 아래는 그중 인증 실패를 401로 매핑하는 부분입니다 — 이 코드는 이번 패치로 바뀌지 않았습니다(원래도 정상 동작).

wso2/carbon-apimgt 실제 소스(패치 전·후 동일 — 이 분기는 이번 커밋에서 변경되지 않았습니다) — GlobalThrowableMapper.java:128-139.

왜 이렇게 됐나이 매핑 로직은 처음부터 옳았습니다 — 무언가 AuthenticationException이나 APIManagementException으로 이 코드에 도달하기만 하면 401을 정확히 돌려줬을 것입니다. 하지만 CXF의 PRE_INVOKE 인터셉터 체인은 "명시적으로 막으라고 말하지 않으면 통과시킨다"는 기본값(fail-open) 위에 있어서, W2에서 아무것도 던지지 않는 순간 이 안전장치 자체가 호출될 기회를 잃습니다. 안전장치가 없었던 게 아니라, 그 안전장치를 켜는 스위치가 눌리지 않은 것입니다.

05공격 과정

5.1 공격 과정 요약

공격 흐름도 (직접 작성)

• 공격자가 회원가입·로그인 없이, RS256/RS384/RS512가 아닌 알고리즘으로 admin 클레임을 담은 JWT를 오프라인으로 스스로 서명해 위조합니다.
• 이 위조 토큰을 Authorization: Bearer 헤더에 담아 WSO2 REST API(Admin/Publisher/DevPortal 등)에 요청을 보냅니다.
• OAuthJwtAuthenticatorImpl → JWTValidatorImpl.validateSignature() → JWTUtil.verifyTokenSignature()가 알고리즘을 확인하고, RSA 계열이 아니므로 APIManagementException을 던집니다.
• 이 예외가 흡수되지 않고 그대로 전파돼 OAuthAuthenticationInterceptor.handleMessage()의 catch(APIManagementException) 블록까지 올라갑니다.
• 이 catch 블록은 로그만 남기고 아무것도 다시 던지지 않은 채 정상 종료합니다 — CXF PRE_INVOKE 인터셉터 체인은 이 요청이 통과한 것으로 보고 다음 단계로 진행합니다.
• 체인이 실제 REST 리소스 메서드 호출까지 그대로 이어지며, 위조 토큰의 admin 클레임이 검증되지 않은 채 관리자 권한 동작(API 백엔드·컨슈머 키/시크릿 접근 등)에 도달합니다.

5.2 상세 공격 과정

이 취약점은 흔한 "서명 위조에 성공했다" 계열과 결이 다릅니다 — 공격자는 실제 서명 검증을 속이지 않습니다. 애초에 RSA 서명을 만들 필요조차 없습니다. 확인 저희가 직접 대조한 코드 경로에서, 알고리즘 검사(§04 W1)는 서명값을 들여다보기도 전에 예외를 던지므로 — 필요한 건 "RS256/384/512가 아닌 alg 값을 가진, 형식만 맞는 3-세그먼트 토큰" 하나뿐입니다.

분석 저희가 이번 세션에서 추적한 OAuthJwtAuthenticatorImpl.authenticate()의 호출 순서상, 서명 검증(validateSignature)은 스코프 클레임을 읽는 handleScopeValidation()보다 먼저 실행됩니다. 즉 이 우회 경로를 타는 요청은 서명 검증뿐 아니라 스코프(권한) 검증 자체가 아예 실행되지 않은 채 리소스 메서드에 도달할 가능성이 있습니다 — WSO2·watchTowr가 설명한 "admin 클레임을 넣은 위조 토큰"은 실제 공격에 쓰인 구체적인 방법이지만, 저희가 대조한 코드만 보면 이론적으로는 그보다 더 헐거운 조건(스코프 검증 자체의 부재)까지도 열려 있었을 수 있습니다. 이 마지막 한 문장은 리소스 구현체까지 끝까지 추적하지 않은 추론이며, WSO2가 별도로 확증하지 않은 부분입니다.

실제 작동하는 위조 토큰의 정확한 헤더·페이로드 값은 이 글에 싣지 않습니다(무해화 원칙) — 여기서는 "어떤 조건이 이 경로를 타는가"까지만 개념적으로 다룹니다.

5.3 미흡점 ↔ 공격 흐름 매핑

06취약점 패치

07대응방안

위 표에 정리한 제품별 update level 이상으로 갱신하는 것이 유일한 근본 해결책입니다. 커뮤니티 사용자는 GitHub PR #13752/#14167의 패치를 직접 적용하거나 이후 릴리스로 업그레이드하고, WSO2 지원 구독 고객은 WSO2 Update Manager로 표의 update level 이상으로 갱신합니다.

• 즉시 업데이트가 어렵다면 Admin/Publisher/DevPortal REST API 앞단(리버스 프록시·API 게이트웨이)에서 Authorization 헤더의 JWT를 사전 파싱해, 헤더의 alg 값이 RS256/RS384/RS512가 아닌 요청을 차단하는 임시 규칙을 둡니다 — 서버가 최종적으로 하는 검사와 같은 조건을 앞단에서 선제 차단하는 것입니다.
• 관리용 REST API(특히 /api/am/admin, /api/am/publisher 등)를 공인 인터넷에 직접 노출하지 말고 VPN·IP 허용목록으로 접근을 제한합니다.
• 탐지 관점. RS256/RS384/RS512가 아닌 alg 헤더를 가진 JWT가 관리용 REST API에 도달하는 요청, 그리고 정상 로그인 절차 없이 곧바로 admin 스코프·클레임을 가진 토큰이 등장하는 패턴을 WAF·API 게이트웨이 로그에서 관찰합니다. 서버 로그의 "Authentication Failure"/"Error while authenticating" 문구가 실제로는 요청이 차단되지 않고 통과했던 흔적일 수 있다는 점(패치 전 버전)도 사후 조사 시 참고합니다.

08왜 이게 반복되는가

이 사고와 저희가 함께 다룬 Issabel Framework 하드코딩 JWT 키 사례(CVE-2026-89026)는 둘 다 "위조 JWT로 관리자 권한을 탈취"라는 같은 결과에 이르지만, 근본원인은 정반대입니다 — Issabel은 검증에 쓰는 키 자체가 공개돼 서명 검증이 애초에 무의미했던 경우(CWE-321)였고, WSO2는 검증 로직·오류 매핑 인프라 모두 각각은 정상이었지만 그 사이 예외 처리 한 곳이 신호를 끊어버린 경우(CWE-703)입니다. "서명을 확인한다"는 문장 하나로는 안전을 보장할 수 없습니다 — 확인에 실패했을 때 정확히 무엇을 하는지까지가 그 문장의 일부라는 것을, 두 사례가 나란히 보여줍니다.

체크된 예외(checked exception)를 catch한 뒤 로그만 남기고 지나가는 코드는 Java 코드베이스에서 흔합니다 — 대부분은 무해하지만, 그 예외가 "이 요청을 거부해야 한다"는 보안 판단을 실어 나르는 통로일 때는 이야기가 다릅니다. 이번 사례처럼 인증 프레임워크가 "명시적으로 막지 않으면 통과"라는 fail-open 기본값을 갖고 있다면, catch 블록 하나의 누락이 곧 인증 전체의 누락으로 번집니다.

패치 완전성 평가. ① 근본원인을 막았나: 확인 — 같은 파일 안의 두 catch 블록 모두 동일한 패턴으로 수정됐고, 신호가 소거되는 지점이 남아 있지 않습니다. ② variant 여지: 분석 — 저장소 전체에서 JWTUtil.verifyTokenSignature류를 호출하는 지점을 찾아보면 API 게이트웨이(데이터플레인) 쪽의 GatewayUtils.java·InternalAPIKeyAuthenticator.java(Internal Key/MCP 인증 경로)도 있습니다 — 이 경로가 같은 "예외를 잡고도 명시적으로 거부하지 않는" 패턴을 공유하는지는 이번 세션에서 끝까지 추적하지 않았습니다. 정적 신호일 뿐이며 별도 patch-gap 후보로만 남깁니다. ③ silent/불완전 재패치: 분석 — product-apim의 PR #14167은 통합 테스트 갱신뿐이라 재패치가 필요했다는 신호로 보기 어렵고, 이 패치를 되짚는 후속 커밋도 확인되지 않았습니다. 종합하면 이번 패치는 REST API 인터셉터 경로에 한해 근본원인 제거로 판단되며, 게이트웨이 측 Internal Key 경로는 별도 확인이 필요한 가설로 남습니다.

서명 검증 로직도, 오류를 HTTP 코드로 바꾸는 인프라도 각각은 멀쩡했습니다. 문제는 그 둘 사이, 실패를 실패로 전달하는 단 하나의 통로였습니다 — 그래서 저희는 도구가 아니라 이 질문("이 예외가 정말로 요청을 막고 있는가")을 남깁니다.

09결론

CVE-2026-5430은 WSO2 API Manager 등 4개 제품의 REST API 인증에서, 지원되지 않는 서명 알고리즘의 JWT가 만드는 예외를 인터셉터가 로그만 남기고 그냥 통과시켜 발생하는 인증 우회입니다(CVSS 3.1 = 9.8~10.0). 서명 검증 로직도, HTTP 오류 매핑 인프라도 각각은 정상이었지만, 그 사이 인터셉터의 catch 블록 두 곳이 거부 신호를 소거해 CXF 인터셉터 체인의 "막지 않으면 통과" 기본값이 그대로 우회로 이어졌습니다. 패치는 새 예외 타입을 던지고 매핑 조건을 넓혀 이 신호를 복구합니다. 2026-09-13 watchTowr가 실공격을 관측했습니다.