curl의 CVE 발급 여부를 둘러싼 분쟁

curl은 CNA로서 직접 CVE를 발급해 왔지만, 여러 극단적 조건에서만 발생하는 인증서 호스트명 검사 버그는 CVE 대상이 아니라고 판단했으며 MITRE도 이에 동의함 점으로 시작하는 불법 DNS 호스트명, 와일드카드 인증서, 특정 TLS 백엔드가 결합되면 Curl_cert_hostcheck()가 명세와 달리 TRUE를 반환하는 버그였음 curl은 2025년 12월 8일 버그를 수정하고 단위 테스트를 추가했으나, 악용에는 주소 확인 환경을 조작할 권한이 있는 로컬 공격자까지 필요해 심각도를 LOW 미만으로 평가함 약 300억 개 인스턴스에 설치된 libcurl의 CVE는 전 세계 보안팀의 패치와 후속 업데이트를 촉발하므로, 현실적인 취약점이 아닌 이론적 문제에 CVE를 발급하면 생태계 전체에 큰 비용이 발생함 제보자의 이의 제기 이후 2026년 2월·5월·6월에 같은 사안을 반복 검토했으며, MITRE TL-Root는 6월 24일 CVE를 부여하지 않기로 최종 결정함 curl의 CNA 운영 방식 curl 프로젝트는 몇 년 전 CNA가 되어 자체 영역의 보안 문제에 CVE를 부여할지 결정하고 식별자도 직접 할당할 수 있게 됨 CNA가 된 이후 57건의 보안 취약점과 해당 CVE를 공개함 CVE 번호는 API 호출 한 번으로 빠르게 받을 수 있음 소규모 보안팀도 별도의 번거로운 절차 없이 운영 가능함 CNA가 되기 전부터 취약점 접수·관리·평가 절차를 갖추고 있어 추가 유지관리 부담은 거의 없으며, 외부 기관을 거치지 않아도 된다는 점이 달라짐 취약점과 심각도 평가 기준 모든 보고를 먼저 검토해 실제 취약점 또는 보안 문제인지 판단함 보안 문제라면 LOW, MEDIUM, HIGH, CRITICAL 가운데 하나로 등급을 정함 curl이나 libcurl이 각 사용자 환경에서 어떻게 쓰이는지 알 수 없으므로 순수한 curl 관점에서 심각도를 평가함 실제 영향을 받는 사용자는 같은 문제를 다르게 평가할 수 있음 극단적인 전제와 복잡한 단계가 모두 필요해 사용자가 현실에서 마주칠 가능성이 거의 없는 문제는 내부적으로 LOW 미만이라 부름 이런 문제에는 불필요한 보안 대응을 피하기 위해 CVE를 발급하지 않는 편이 낫다고 판단함 CVE가 생태계에 만드는 비용 libcurl은 전 세계 약 300억 개 인스턴스에 설치돼 있음 CVE가 하나 공개될 때마다 안전한 버전을 유지하려는 여러 조직의 보안팀이 대응하고, 수많은 패치와 ...