보안이슈

fast-uri 호스트 해석 취약점 2건|공격 조건과 대응

fast-uri의 이중 디코딩과 스킴 상대 IDN 정규화 불일치가 SSRF·호스트 정책 우회로 이어지는 조건과 수정 버전을 다룹니다.

fast-uri 호스트 해석 불일치를 표현한 한국어 표지
fast-uri 호스트 해석 불일치를 표현한 한국어 표지

같은 URI가 두 호스트로 갈라지는 이유

fast-uri의 CVE-2026-75899와 CVE-2026-75931은 애플리케이션이 검사한 호스트와 실제로 요청이 도달하는 호스트가 달라질 수 있은 해석 불일치 문제입니다. 두 취약점 모두 URI를 정규화하거나 기준 URI와 결합한 뒤 호스트 허용목록, 리디렉션 검증, SSRF 차단 정책을 적용하는 서비스에서 중요합니다. 수정 버전은 2.4.5, 3.1.6, 4.1.3으로 같습니다.

보안 정책은 보통 ‘문자열을 파싱해 호스트를 얻고, 허용된 주소인지 확인한 뒤 요청한다’는 순서를 가정합니다. 하지만 파서, 정규화 함수, 최종 HTTP 클라이언트가 인코딩과 국제화 호스트를 서로 다르게 해석하면 검사 시점의 호스트와 연결 시점의 호스트가 달라집니다. fast-uri 두 건은 이 간격이 중첩 퍼센트 인코딩과 스킴 상대 참조에서 생긴다는 점을 보여 줍니다.

CVE-2026-75899: 호스트 이중 디코딩

CVE-2026-75899는 normalize() 또는 resolve() 한 번의 호출 안에서 호스트 퍼센트 이스케이프가 두 차례 해석되는 문제입니다. 첫 번째 파싱에서 한 겹이 풀리고, 권한부를 다시 구성하는 과정에서 또 한 겹이 풀릴 수 있습니다. 중첩 인코딩된 호스트는 처음에는 일반 문자열처럼 보이지만 최종 결과에서 localhost 같은 실제 목적지로 바뀔 수 있습니다. 공급사 권고는 이 문제가 CVE-2026-6322 수정 뒤 생긴 불완전 수정 변형이라고 설명합니다.

영향은 fast-uri 자체가 네트워크 요청을 보내서 발생하는 것이 아닙니다. 애플리케이션이 신뢰할 수 없은 URI를 fast-uri로 정규화한 뒤, 그 결과를 SSRF 검사·리디렉션 정책·호스트 허용목록·프록시 라우팅에 사용하고, 이어서 다른 구성요소가 다시 파싱해 요청할 때 만들어집니다. 내부 루프백, 메타데이터 서비스, 관리망 주소처럼 외부 입력에서 직접 접근해서는 안 되는 목적지가 정책 뒤에서 살아날 수 있습니다.

CVE-2026-75931: 스킴 상대 참조와 IDN

CVE-2026-75931은 //host/path 형태의 스킴 상대 참조를 기준 URI와 결합할 때 국제화 도메인 정규화가 빠지는 문제입니다. 명시적 스킴이 있은 입력에서는 호스트를 ASCII 형식으로 정규화하지만, resolve()가 스킴 상대 참조에 기준 URI의 스킴을 적용하는 경로에서는 호스트를 그대로 내보낼 수 있습니다. 그 결과 resolve()가 반환한 호스트를 검사한 뒤 URI를 다시 파싱하면 다른 호스트로 해석될 수 있습니다.

이 취약점도 기존 CVE-2026-13676 수정이 스킴이 명시된 형식에만 적용된 불완전 수정 변형입니다. 호스트 정책을 유니코드 표시 이름에 적용하는지, ASCII 호환 이름에 적용하는지, 기준 URI 결합 전후 어느 시점에 적용하는지가 달라지면 허용목록과 실제 연결 대상 사이에 틈이 생깁니다. 공급사는 유효 스킴이 정해진 뒤 호스트를 정규화하고 변환할 수 없은 원시 비ASCII 호스트는 실패하도록 수정했습니다.

영향 범위

  • CVE-2026-75899: 2.4.1 이상 2.4.5 미만, 3.1.2 이상 3.1.6 미만, 4.0.0 이상 4.1.3 미만
  • CVE-2026-75931: 2.4.2 이상 2.4.5 미만, 3.1.3 이상 3.1.6 미만, 4.0.1 이상 4.1.3 미만
  • 공통 수정 버전: 2.4.5, 3.1.6, 4.1.3

두 범위는 시작 버전이 조금 다릅니다. 단순히 2.x·3.x·4.x를 영향 계열로 표시하면 과도하게 넓거나 좁은 판정이 될 수 있으므로 잠금 파일과 실제 설치 버전을 CVE별로 대조해야 합니다. 전이 의존성으로 들어온 경우에는 패키지 매니저가 어느 분기를 선택했는지와 배포 이미지가 같은 잠금 결과를 쓰는지 함께 확인합니다.

fast-uri URI 정규화에서 검사 호스트와 실제 목적지가 갈라지는 흐름과 점검 순서를 보여주는 한국어 인포그래픽
URI 입력·정규화·스킴 상대 참조·허용목록·업데이트 점검

코드와 구성 점검 순서

  1. package-lock.json, pnpm-lock.yaml, yarn.lock과 실행 이미지에서 fast-uri 버전을 확인합니다.
  2. normalize()와 resolve()에 외부 URL, 웹훅, 리디렉션, 프록시 대상, 이미지·문서 가져오기 주소가 들어가는 호출 지점을 찾습니다.
  3. 호스트 허용·차단 판단이 정규화 전인지 후인지, 최종 HTTP 클라이언트가 URI를 다시 파싱하는지 추적합니다.
  4. 스킴 상대 참조와 국제화 호스트를 허용하는 입력 면을 확인하고 불필요하면 입력 규칙에서 제한합니다.
  5. 사용 중인 주 버전에 맞춰 2.4.5, 3.1.6, 4.1.3 이상으로 업데이트합니다.
  6. 업데이트 뒤 검사 단계의 정규화된 호스트와 실제 연결 대상이 일치하는지 회귀 시험합니다.

패치 전 임시 통제

CVE-2026-75899에 대해 공급사는 호스트 구성요소에 인코딩된 퍼센트 기호(%25)가 있은 신뢰할 수 없은 URI를 normalize()나 resolve()에 넘기기 전에 거부하는 방안을 제시합니다. 이는 중첩 디코딩 경로를 줄이는 임시 통제입니다. CVE-2026-75931에는 스킴 상대 참조를 호스트 정책이나 출처 검증 전에 스킴이 있은 기준 URI와 결합하고, 그 결과를 한 번 정규화된 표현으로 검사하는 방법이 제시됩니다.

임시 통제는 입력 표현 하나만 차단하는 정규식으로 끝내기보다 최종 연결 직전의 목적지를 다시 검증하는 구조와 결합해야 합니다. DNS 해석 결과가 사설·루프백·링크 로컬 범위인지, 리디렉션마다 같은 정책을 다시 적용하는지, 프록시가 다른 파서 규칙을 쓰는지까지 확인하면 파서 불일치의 영향을 줄일 수 있습니다. 이 조치들은 패치 적용을 미루는 근거가 아니라 배포 전후의 방어 계층입니다.

업데이트 후 검증

수정된 fast-uri는 호스트를 반복 디코딩하지 않고, 기준 URI에서 유효 스킴이 결정된 뒤 스킴 상대 참조의 호스트를 정규화하며, 변환할 수 없은 원시 비ASCII 호스트를 실패 처리합니다. 회귀 시험은 정상 URI만 통과하는지 보는 데 그치지 않고, 중첩 퍼센트 인코딩·스킴 상대 참조·국제화 도메인·리디렉션 체인에서 정책 판단 호스트와 실제 연결 호스트가 같다는 것을 확인해야 합니다.

여러 서비스가 공통 URL 검증 모듈을 쓰는 조직은 한 번의 패키지 업데이트로 끝났다고 보기 쉽습니다. 서버리스 함수, 작업 큐 소비자, 이미지 프록시, 웹훅 검증기처럼 독립 배포되는 구성요소가 서로 다른 잠금 파일을 가질 수 있으므로, 외부 URL을 받아 outbound 요청으로 바꾸는 모든 경로를 자산 단위로 확인해야 합니다.

URL 정책의 설계 원칙

URL을 문자열 하나로 검사하는 대신 파싱·정규화·정책 판단·DNS 해석·연결의 각 단계에서 사용한 값을 기록하고, 최종 연결 직전에도 같은 정책을 적용하는 편이 안전합니다. 호스트 이름은 소문자·후행 점·국제화 도메인·IPv4와 IPv6 표기 차이를 하나의 규칙으로 정규화하고, 스킴과 포트도 허용된 조합만 사용합니다. 리디렉션을 허용한다면 최초 URL뿐 아니라 매 단계의 새 목적지를 다시 평가해야 합니다.

DNS 이름이 허용됐더라도 해석 결과가 루프백·사설·링크 로컬·클라우드 메타데이터 범위로 바뀌면 outbound 요청을 중단하는 통제가 필요합니다. 검사와 연결 사이에 DNS 응답이 달라지는 상황을 줄이려면 검증한 주소와 실제 연결 주소의 일치를 확인하고, 프록시·서비스 메시·HTTP 클라이언트가 자체적으로 주소를 다시 해석하는지도 점검합니다. 이러한 계층은 fast-uri 수정과 별개로 SSRF 방어의 일관성을 높입니다.

서비스 유형별 우선순위

웹훅 검증기와 URL 미리보기 서비스는 외부 입력을 즉시 outbound 요청으로 바꾸므로 우선순위가 높습니다. 이미지·문서 가져오기, PDF 변환, 링크 검사, 리디렉션 중계, OAuth 콜백 검증, 프록시 라우팅도 같은 신뢰 경계를 가질 수 있습니다. 반대로 정적이고 신뢰된 URI만 코드에 포함하는 경로는 노출 방식이 다릅니다. 패키지 존재 여부만으로 위험 등급을 정하기보다 외부 입력과 실제 요청 사이의 연결을 기준으로 분류해야 합니다.

정보 확인 기준

2026년 8월 25일 14:00 KST 회차 기준으로 fastify/fast-uri의 두 공식 GitHub 보안 권고를 확인했습니다. 영향 버전, 수정 버전, 임시 통제는 공급사 권고의 범위를 따릅니다. 실제 노출 판정은 외부 URI 입력과 최종 outbound 연결 사이의 전체 경로를 기준으로 합니다.

확인한 출처

  1. fast-uri vulnerable to server-side request forgery via repeated hostname percent-decodingfastify/fast-uri GitHub Security Advisory · 공식 자료
  2. fast-uri vulnerable to host confusion via skipped IDN canonicalization on scheme-relative referencesfastify/fast-uri GitHub Security Advisory · 공식 자료

사실관계와 수치는 연결된 자료에서 다시 확인할 수 있습니다.

독자 의견

의견을 남겨주세요

0

아직 등록된 댓글이 없습니다.

개인정보·광고·외부 연락처는 입력하지 마세요.