nimaarek/cve-2026-8932-pocCVE-2026-8932를 재현하는 개념 증명으로, libcurl 연결 재사용에서의 불완전한 mTLS 구성 매칭 결함을 다루며, 로컬 랩 서버와 C PoC를 포함합니다.
libcurl 연결 재사용에서의 불완전한 mTLS 구성 매칭 문제인 CVE-2026-8932의 개념 증명 재현입니다.
CVE-2026-8932는 요청 간에 상호 TLS(mTLS) 구성이 변경될 때 libcurl의 연결 재사용 로직에 영향을 미칩니다.
취약한 조건에서 libcurl은 mTLS 관련 구성 옵션이 변경되어 해당 연결을 재사용하지 말았어야 함에도 불구하고 기존 TLS 연결을 재사용할 수 있습니다.
이 PoC는 동일한 클라이언트 인증서와 개인 키를 사용하면서 두 요청 사이에 개인 키 비밀번호를 변경하여 이 문제를 시연합니다.
첫 번째 요청은 올바른 비밀번호를 사용합니다:
correct-password
두 번째 요청은 의도적으로 잘못된 비밀번호를 사용합니다:
WRONG-PASSWORD
libcurl이 기존 TLS 연결을 잘못 재사용하면 두 번째 요청은 또 다른 TLS 핸드셰이크를 필요로 하지 않습니다. 결과적으로 잘못된 개인 키 비밀번호는 새 TLS 연결을 설정하는 데 전혀 필요하지 않게 되고 요청이 성공합니다.
따라서 이 PoC는 CVE-2026-8932와 관련된 연결 재사용 조건을 시연합니다.
| 속성 | 값 |
|---|
| CVE | CVE-2026-8932 |
| 구성 요소 | libcurl |
| 취약점 유형 | 불완전한 mTLS 구성 매칭 |
| CWE | CWE-305 — 기본 취약점을 통한 인증 우회 |
| 영향 영역 | TLS 연결 재사용 |
| 프로토콜 | HTTPS / mTLS |
| 클라이언트 | libcurl API |
| curl CLI | 영향 없음 |
| PoC 범위 | 로컬 실험실 환경 |
이 취약점은 버퍼 오버플로나 use-after-free와 같은 전통적인 메모리 안전성 취약점이 아니라 로직/구성 매칭 문제입니다.
libcurl은 연결 정보를 유지하며, 후속 요청이 연결의 구성과 호환된다고 간주될 때 기존 연결을 재사용할 수 있습니다.
따라서 TLS 연결의 경우 재사용 전에 연결 구성을 신중하게 비교해야 합니다.
취약한 구현은 연결 매칭 로직에 모든 관련 mTLS 구성 필드를 포함하지 않았습니다.
영향을 받는 설정에는 다음이 포함됩니다:
cert_type
key
key_type
key_passwd
key_blob
이 PoC에서 사용하는 중요한 설정은 다음과 같습니다:
key_passwd
이 PoC는 암호화된 클라이언트 개인 키와 올바른 비밀번호를 사용하여 TLS 연결을 설정합니다:
correct-password
그런 다음 동일한 인증서와 키를 사용하지만 비밀번호를 다음과 같이 변경하여 또 다른 요청을 수행합니다:
WRONG-PASSWORD
취약한 연결 매칭 구현은 기존 연결을 여전히 재사용 가능하다고 간주할 수 있습니다.
테스트는 두 개의 HTTP 요청으로 구성됩니다.
첫 번째 요청이 TLS 연결을 설정합니다:
URL:
https://server.test:8443/A
Client certificate:
client.crt
Private key:
client.key
Key password:
correct-password
서버가 HTTP keep-alive를 지원하므로 TLS 연결은 지속적으로 유지됩니다.
두 번째 요청은 동일한 인증서와 개인 키를 사용하지만 키 비밀번호를 변경합니다:
URL:
https://server.test:8443/B
Client certificate:
client.crt
Private key:
client.key
Key password:
WRONG-PASSWORD
libcurl이 새 TLS 연결을 생성하면 잘못된 비밀번호로 암호화된 개인 키를 로드하는 것이 실패해야 합니다.
그러나 libcurl이 기존 연결을 잘못 재사용하면 새로운 TLS 핸드셰이크가 필요하지 않습니다.
따라서 잘못된 비밀번호는 HTTP 요청이 성공하는 것을 막지 못합니다.
실험실 설정은 다음으로 구성됩니다:
localhost
|
v
+---------------------+
| Python mTLS Server |
| 127.0.0.1:8443 |
+----------+----------+
|
| HTTPS / TLS 1.3
|
+--------+--------+
| |
/A /B
\ /
\ /
v v
Same TLS Connection
|
v
libcurl
PoC (C)
중요한 관찰은 /A와 /B가 동일한 TLS 연결로 도착해야 한다는 것입니다.
CVE-2026-8932-PoC/
├── README.md
├── LICENSE
├── .gitignore
│
├── certs/
│ └── .gitkeep
│
├── poc/
│ └── poc.c
│
├── server/
│ └── server.py
│
└── docs/
├── CVE-2026-8932-POC.jpg
├── CVE-2026-8932-server-POC.jpg
├── poc-output.txt
└── server-output.txt
certs/ 디렉터리는 저장소에서 의도적으로 비어 있게 유지됩니다. 인증서와 개인 키는 로컬에서 생성해야 합니다.
이 PoC는 다음 환경에서 테스트되었습니다:
OS:
Debian GNU/Linux 13 (trixie)
Architecture:
x86_64
libcurl:
8.14.1
OpenSSL:
3.5.7
GCC:
14.2.0
재현에 사용된 취약한 libcurl 설치는 다음과 같습니다:
libcurl/8.14.1
설치된 버전을 확인하십시오:
curl --version
그리고:
pkg-config --modversion libcurl
mkdir -p ~/cve-2026-8932-lab/{certs,poc,server,docs}
cd ~/cve-2026-8932-lab
cd ~/cve-2026-8932-lab/certs
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes \
-key ca.key \
-sha256 \
-days 3650 \
-subj "/CN=CVE-2026-8932-CA" \
-out ca.crt
서버 개인 키를 생성합니다:
openssl genrsa -out server.key 2048
CSR을 생성합니다:
openssl req -new \
-key server.key \
-subj "/CN=server.test" \
-out server.csr
인증서 확장을 생성합니다:
printf "subjectAltName=DNS:server.test\nextendedKeyUsage=serverAuth\n" \
> server.ext
테스트 CA를 사용하여 인증서에 서명합니다:
openssl x509 -req \
-in server.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out server.crt \
-days 3650 \
-sha256 \
-extfile server.ext
클라이언트 개인 키를 생성합니다:
openssl genrsa -out client.key.tmp 2048
CSR을 생성합니다:
openssl req -new \
-key client.key.tmp \
-subj "/CN=Client-A" \
-out client.csr
개인 키를 암호화된 PKCS#8 형식으로 변환합니다:
openssl pkcs8 \
-topk8 \
-in client.key.tmp \
-out client.key \
-v2 aes-256-cbc \
-passout pass:correct-password
결과 개인 키는 다음으로 암호화됩니다:
correct-password
클라이언트 인증서 확장을 생성합니다:
printf "extendedKeyUsage=clientAuth\n" \
> client.ext
클라이언트 인증서에 서명합니다:
openssl x509 -req \
-in client.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out client.crt \
-days 3650 \
-sha256 \
-extfile client.ext
이 시점에서 필요한 파일이 존재해야 합니다:
certs/
├── ca.crt
├── ca.key
├── client.crt
├── client.key
├── server.crt
└── server.key
서버 디렉터리로 이동합니다:
cd ~/cve-2026-8932-lab/server
서버를 시작합니다:
python3 server.py
서버는 다음에서 수신 대기합니다:
0.0.0.0:8443
클라이언트 인증서 인증이 필요합니다.
또한 서버는 libcurl이 TLS 연결을 재사용할 수 있도록 HTTP/1.1 연결을 활성 상태로 유지합니다.
다른 터미널을 엽니다:
cd ~/cve-2026-8932-lab/poc
컴파일합니다:
gcc -Wall -Wextra -O0 -g \
poc.c \
$(pkg-config --cflags --libs libcurl) \
-o poc
실행합니다:
./poc
PoC는 다음을 사용합니다:
Client certificate : client.crt
Private key : client.key
Request A password : correct-password
Request B password : WRONG-PASSWORD
가장 중요한 클라이언트 측 증거는 다음과 같습니다:
[+] STEP 2: Request using modified mTLS configuration
[+] Key password = WRONG-PASSWORD
* Re-using existing https: connection with host server.test
> GET /B HTTP/1.1
그런 다음 요청은 다음을 수신합니다:
< HTTP/1.1 200 OK
그리고 PoC는 다음을 보고합니다:
[!!!] B REQUEST SUCCEEDED
/B가 의도적으로 잘못된 개인 키 비밀번호를 사용하기 때문에 이는 중요합니다.
핵심 관찰은 단순히 /B가 성공한다는 것이 아닙니다.
결정적인 증거는 libcurl이 명시적으로 다음과 같이 보고한다는 것입니다:
Re-using existing https: connection
따라서 두 번째 요청은 변경된 키 구성을 사용하여 또 다른 TLS 핸드셰이크를 수행할 필요가 없습니다.
서버 출력은 연결 재사용에 대한 독립적인 확인을 제공합니다.
관련 출력은 다음과 같습니다:
[+] TLS connection #2
Client CN : Client-A
[+] Connection #2 Client=Client-A Request=GET /A HTTP/1.1
[+] Connection #2 Client=Client-A Request=GET /B HTTP/1.1
중요한 관찰은 다음과 같습니다:
/A -> Connection #2
/B -> Connection #2
따라서 두 HTTP 요청 모두 동일한 TLS 연결을 통해 수신되었습니다.
서버는 또한 두 요청 모두에 대해 동일한 클라이언트 ID를 보고합니다:
Client-A
PoC에서 사용하는 개인 키는 암호화되어 있습니다.
첫 번째 요청은 다음을 사용합니다:
correct-password
이는 libcurl/OpenSSL이 개인 키에 접근하고 TLS 연결을 설정할 수 있게 합니다.
두 번째 요청은 구성을 다음과 같이 변경합니다:
WRONG-PASSWORD
새 TLS 연결을 설정해야 했다면 libcurl은 암호화된 개인 키를 다시 처리해야 하며 잘못된 비밀번호는 작업을 실패하게 만들어야 합니다.
그러나 기존 TLS 연결이 재사용되면 TLS 세션은 이미 설정되어 있습니다.
/B에 대해 새로운 클라이언트 인증 작업이 필요하지 않습니다.
개념적으로:
Request A
|
| correct-password
v
TLS handshake
|
v
Established TLS connection
|
+----------------------+
| |
v v
/A /B
|
WRONG-PASSWORD
|
X
No new TLS handshake
|
v
HTTP succeeds
이 PoC는 TLS 세션 재개가 아니라 연결 재사용을 시연합니다.
두 메커니즘은 다릅니다.
이미 설정된 TLS 연결이 열린 상태로 유지되며 또 다른 HTTP 요청에 사용됩니다:
TLS connection #2
|
+-- GET /A
|
+-- GET /B
두 번째 TLS 핸드셰이크가 필요하지 않습니다.
새 TCP/TLS 연결이 생성되지만, 이전 연결의 암호화 세션 정보를 사용하여 새 TLS 핸드셰이크를 단축합니다.
이 PoC가 의존하는 것은 그것이 아닙니다.
이 PoC는 의도적으로 두 easy handle 간에 다음을 공유합니다:
CURL_LOCK_DATA_CONNECT
다음은 공유하지 않습니다:
CURL_LOCK_DATA_SSL_SESSION
이렇게 하면 시연이 연결 재사용에 집중됩니다.
저장소에는 성공적인 재현에서 캡처한 출력이 포함되어 있습니다.
캡처된 출력은 다음을 보여줍니다:
/A 요청Re-using existing https: connection/B 요청전체 터미널 출력은 다음에서도 확인할 수 있습니다:
docs/poc-output.txt
서버 측 증거는 다음을 보여줍니다:
/A -> TLS connection #2
/B -> TLS connection #2
전체 서버 출력은 다음에서 확인할 수 있습니다:
docs/server-output.txt
PoC를 실행하기 전에 수동 curl 테스트를 수행하면 서버가 이전 연결을 표시할 수 있습니다:
TLS connection #1
이 연결은 실제 PoC 실행과 관련이 없습니다.
예를 들어, 수동 검증 요청:
curl \
--resolve server.test:8443:127.0.0.1 \
--cacert ~/cve-2026-8932-lab/certs/ca.crt \
--cert ~/cve-2026-8932-lab/certs/client.crt \
--key ~/cve-2026-8932-lab/certs/client.key \
--pass correct-password \
https://server.test:8443/A
는 연결 #1을 생성할 수 있습니다.
그런 다음 실제 PoC가 연결 #2를 생성할 수 있습니다.
따라서 관련 조건은 절대적인 연결 번호가 아니라 PoC 실행 중에 다음이:
/A and /B
동일한 TLS 연결에 나타나는 것입니다.
업스트림 수정은 다음과 같습니다:
7541ae569d82fb308a5e2d94916027da4fa3ba3e
커밋:
tls: fix incomplete mTLS config in conn reuse and session cache
이 수정은 누락된 mTLS 구성 비교를 연결 매칭 로직에 추가합니다.
개념적으로 매칭 로직은 이제 다음을 포함한 값을 고려합니다:
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)
이 PoC에서 중요한 변경은 다음의 비교입니다:
key_passwd
따라서 개인 키 비밀번호의 변경은 기존 연결이 재사용에 호환되는 것으로 간주되는 것을 방지해야 합니다.
업스트림 수정은 또한 TLS 구성 매칭 동작에 대한 회귀 커버리지를 도입했습니다.
관련 테스트는 다음에 연결됩니다:
test 3303
회귀 테스트는 다음을 포함한 mTLS 구성의 차이를 다룹니다:
key_passwd
key
key_type
cert_type
예를 들어, 동일한 구성은 일치해야 합니다:
config A == config B
반면 키 비밀번호를 변경하면 일치하지 않아야 합니다:
config A key_passwd = password-A
config B key_passwd = password-B
↓
connection match = false
이것은 이 PoC가 실행하는 것과 동일한 구성 차원입니다.
/B 실패/B가 실패하면 먼저 libcurl이 실제로 연결을 재사용했는지 확인하십시오.
verbose 출력에 다음이 포함되어야 합니다:
Re-using existing https: connection
이 줄이 나타나지 않으면 취약점 조건이 시연되지 않은 것입니다.
/A와 /B가 서로 다른 TLS 연결에 나타남서버는 다음을 표시해야 합니다:
Connection #X -> /A
Connection #X -> /B
대신 다음과 같이 표시되면:
Connection #X -> /A
Connection #Y -> /B
두 번째 요청이 새 TLS 연결을 생성한 것이며 의도한 조건이 재현되지 않은 것입니다.
다음을 확인하십시오:
CURL_LOCK_DATA_CONNECT가 공유됩니다.CURLOPT_FORBID_REUSE가 활성화되어 있지 않습니다.CURLOPT_FRESH_CONNECT가 활성화되어 있지 않습니다.Connection: keep-alive를 전송합니다.클라이언트 개인 키는 다음을 사용하여 생성해야 합니다:
correct-password
그런 다음 PoC는 의도적으로 다음을 사용합니다:
WRONG-PASSWORD
해당 PoC 값도 변경하지 않는 한 개인 키 생성 명령에 포함된 비밀번호를 변경하지 마십시오.
이 저장소는 통제된 보안 연구 및 취약점 재현을 위한 것입니다.
이 PoC는 로컬에서 호스팅되는 테스트 서버에 대해 작동하도록 설계되었습니다:
127.0.0.1:8443
권한 없이 시스템에 대해 이 PoC를 사용하지 마십시오.
개인 키와 생성된 인증서는 버전 관리 외부에 유지해야 합니다.
저장소에는 생성된 개인 키가 아니라 다음만 포함되어야 합니다:
certs/.gitkeep
PoC 설계, 실험실 방법론, 구현 및 기술 분석은 AliReza가 OpenAI ChatGPT(GPT-5.6 Luna)의 도움을 받아 개발했습니다.
인간 검증, 실행, 테스트 및 재현은 저장소 작성자가 수행했습니다.
이 저장소는 보안 연구, 취약점 분석 및 교육 목적으로 제공됩니다.
명시적인 권한이 있는 시스템과 환경에서만 사용하십시오.