Python str.lower()의 Unicode 버전 차이가 IDNA 2003 불일치를 만들어 CVE-2026-17084로 수정됨

이게 잘못된 데이터를 만드는 버그가 아니라 실제 취약점인 이유가 더 설명됐으면 함. 공격자가 쓸 만한 경로가 바로 보이지 않음.

작성자인데, 한 시스템 안에서 IDNA 2003 구현이 둘로 갈리면 공격 가능함. 정책이나 필터는 호스트명을 한쪽 방식으로 보고, 실제 동작 부분은 다른 방식으로 보면 됨. URL 파서 차이를 노린 SSRF와 비슷한 유형임.

결국 같은 문자열을 서로 다른 호스트명으로 해석하는 파서 차이임. 신뢰하거나 차단한 호스트명, 관리자 호스트명, SSRF 필터가 정확한 비교에 의존하니 문제가 될 수 있음. 다만 IDN을 다루는 상황이어야 해서 조건은 꽤 한정적임.

비밀번호 재설정 메일 같은 데서도 상상해볼 수 있음. 정상이라면 존재하지 않아 실패할 유니코드 도메인 변형을 공격자가 등록하면, 재설정 요청을 가로챌 여지가 생김.

정확성 버그를 보안 문제로 먼저 취급하는 이유가 있음. Chromium에서는 WebAudio의 부동소수점 flush-to-zero가 V8 힙 OOB 접근으로 이어진 사례도 있었음. 서로 다른 구현이 불일치하는 지점은 대개 공격 사슬의 출발점임.

TLS SAN의 dNSName은 사람이 읽는 유니코드 텍스트로 디코딩하면 안 된다고 봄. 와일드카드 하나를 제외하면 DNS 이름은 바이트가 같은지만 비교해야 함. Python 쪽에서 유니코드로 다루려 했던 흐름은 위험했음.

IDN을 호스팅한다면 .lower() 차이를 악용해 등록한 도메인이 있는지 찾아봐야 할 듯함.

Python에서 ß.upper()가 SS가 되는 것도 처음엔 놀랐음. 대소문자 변환 뒤 문자열 길이가 바뀔 수 있는데, Unicode SpecialCasing 규칙에 있는 동작임.

str.lower() 자체가 취약점이라는 표현은 과장 같음. 명세를 따르지 않은 IDNA 2003 구현이 취약점인 거지 lower()가 문제인 건 아님.

한 시스템에 IDNA 2003 구현이 두 개나 실제로 들어가는 경우가 흔한지 모르겠음. 그런 사례가 있어야 공격 표면도 생기는 거 아닌가.

현재 Unicode와 3.2의 차이를 모든 코드포인트에서 찾아 예외 테이블로 넣는 방식은 꽤 임시방편처럼 들림. Unicode 3.2 전용 lower 구현을 따로 두는 편이 더 자연스러워 보임.

예전에 Kelvin sign 때문에 비슷한 문제를 겪었음. 원인 찾는 데 생각보다 오래 걸리더라.