NOW Briefing
libcurl mTLS 연결 재사용 인증서 검증 누락 취약점 (CVE-2026-8932)
■ 개요
curl은 데이터를 주고받는 명령행 도구이고, libcurl(curl의 기능을 다른 프로그램이 코드로 호출해 쓸 수 있게 만든 라이브러리)은 수많은 애플리케이션·언어 런타임·임베디드 기기에 들어가 있는 사실상 표준 HTTP 통신 엔진입니다. CVE-2026-8932는 libcurl이 상호 TLS 인증(mTLS, 클라이언트와 서버가 서로 인증서로 신원을 검증하는 방식)에 쓰는 연결을 재사용할 때 발생합니다. 영향 범위는 curl 7.7부터 8.20.0까지로, 2001년 3월부터 25년 넘게 코드에 남아 있던 결함입니다.
핵심 문제는 연결 재사용(connection reuse, 한 번 맺은 TCP/TLS 연결을 다음 요청에 다시 쓰는 성능 최적화) 시 두 요청이 같은 연결을 써도 되는지 판정하는 검사가 불완전했다는 점입니다. 호스트·포트 같은 조건은 비교했지만, 클라이언트 인증서 형식과 개인키 관련 설정 일부가 비교 항목에서 빠져 있었습니다. 그 결과 인증 자격이 바뀐 요청이 이전 자격으로 인증된 연결을 그대로 물려받아, 의도와 다른 클라이언트 신원으로 서버와 통신할 수 있습니다.
인증 자격이 달라져도 연결이 공유될 수 있지만, 벤더가 매긴 보안 등급은 Low(낮음)이며 curl 명령행 도구는 영향을 받지 않습니다. 다만 이번 8.21.0 릴리스는 18개 CVE를 한 번에 패치한 curl 사상 최대 규모 보안 릴리스입니다. 이 결함은 mTLS로 여러 클라이언트 자격을 다루는 서버 간 통신·게이트웨이·SaaS 백엔드에서 인증 경계에 직접 닿는 문제입니다. 자격이 어긋난 통신은 서버 로그에 정상 연결처럼 보일 수 있어, 영향 버전을 임베드한 애플리케이션은 등급과 별개로 점검 대상에 올려야 합니다.
■ 요약
| 항목 | 내용 |
|---|---|
| CVE ID | CVE-2026-8932 (libcurl mTLS 연결 재사용 시 자격 매칭 누락) |
| CVSS 점수 | 공식 CVSS 점수 미부여, curl 보안 등급 Low(낮음) |
| 취약점 유형 | CWE-305(기본 취약점에 의한 인증 우회), mTLS 연결 재사용 시 설정 매칭 누락 |
| 영향/위험 |
• 변경된 클라이언트 인증서·개인키 설정이 무시된 채 기존 연결 재사용됨 • 의도와 다른 자격으로 mTLS 통신 가능, 인증 경계 혼선 • libcurl 임베드 애플리케이션만 해당, curl 명령행 도구 비영향 • 2001년 curl 7.7부터 25년 이상 잔존 |
| 취약 버전 | curl / libcurl 7.7 ~ 8.20.0 |
| 패치 버전 | curl 8.21.0 (2026-06-24 공개) |
■ 기술 분석
libcurl은 연결 풀에서 기존 연결을 재사용할지 판정할 때 TLS 설정을 비교하는 함수 match_ssl_primary_config()(vtls.c 내부의 연결 매칭 함수)를 사용합니다. 문제는 클라이언트 인증서 형식(cert_type), 개인키 파일(key), 키 형식(key_type), 키 암호(key_passwd), 인메모리 키 데이터(key_blob) 같은 자격 관련 필드가 이 대조 대상에 들어가 있지 않았다는 것입니다. 이 라이브러리는 비교에서 빠진 값을 항상 "같다"고 취급해, 자격이 달라도 연결을 매칭했습니다.
이 비교 누락의 근본 원인은 자료구조 배치였습니다. 위 필드들이 연결 매칭에 쓰이지 않는 ssl_config_data 구조체에만 있었기 때문에, 정작 매칭 비교에 쓰이는 ssl_primary_config 구조체에서는 참조할 수 없었습니다. 패치는 이 필드들을 ssl_primary_config로 옮기고, 매칭 함수에 비교 조건을 추가해 자격이 다른 핸들은 연결을 공유하지 못하게 막았습니다. 이 점에서 과거 CVE-2022-27782와 같은 유형의 결함입니다.
/* [패치 후] vtls.c match_ssl_primary_config() 에 비교 조건 추가 */
blobcmp(c1->key_blob, c2->key_blob) &&
curl_strequal(c1->cert_type, c2->cert_type) &&
Curl_safecmp(c1->key, c2->key) &&
curl_strequal(c1->key_type, c2->key_type) &&
!Curl_timestrcmp(c1->key_passwd, c2->key_passwd)📘 INFO
원인이 비교 누락인 만큼, 이 결함은 C 언어 메모리 오류가 아니라 설계상의 결함입니다.
따라서 메모리 보호 기법으로는 막히지 않으며, 영향 버전을 쓰는 한 코드 경로가 그대로 노출됩니다.
curl 명령행 도구는 한 번 실행에 단일 자격만 쓰므로 이 조건이 성립하지 않아 영향이 없습니다.
■ 탐지 및 점검
• 먼저 시스템과 애플리케이션이 링크한 libcurl 버전을 curl -V나 패키지 매니저로 조회해 7.7~8.20.0 범위인지 확인합니다.
• 정적·동적으로 libcurl을 번들한 사내 빌드, 컨테이너 이미지, 언어 런타임의 SBOM(소프트웨어 구성 목록)에서 curl 버전을 검색합니다.
• 영향 버전이 확인되면 하나의 멀티 핸들이나 연결 풀에서 서로 다른 클라이언트 인증서·개인키를 바꿔가며 mTLS 요청을 보내는 코드 경로가 있는지 검토합니다.
• 해당 코드 경로가 있으면 mTLS를 받는 서버 측 로그에서 동일 연결에 서로 다른 클라이언트 인증서 주체(subject)가 매핑된 이력이 있는지 점검합니다.
✅ CHECK
단일 자격만 쓰는 애플리케이션은 실질 위험이 낮습니다.
여러 테넌트(고객별로 격리된 독립 공간)·계정의 인증서를 한 프로세스에서 번갈아 사용하는 게이트웨이·프록시·멀티테넌트 백엔드를 우선 점검 대상으로 삼습니다.
■ 대응 방안
• 점검 결과 영향 범위에 해당하면 curl / libcurl을 8.21.0 이상으로 업그레이드하고, libcurl을 정적 링크한 애플리케이션은 라이브러리 교체 후 반드시 재빌드합니다.
• 즉시 업그레이드가 어려우면 인증서·키가 다른 요청을 서로 다른 핸들과 연결 풀로 분리하고, 해당 요청에 연결 재사용 비활성화 옵션(CURLOPT_FRESH_CONNECT·CURLOPT_FORBID_REUSE)을 적용해 임시 대응합니다.
• 컨테이너·배포 파이프라인의 기반 이미지(base image)를 재빌드해 이미지에 포함된 구버전 libcurl을 함께 교체합니다.
• 반대로 일반 독자나 curl 명령행 도구만 쓰는 환경은 직접 조치가 필요 없습니다. 다만 자신이 운영하는 서비스가 libcurl을 임베드하고 mTLS를 쓰는지 이번 기회에 의존성 목록으로 확인해 두는 것이 좋습니다.
💡 TIP
18개 CVE가 한 릴리스에 묶여 있으므로 개별 패치보다 8.21.0 일괄 업그레이드가 효율적입니다.
운영체제 패키지 업데이트만으로는 애플리케이션이 정적 링크한 libcurl이 갱신되지 않으니, 빌드 단계의 의존성까지 함께 올려야 합니다.
[참고 자료]
curl - incomplete mTLS config matching in conn reuse (CVE-2026-8932)
AISLE - Discovers 6 New CVEs in curl, Including the Oldest Issue Ever Reported
