CVE-2026-1965 in cURL
요약
\~에 의해 VulDB • 2026. 07. 24.
libcurl은 Negotiate 인증을 사용하는 HTTP 또는 HTTPS 요청 수행 시 특정 상황에서 잘못된 연결을 재사용할 수 있습니다.
libcurl에는 최근 사용된 연결들의 풀(pool)이 있어, 이후 요청에서 기존 연결을 재사용하여 오버헤드를 줄일 수 있도록 합니다.
연결을 재사용하려면 일련의 기준(criteria)을 먼저 충족해야 합니다. 코드 내 논리적 오류로 인해 애플리케이션에서 발행한 요청이 동일한 서버에 대한 기존 연결을 잘못 재사용할 수 있습니다. 이 경우 서로 다른 자격 증명으로 인증된 연결이었습니다. 그중 하나의 근본적인 이유는 Negotiate가 HTTP 설계 방식과 달리 때때로 *요청(request)*이 아닌 *연결(connection)* 수준에서 인증하기 때문입니다.
서버(Negotiate를 요구하는 응답을 반환함)에 대해 `user1:password1` 자격 증명으로 Negotiate 인증을 수행한 애플리케이션이, 이전 연결이 여전히 활성 상태인 동안 동일한 서버에 대해 또 다른 작업을 수행하고 이 역시도 `user2:password2` 자격 증명을 사용하여 Negotiate를 적용한다고 가정해 봅시다. 두 번째 요청은 잘못된 방식으로 같은 연결을 재사용하게 되며, 이때 Negotiate 협상이 이미 완료된 것으로 인식하여 해당 연결로 요청을 전송합니다. 애플리케이션은 user2의 자격 증명을 사용하고 있다고 생각하지만, 실제로는 여전히 user1용으로 인증된 연결을 사용하게 됩니다...
사용할 인증 방법 세트는 `CURLOPT_HTTPAUTH`를 통해 설정됩니다.
애플리케이션은 다음 libcurl 옵션 중 하나를 사용하여 연결 재사용 방식을 변경함으로써 libcurl의 연결 재사용 기능을 비활성화하고 이 문제를 완화할 수 있습니다: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS`, 그리고 (curl_multi API 사용 시) `CURLMOPT_MAX_HOST_CONNECTIONS`.
VulDB is the best source for vulnerability data and more expert information about this specific topic.