nimaarek/cve-2026-8932-pocPrueba de concepto que reproduce CVE-2026-8932, un fallo de coincidencia en la configuración incompleta de mTLS en la reutilización de conexiones de libcurl, con un servidor de laboratorio local y un PoC en C.
Reproducción de prueba de concepto de CVE-2026-8932, un problema de coincidencia incompleta de configuración mTLS en la reutilización de conexiones de libcurl.
CVE-2026-8932 afecta la lógica de reutilización de conexiones de libcurl cuando la configuración de TLS mutuo (mTLS) cambia entre solicitudes.
En condiciones vulnerables, libcurl puede reutilizar una conexión TLS existente aunque una opción de configuración relacionada con mTLS haya cambiado y debería haber impedido que esa conexión se reutilizara.
Esta PoC demuestra el problema cambiando la contraseña de la clave privada entre dos solicitudes mientras se utiliza el mismo certificado de cliente y la misma clave privada.
La primera solicitud utiliza la contraseña correcta:
correct-password
La segunda solicitud utiliza intencionalmente una contraseña no válida:
WRONG-PASSWORD
Si libcurl reutiliza incorrectamente la conexión TLS existente, la segunda solicitud no requiere otro handshake TLS. En consecuencia, la contraseña no válida de la clave privada nunca es necesaria para establecer una nueva conexión TLS y la solicitud tiene éxito.
Por lo tanto, la PoC demuestra la condición de reutilización de conexión asociada con CVE-2026-8932.
| Propiedad | Valor |
|---|---|
| CVE | CVE-2026-8932 |
| Componente | libcurl |
| Tipo de vulnerabilidad | Coincidencia incompleta de configuración mTLS |
| CWE | CWE-305 — Omisión de autenticación por debilidad primaria |
| Área afectada | Reutilización de conexión TLS |
| Protocolo | HTTPS / mTLS |
| Cliente | API de libcurl |
| CLI de curl | No afectado |
| Alcance de la PoC | Entorno de laboratorio local |
La vulnerabilidad es un problema de lógica/coincidencia de configuración, en lugar de una vulnerabilidad tradicional de seguridad de memoria como un desbordamiento de búfer o un use-after-free.
libcurl mantiene información de conexión y puede reutilizar una conexión existente cuando una solicitud posterior se considera compatible con la configuración de la conexión.
Para las conexiones TLS, la configuración de la conexión debe compararse cuidadosamente antes de su reutilización.
La implementación vulnerable no incluía todos los campos de configuración mTLS relevantes en la lógica de coincidencia de conexiones.
Entre las configuraciones afectadas se encuentran:
cert_type
key
key_type
key_passwd
key_blob
La configuración importante utilizada por esta PoC es:
key_passwd
La PoC establece una conexión TLS utilizando una clave privada de cliente cifrada y la contraseña correcta:
correct-password
Luego realiza otra solicitud utilizando el mismo certificado y la misma clave, pero cambia la contraseña a:
WRONG-PASSWORD
Una implementación vulnerable de coincidencia de conexiones puede seguir considerando reutilizable la conexión existente.
La prueba consta de dos solicitudes HTTP.
La primera solicitud establece la conexión TLS:
URL:
https://server.test:8443/A
Client certificate:
client.crt
Private key:
client.key
Key password:
correct-password
La conexión TLS permanece persistente porque el servidor admite HTTP keep-alive.
La segunda solicitud utiliza el mismo certificado y la misma clave privada, pero cambia la contraseña de la clave:
URL:
https://server.test:8443/B
Client certificate:
client.crt
Private key:
client.key
Key password:
WRONG-PASSWORD
Si libcurl crea una nueva conexión TLS, cargar la clave privada cifrada con la contraseña incorrecta debería fallar.
Sin embargo, si libcurl reutiliza incorrectamente la conexión existente, no se requiere un nuevo handshake TLS.
Por lo tanto, la contraseña no válida no impide que la solicitud HTTP tenga éxito.
La configuración del laboratorio consta de:
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)
La observación importante es que /A y /B deben llegar en la misma conexión 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
El directorio certs/ se mantiene intencionalmente vacío en el repositorio. Los certificados y las claves privadas deben generarse localmente.
La PoC se probó en el siguiente entorno:
OS:
Debian GNU/Linux 13 (trixie)
Architecture:
x86_64
libcurl:
8.14.1
OpenSSL:
3.5.7
GCC:
14.2.0
La instalación vulnerable de libcurl utilizada para la reproducción fue:
libcurl/8.14.1
Verifique la versión instalada:
curl --version
y:
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
Genere la clave privada del servidor:
openssl genrsa -out server.key 2048
Genere la CSR:
openssl req -new \
-key server.key \
-subj "/CN=server.test" \
-out server.csr
Cree las extensiones del certificado:
printf "subjectAltName=DNS:server.test\nextendedKeyUsage=serverAuth\n" \
> server.ext
Firme el certificado utilizando la CA de prueba:
openssl x509 -req \
-in server.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out server.crt \
-days 3650 \
-sha256 \
-extfile server.ext
Genere la clave privada del cliente:
openssl genrsa -out client.key.tmp 2048
Genere la CSR:
openssl req -new \
-key client.key.tmp \
-subj "/CN=Client-A" \
-out client.csr
Convierta la clave privada al formato PKCS#8 cifrado:
openssl pkcs8 \
-topk8 \
-in client.key.tmp \
-out client.key \
-v2 aes-256-cbc \
-passout pass:correct-password
La clave privada resultante se cifra con:
correct-password
Cree las extensiones del certificado del cliente:
printf "extendedKeyUsage=clientAuth\n" \
> client.ext
Firme el certificado del cliente:
openssl x509 -req \
-in client.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out client.crt \
-days 3650 \
-sha256 \
-extfile client.ext
En este punto, los archivos requeridos deberían existir:
certs/
├── ca.crt
├── ca.key
├── client.crt
├── client.key
├── server.crt
└── server.key
Muévase al directorio del servidor:
cd ~/cve-2026-8932-lab/server
Inicie el servidor:
python3 server.py
El servidor escucha en:
0.0.0.0:8443
Se requiere autenticación mediante certificado de cliente.
El servidor también mantiene activas las conexiones HTTP/1.1 para que libcurl pueda reutilizar la conexión TLS.
Abra otra terminal:
cd ~/cve-2026-8932-lab/poc
Compile:
gcc -Wall -Wextra -O0 -g \
poc.c \
$(pkg-config --cflags --libs libcurl) \
-o poc
Ejecute:
./poc
La PoC utiliza:
Client certificate : client.crt
Private key : client.key
Request A password : correct-password
Request B password : WRONG-PASSWORD
La evidencia más importante del lado del cliente es:
[+] 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
La solicitud luego recibe:
< HTTP/1.1 200 OK
y la PoC informa:
[!!!] B REQUEST SUCCEEDED
Esto es significativo porque /B utiliza una contraseña de clave privada intencionalmente no válida.
La observación clave no es simplemente que /B tenga éxito.
La evidencia crítica es que libcurl informa explícitamente:
Re-using existing https: connection
Por lo tanto, la segunda solicitud no necesita realizar otro handshake TLS utilizando la configuración de clave modificada.
La salida del servidor proporciona confirmación independiente de la reutilización de la conexión.
La salida relevante es:
[+] 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
La observación importante es:
/A -> Connection #2
/B -> Connection #2
Por lo tanto, ambas solicitudes HTTP se recibieron a través de la misma conexión TLS.
El servidor también informa la misma identidad de cliente:
Client-A
para ambas solicitudes.
La clave privada utilizada por la PoC está cifrada.
La primera solicitud utiliza:
correct-password
lo que permite a libcurl/OpenSSL acceder a la clave privada y establecer la conexión TLS.
La segunda solicitud cambia la configuración a:
WRONG-PASSWORD
Si tuviera que establecerse una nueva conexión TLS, libcurl necesitaría procesar de nuevo la clave privada cifrada y la contraseña incorrecta debería provocar que la operación fallara.
Sin embargo, cuando se reutiliza la conexión TLS existente, la sesión TLS ya está establecida.
No es necesaria ninguna nueva operación de autenticación de cliente para /B.
Conceptualmente:
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
Esta PoC demuestra reutilización de conexión, no reanudación de sesión TLS.
Los dos mecanismos son diferentes.
Una conexión TLS ya establecida permanece abierta y se utiliza para otra solicitud HTTP:
TLS connection #2
|
+-- GET /A
|
+-- GET /B
No se requiere un segundo handshake TLS.
Se crea una nueva conexión TCP/TLS, pero se utiliza información criptográfica de sesión de una conexión anterior para acortar el nuevo handshake TLS.
Eso no es en lo que se basa esta PoC.
La PoC comparte intencionalmente:
CURL_LOCK_DATA_CONNECT
entre los dos easy handles sin compartir:
CURL_LOCK_DATA_SSL_SESSION
Esto mantiene la demostración centrada en la reutilización de conexión.
El repositorio contiene la salida capturada de la reproducción exitosa.
La salida capturada demuestra:
/A exitosaRe-using existing https: connection/B exitosaLa salida completa de la terminal también está disponible en:
docs/poc-output.txt
La evidencia del lado del servidor demuestra que:
/A -> TLS connection #2
/B -> TLS connection #2
La salida completa del servidor está disponible en:
docs/server-output.txt
Si se realiza una prueba manual con curl antes de ejecutar la PoC, el servidor puede mostrar una conexión anterior:
TLS connection #1
Esta conexión no está relacionada con la ejecución real de la PoC.
Por ejemplo, la solicitud de validación manual:
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
puede crear la conexión #1.
La PoC real puede entonces crear la conexión #2.
Por lo tanto, la condición relevante no es el número absoluto de conexión, sino que:
/A and /B
aparezcan en la misma conexión TLS durante la ejecución de la PoC.
La corrección upstream es:
7541ae569d82fb308a5e2d94916027da4fa3ba3e
Commit:
tls: fix incomplete mTLS config in conn reuse and session cache
La corrección añade las comparaciones de configuración mTLS faltantes a la lógica de coincidencia de conexiones.
Conceptualmente, la lógica de coincidencia ahora considera valores que incluyen:
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)
El cambio importante para esta PoC es la comparación de:
key_passwd
Por lo tanto, un cambio en la contraseña de la clave privada debería impedir que la conexión existente se considere compatible para su reutilización.
La corrección upstream también introdujo cobertura de regresión para el comportamiento de coincidencia de configuración TLS.
La prueba relevante está asociada con:
test 3303
Las pruebas de regresión cubren diferencias en la configuración mTLS, incluyendo:
key_passwd
key
key_type
cert_type
Por ejemplo, las configuraciones idénticas deberían coincidir:
config A == config B
mientras que cambiar la contraseña de la clave no debería:
config A key_passwd = password-A
config B key_passwd = password-B
↓
connection match = false
Esta es la misma dimensión de configuración ejercitada por esta PoC.
/B fallaSi /B falla, primero verifique si libcurl realmente reutilizó la conexión.
La salida detallada debería contener:
Re-using existing https: connection
Si esta línea no aparece, la condición de vulnerabilidad no se ha demostrado.
/A y /B aparecen en conexiones TLS diferentesEl servidor debería mostrar:
Connection #X -> /A
Connection #X -> /B
Si en cambio ve:
Connection #X -> /A
Connection #Y -> /B
entonces la segunda solicitud creó una nueva conexión TLS y la condición prevista no se reprodujo.
Verifique que:
CURL_LOCK_DATA_CONNECT se comparte.CURLOPT_FORBID_REUSE no está habilitado.CURLOPT_FRESH_CONNECT no está habilitado.Connection: keep-alive.La clave privada del cliente debe generarse utilizando:
correct-password
La PoC luego utiliza intencionalmente:
WRONG-PASSWORD
No cambie la contraseña incluida en el comando de generación de la clave privada a menos que también se cambie el valor correspondiente de la PoC.
Este repositorio está destinado a la investigación de seguridad controlada y a la reproducción de vulnerabilidades.
La PoC está diseñada para operar contra un servidor de prueba alojado localmente:
127.0.0.1:8443
No utilice la PoC contra sistemas sin autorización.
Las claves privadas y los certificados generados deben permanecer fuera del control de versiones.
El repositorio solo debe contener:
certs/.gitkeep
en lugar de claves privadas generadas.
El diseño de la PoC, la metodología de laboratorio, la implementación y el análisis técnico fueron desarrollados por AliReza con la asistencia de OpenAI ChatGPT (GPT-5.6 Luna).
La verificación humana, la ejecución, las pruebas y la reproducción fueron realizadas por el autor del repositorio.
Este repositorio se proporciona con fines de investigación de seguridad, análisis de vulnerabilidades y educación.
Úselo solo en sistemas y entornos para los que tenga autorización explícita.