CVE-2026-114437: go-chi ClientIPFromXFF의 X-Forwarded-For 기반 클라이언트 IP 스푸핑 점검

Go 라우터 라이브러리 go-chi의 chi/v5 미들웨어 ClientIPFromXFF에서 클라이언트 IP 스푸핑 취약점이 보고되었습니다. 식별자는 CVE-2026-114437, GitHub 보안 어드바이저리는 GHSA-j6qf-3m9c-vwj3입니다. 이 미들웨어는 X-Forwarded-For(XFF) 헤더를 근거로 클라이언트 IP를 판단하는데, 신뢰 프록시 CIDR 설정만으로는 공격자가 직접 삽입한 헤더 값을 걸러내지 못하는 구조적 문제가 있었습니다.

이 글은 확인된 사실(원인, 수정 방식, PoC 존재)과 아직 확인되지 않은 사항(수정 릴리스 버전, CVSS, 야생 악용)을 분리해, 지금 자신의 환경에서 무엇을 점검하고 어떤 순서로 대응해야 하는지를 정리합니다.

개요

middleware.ClientIPFromXFF는 요청이 들고 있는 X-Forwarded-For(XFF) 헤더 값을 근거로 클라이언트 IP를 판단하는 미들웨어입니다. 어드바이저리에 따르면 이 판단의 근거는 연결의 실제 TCP 소스 주소가 아니라 헤더로 전달된 값입니다.

핵심 원인은 수정 커밋 메시지에 압축되어 있습니다. 커밋 7f9b744는 'treat RemoteAddr as the rightmost hop in ClientIPFrom*'이라는 제목으로, 연결의 실제(peer) 주소를 XFF 체인의 가장 오른쪽 홉으로 취급하도록 동작을 바꾸었습니다. 바꿔 말하면 이전 동작에서는 연결 상대(RemoteAddr)가 신뢰 범위에 속하는지를 체인의 종착점에서 검증하지 않아, 공격자가 임의로 넣은 XFF 항목이 신뢰 프록시를 통과한 값처럼 다뤄질 여지가 있었던 셈입니다.

이 차이가 왜 중요한지는 뒤의 영향 범위에서 구체적으로 다루지만, 요약하면 이렇습니다. IP 주소 하나를 '신뢰할 수 있는가'로 믿고 접근 허용, 차단, 레이트 리밋, 감사 로그를 결정해 왔다면 그 전제가 이번 어드바이저리로 흔들리게 되었습니다.

영향 범위

영향 범위는 라이브러리 자체가 아니라 구성과 사용 방식에 따라 결정됩니다. 기술 분석 기준 다음 구성이 점검 대상입니다.

• github.com/go-chi/chi/v5의 middleware.ClientIPFromXFF를 사용하는 애플리케이션
• 신뢰 프록시 CIDR(어드바이저리 PoC의 예시값은 198.51.100.0/24)을 인자로 지정하고, XFF 기반 클라이언트 IP를 인가·ACL 같은 보안 판단에 쓰는 구성
• PoC가 보여준 것처럼 산출된 클라이언트 IP를 허용 목록(예시 allowedIP = "10.0.0.7")과 직접 비교하는 IP 기반 접근 제어 패턴

여기서 중요한 조건부 관계가 있습니다. XFF 기반 클라이언트 IP를 기록만 하는 경우와 보안 결정에 사용하는 경우의 위험도가 다릅니다. 후자, 즉 허용 IP 목록 우회나 IP 기반 차단 회피로 바로 이어질 수 있는 경로가 우선 점검 대상입니다. 반대로 이 미들웨어를 쓰지 않거나, 클라이언트 IP를 인증·인가 수단이 아니라 참고 정보로만 쓰는 서비스는 실질 위험이 크게 낮습니다.

또 하나의 조건은 서비스 노출 형태입니다. 외부에 직접 노출되는 서비스는 공격자가 XFF 헤더를 임의로 제어할 수 있는 상황에 놓이지만, 항상 신뢰할 수 있는 리버스 프록시를 통해서만 트래픽을 받는 구성은 조건이 달라집니다. 다만 '항상 프록시를 거친다'는 전제가 실제로 성립하는지(헬스체크, 우회 경로, 내부 리스너 등)까지 확인해야 영향 범위를 좁힐 수 있습니다.

실제 위험 등급에 대해 단정하지 못할 부분도 있습니다. 이번 증거에는 CVSS 같은 벤더 심각도 수치가 포함되어 있지 않고, CISA KEV 등재 여부도 확인되지 않았습니다. 따라서 우선순위는 '심각도 점수'가 아니라 자신의 환경에서 IP 기반 보안 결정이 이 미들웨어 결과값에 얼마나 의존하는지로 판단하는 편이 현실적입니다.

기술적 분석

동작을 순서대로 추적하면 다음과 같습니다.

• 요청이 들어오면 미들웨어는 XFF 헤더에서 클라이언트 IP를 추출합니다.
• 어드바이저리의 PoC는 r.Use(middleware.ClientIPFromXFF("198.51.100.0/24"))처럼 신뢰 CIDR을 인자로 전달해 미들웨어를 적용합니다.
• 추출된 값이 핸들러 안에서 허용 IP(10.0.0.7)와 비교되어 접근을 허용 또는 거부하는 구성이 PoC의 뼈대입니다.
• 문제는 이 비교에 이르기까지, 실제 연결 소스 주소인 RemoteAddr가 XFF 체인의 오른쪽 홉으로 취급되지 않는다는 점이었습니다. 그 결과 신뢰 판단의 '입구'를 검증하지 못한 채 헤더 값이 인가 판단에 도달할 수 있었습니다.

수정 커밋 7f9b744는 이 순서를 바로잡습니다. RemoteAddr를 XFF 체인의 가장 오른쪽 홉, 즉 '가장 마지막에 요청을 넘겨준 실제 상대'로 다루도록 바뀐 것입니다. 신뢰 CIDR이 실제로 연결을 맺은 상대와 일치하는지를 체인의 끝에서 확인하게 되므로, 임의로 덧붙인 XFF 항목이 단독으로 신뢰 판단을 통과하기 어려워집니다.

커밋 문서에는 주소 정규화 동작도 명시되어 있습니다. v4 매핑 IPv6(::ffff:a.b.c.d)은 일반 IPv4로 접고, IPv6 zone은 접두사(prefix) 검사 전에 제거합니다. 즉 신뢰 CIDR 매칭이 시작되기 전에 주소 형태를 정리한다는 의미이며, CIDR을 설계할 때 IPv6 표현까지 고려해야 한다는 실무적 시사점을 줍니다. 로컬에서 리버스 프록시를 두는 구성의 예시로 커밋 문서에 등장하는 r.Use(middleware.ClientIPFromXFF("127.0.0.1/32", "::1/128")) 같은 명시적 신뢰 주소 지정도 같은 맥락에서 읽어볼 만합니다.

공개 PoC·익스플로잇 분석

이번 어드바이저리에는 재현 절차가 포함된 공개 PoC가 확인됩니다. 인용된 재현 코드는 go mod init 후 go get github.com/go-chi/chi/v5@167e1e3bd039d060696b99c8da4e876ae04f42c1로 특정 커밋을 지정해 의존성을 구성하고, main.go에 middleware.ClientIPFromXFF("198.51.100.0/24")을 적용한 뒤 allowedIP와 비교하는 구성을 담고 있습니다.

이 PoC에서 전제조건은 분명합니다. 신뢰 CIDR 인자를 둔 ClientIPFromXFF가 적용되어 있고, 그 결과값을 접근 허용 판단에 사용하는 애플리케이션이어야 합니다. 입증 범위는 '특정 구성에서 XFF 위조가 인가 우회로 이어질 수 있음'까지입니다. 반대로 PoC의 존재는 다음을 증명하지 않습니다. 실제 서비스에서의 악용, 자동화된 익스플로잇의 유포, 데이터 유출의 발생.

운영상 의미는 확인된 사실과 아직 확인되지 않은 사실을 나누어 보는 것입니다. 어드바이저리에 재현 절차가 포함된 공개 PoC가 확인된 것과 달리, 실제 야생에서의 악용(in-the-wild exploitation) 증거는 이번 조사에서 확인되지 않았고 CISA KEV 등재 여부도 확인되지 않았습니다. 따라서 현 시점의 정확한 평가는 '공격 재현 가능성이 입증된 상태'이지 '대규모 악용이 진행 중인 상태'가 아닙니다. PoC 존재와 실제 악용은 구분해서 우선순위에 반영해야 합니다.

대응 방안

즉시 단계와 구조적 단계를 나눠 보는 것을 권합니다.

즉시 확인할 것

• 사내 코드베이스에서 middleware.ClientIPFromXFF 사용 여부와 인자로 전달된 신뢰 CIDR 구성을 전수 조사합니다.
• 이 미들웨어가 산출한 클라이언트 IP가 인가·ACL 같은 보안 결정에 직접 쓰이는 경로를 우선 식별합니다. 해당 판단을 일시적으로 RemoteAddr 기반이나 신뢰 가능한 프록시 검증으로 대체하는지도 검토 대상입니다.
• XFF 값과 RemoteAddr가 불일치하는 요청의 로그를 소급 검토해 이미 발생한 우회 흔적이 있는지 살펴봅니다. 어드바이저리의 PoC 재현 코드 패턴과 일치하는지를 찾기보다, 실제 트래픽에서 XFF 위조 시도 징후를 중심으로 보는 편이 탐지로서 실질적입니다.
• 적용 가능하면 수정 커밋 7f9b744가 반영된 chi/v5 버전으로 업그레이드를 진행합니다. 단 정확한 수정 릴리스 버전 번호는 아래 한계를 참고하세요.

구조적 개선

• RemoteAddr를 XFF 체인의 오른쪽 홉으로 취급하는 수정(#1214)이 포함된 go-chi/chi 버전으로 업그레이드합니다.
• XFF는 신뢰할 수 있는 리버스 프록시에서만 설정·정규화되고, 프록시를 거치지 않은 직접 요청의 XFF 값이 무시되는 아키텍처를 유지합니다.
• 로컬호스트 프록시를 쓰는 구성에서는 127.0.0.1/32, ::1/128처럼 신뢰 주소를 명시적으로 전달하는 관행을 적용합니다.
• 클라이언트 IP 단독 의존을 줄이고, 단일 헤더 기반 접근 제어 대신 인증·인가 수단과 결합하는 방향으로 설계를 조정합니다.

우선순위를 정리하면, 'IP 기반 보안 결정에 XFF 결과값을 쓰는 경로'가 가장 앞, 그다음이 '로그·감사 기록의 정확성', 마지막으로 '참고 정보로만 사용하는 경우'의 순서가 됩니다. 같은 취약점이라도 의존도의 깊이만큼 실질 위험이 달라지기 때문입니다.

한계

• 이 취약점이 수정된 정확한 chi/v5 릴리스 버전 번호는 증거 인용문에 명시되어 있지 않습니다. v5.4.0 릴리스의 존재는 확인되지만 이 수정이 포함되었는지는 인용 문구로 확정되지 않으므로, 패치 적용 전 공식 어드바이저리에서 수정 버전을 확인해야 합니다.
• CVSS 점수 등 벤더 심각도 수치가 증거에 포함되어 있지 않아 위험 등급 산정에는 별도 확인이 필요합니다.
• 실제 야생 악용 사례나 위협 행위자 활용 정황, CISA KEV 등재 여부는 확인되지 않았습니다.
• PoC 인용문이 코드의 일부로 잘려 있어 전체 재현 스크립트는 원문 어드바이저리에서 확인해야 합니다.

참고자료

• Client IP spoofing in ClientIPFromXFF via X-Forwarded-For
• Client IP spoofing in ClientIPFromXFF via X-Forwarded-For · CVE-2026-114437
• Release v5.4.0
• Commit 7f9b744: treat RemoteAddr as the rightmost hop in ClientIPFrom* (#1214)

함께 읽으면 좋은 글

• bit-pi(Bit Flows) 1.31.0 코드에서 확인되는 웹훅 콜백 라우트와 imageHelper 기본값, 어디까지 확인됐는가
• CVE-2026-96951: 악용 감지가 공식 표기된 Windows Shell 보안 기능 우회와 CISA KEV 등재
• CVE-2026-110662: MxChat AI 챗봇 3.2.25 이하, 로그인 없이 저장되고 관리자 화면에서 실행되는 DOM XSS

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.