앞단은 막았는데 뒷단이 열렸다, WebLogic 프록시 플러그인 CVE-2026-21962

이미지 출처: CISA KEV

웹 서버를 앞에 세우고 애플리케이션 서버를 뒤에 숨기는 구성은 자바 진영에서 거의 20년 가까이 정석 취급을 받아 왔음. Oracle HTTP Server(OHS)가 요청을 받아 WebLogic Server로 넘겨주는 프록시 플러그인, 흔히 mod_wl_ohs 혹은 mod_weblogic이라 부르는 그 모듈이 그 정석의 한가운데에 있음. 그런데 이번에 공개된 CVE-2026-21962는 그 중간 다리 자체가 "누구를 어디로 보낼지"를 잘못 판단할 수 있다는 이야기라서, 구조를 믿고 설계했던 사람일수록 더 신경이 쓰이는 사안임.

핵심 요약

• Oracle HTTP Server와 WebLogic Server 프록시 플러그인에서 접근 통제가 제대로 적용되지 않는 결함으로, 원격에서 HTTP만으로 건드릴 수 있는 성격의 문제임.
• 프록시 뒤를 "내부망이니까 안전하다"고 가정한 구성일수록 관리 경로·내부 전용 경로가 그대로 노출될 위험이 커짐.
• 정답은 Oracle 정기 패치 적용이고, 그 전까지는 경로 화이트리스트·WL-Proxy 계열 헤더 정리·백엔드 자체 인증으로 시간을 벌어야 함.

1. 이 플러그인이 실제로 하는 일

프록시 플러그인은 단순한 전달자가 아님. 요청 URI를 보고 WebLogic으로 보낼지 OHS가 직접 처리할지 고르고, 클러스터 멤버 목록을 관리하고, 원본 클라이언트 정보를 WL-Proxy-Client-IP, WL-Proxy-SSL 같은 헤더에 실어 뒤로 넘김. 즉 백엔드 입장에서 "이 요청이 누구한테서 왔는가"라는 판단의 상당 부분을 이 모듈에 위임하고 있는 셈임.

그러다 보니 이 모듈이 경로 매칭이나 접근 조건을 느슨하게 해석하는 순간, 앞단 웹 서버에 아무리 촘촘하게 규칙을 걸어 두었어도 그 규칙을 우회한 요청이 뒤로 흘러갈 수 있음. 이번 건의 성격이 딱 그 지점임. 공격 재현을 세세히 늘어놓을 필요는 없고, 개념만 잡으면 충분함. 앞단의 접근 통제와 뒷단의 라우팅 판단이 서로 다른 기준으로 같은 URI를 해석할 때 틈이 생긴다는 고전적인 구도.

2. 방어자가 진짜 걱정해야 할 부분

WebLogic을 운영해 본 사람은 알겠지만, 관리 콘솔이나 Enterprise Manager 경로는 보통 "외부에서는 프록시가 막아 주니까"라는 전제로 남겨 두는 경우가 많음. 인증이 아예 없는 게 아니라, 인증 앞에 놓인 방어선이 하나 더 있다고 믿는 상태인 것임. 그 방어선이 무력화되면 남는 건 계정 하나뿐이고, 기본 계정이나 오래된 계정이 살아 있다면 이야기가 급격히 나빠짐.

여기에 더해, 백엔드 애플리케이션이 원본 IP를 판단할 때 프록시가 붙여 준 헤더를 그대로 믿는 코드가 흔함. 외부에서 온 요청이 프록시 계층을 제대로 거치지 않고 들어올 수 있다면, 그 헤더는 더 이상 신뢰 근거가 아니라 공격자가 제어하는 입력값이 됨. 관리자 IP 화이트리스트가 이런 방식으로 무너지는 사례를 여러 번 봤음.

3. 탐지: 무엇을 어디서 볼 것인가

• OHS 액세스 로그와 WebLogic 액세스 로그 상관분석 — 뒷단에는 기록이 있는데 앞단 로그에는 대응되는 항목이 없거나, 같은 요청인데 URI 문자열이 서로 다르게 남는 경우가 가장 굵은 신호임.
• URI 정규화 흔적 — 중복 슬래시, 점 세그먼트, 세미콜론 파라미터, 이중 인코딩이 섞인 요청이 특정 시간대에 몰리는지 확인. 정상 브라우저 트래픽은 이런 모양을 거의 만들지 않음.
• 내부 전용 경로에 대한 외부 출처 요청 — 콘솔·관리·헬스체크·상태 조회 계열 경로가 대상. 인증 실패든 성공이든 시도 자체를 알림 대상으로 올려 두는 편이 나음.
• WL-Proxy 계열 헤더가 클라이언트 요청에 실려 들어오는지 — 이 헤더는 원래 프록시가 붙이는 것이므로, 바깥에서 들어온 요청에 이미 들어 있다면 그 자체가 이상 징후임.
• 플러그인 디버그 로그 — 상시로 켜 두긴 부담스럽지만, 점검 기간 동안 한시적으로 켜서 라우팅 결정이 어떤 기준으로 내려졌는지 확인해 볼 가치가 있음.

4. 완화: 순서대로 밟기

첫째는 두말할 것 없이 Oracle 정기 보안 패치 적용임. 프록시 플러그인은 OHS 쪽과 WebLogic 쪽 버전이 함께 맞아야 하는 물건이라, 한쪽만 올리고 끝냈다가 낭패를 보는 일이 자주 생김. 적용 대상 목록을 만들 때 플러그인이 별도 웹 서버에 얹혀 있는 케이스를 빠뜨리지 않는 게 중요함.

둘째, 패치 창구가 열릴 때까지는 앞단에서 허용 경로 화이트리스트로 좁히는 방식을 권함. 막을 것을 나열하는 블랙리스트는 인코딩 변형 앞에서 늘 지는 싸움이었음. 셋째, 프록시 계층에서 들어오는 WL-Proxy 계열 헤더를 무조건 제거한 뒤 새로 붙이도록 정리할 것. 넷째, 백엔드가 프록시를 최종 방어선으로 삼지 않도록 관리 경로에 자체 인증과 접근 제한을 이중으로 걸어 두기. 다섯째, 관리 콘솔은 아예 별도 네트워크 세그먼트나 별도 포트로 분리해서 외부 경로에서 도달 자체가 불가능하게 만드는 게 가장 확실함.

5. 오늘 바로 해볼 점검 목록

• 우리 환경에 mod_wl_ohs 또는 mod_weblogic이 어디어디에 설치되어 있는지 전수 조사
• OHS와 WebLogic의 패치 레벨이 서로 맞는지 대조
• 외부에서 관리 콘솔 경로에 도달 가능한지 실제로 확인
• 최근 한 달치 로그에서 앞단·뒷단 요청 수 불일치 구간 찾기
• 백엔드 코드가 프록시 헤더를 그대로 신뢰하는지 검토

개인적으로는 이런 종류의 취약점이 나올 때마다 "우리는 어디를 안전하다고 가정하고 있었나"를 다시 적어 보는 습관을 추천함. 패치는 이번 한 번으로 끝나지만, 잘못 잡힌 신뢰 경계는 다음 CVE에서 또 같은 자리를 내주게 되어 있음. 각자 환경에서 점검해 보시고, 로그에서 이상한 패턴 발견하신 분들은 어떤 모양이었는지 댓글로 공유해 주세요. 같이 정리하다 보면 훨씬 빨리 감이 잡힐 겁니다.