CVE-2026-27017

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-27017", "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "state": "PUBLISHED", "assignerShortName": "GitHub_M", "dateReserved": "2026-02-17T03:08:23.490Z", "datePublished": "2026-02-20T02:47:17.899Z", "dateUpdated": "2026-02-20T15:20:18.976Z"}, "containers": {"cna": {"title": "uTLS has a Chrome Parrot Fingerprint Vulnerability due to GREASE ECH Cipher Suite Mismatch", "problemTypes": [{"descriptions": [{"cweId": "CWE-1240", "lang": "en", "description": "CWE-1240: Use of a Cryptographic Primitive with a Risky Implementation", "type": "CWE"}]}], "metrics": [{"cvssV4_0": {"attackVector": "NETWORK", "attackComplexity": "HIGH", "attackRequirements": "NONE", "privilegesRequired": "NONE", "userInteraction": "PASSIVE", "vulnConfidentialityImpact": "LOW", "vulnIntegrityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "subAvailabilityImpact": "NONE", "baseScore": 2.3, "baseSeverity": "LOW", "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N", "version": "4.0"}}], "references": [{"name": "https://github.com/refraction-networking/utls/security/advisories/GHSA-7m29-f4hw-g2vx", "tags": ["x_refsource_CONFIRM"], "url": "https://github.com/refraction-networking/utls/security/advisories/GHSA-7m29-f4hw-g2vx"}], "affected": [{"vendor": "refraction-networking", "product": "utls", "versions": [{"version": ">= 1.6.0, < 1.8.1", "status": "affected"}]}], "providerMetadata": {"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M", "dateUpdated": "2026-02-20T02:47:17.899Z"}, "descriptions": [{"lang": "en", "value": "uTLS is a fork of crypto/tls, created to customize ClientHello for fingerprinting resistance while still using it for the handshake. Versions 1.6.0 through 1.8.0 contain a fingerprint mismatch with Chrome when using GREASE ECH, related to cipher suite selection. When Chrome selects the preferred cipher suite in the outer ClientHello and for ECH, it does so consistently based on hardware support\u2014for example, if it prefers AES for the outer cipher suite, it also uses AES for ECH. However, the Chrome parrot in uTLS hardcodes AES preference for outer cipher suites but selects the ECH cipher suite randomly between AES and ChaCha20. This creates a 50% chance of selecting ChaCha20 for ECH while using AES for the outer cipher suite, a combination impossible in Chrome. This issue only affects GREASE ECH; in real ECH, Chrome selects the first valid cipher suite when AES is preferred, which uTLS handles correctly. This issue has been fixed in version 1.8.1."}], "source": {"advisory": "GHSA-7m29-f4hw-g2vx", "discovery": "UNKNOWN"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"timestamp": "2026-02-20T15:20:06.758492Z", "id": "CVE-2026-27017", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-02-20T15:20:18.976Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2026-27017", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2026-02-20T15:20:06.758492Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-02-20T15:20:12.740Z"}}], "cna": {"title": "uTLS has a Chrome Parrot Fingerprint Vulnerability due to GREASE ECH Cipher Suite Mismatch", "source": {"advisory": "GHSA-7m29-f4hw-g2vx", "discovery": "UNKNOWN"}, "metrics": [{"cvssV4_0": {"version": "4.0", "baseScore": 2.3, "attackVector": "NETWORK", "baseSeverity": "LOW", "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N", "userInteraction": "PASSIVE", "attackComplexity": "HIGH", "attackRequirements": "NONE", "privilegesRequired": "NONE", "subIntegrityImpact": "NONE", "vulnIntegrityImpact": "NONE", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "LOW"}}], "affected": [{"vendor": "refraction-networking", "product": "utls", "versions": [{"status": "affected", "version": ">= 1.6.0, < 1.8.1"}]}], "references": [{"url": "https://github.com/refraction-networking/utls/security/advisories/GHSA-7m29-f4hw-g2vx", "name": "https://github.com/refraction-networking/utls/security/advisories/GHSA-7m29-f4hw-g2vx", "tags": ["x_refsource_CONFIRM"]}], "descriptions": [{"lang": "en", "value": "uTLS is a fork of crypto/tls, created to customize ClientHello for fingerprinting resistance while still using it for the handshake. Versions 1.6.0 through 1.8.0 contain a fingerprint mismatch with Chrome when using GREASE ECH, related to cipher suite selection. When Chrome selects the preferred cipher suite in the outer ClientHello and for ECH, it does so consistently based on hardware support\u2014for example, if it prefers AES for the outer cipher suite, it also uses AES for ECH. However, the Chrome parrot in uTLS hardcodes AES preference for outer cipher suites but selects the ECH cipher suite randomly between AES and ChaCha20. This creates a 50% chance of selecting ChaCha20 for ECH while using AES for the outer cipher suite, a combination impossible in Chrome. This issue only affects GREASE ECH; in real ECH, Chrome selects the first valid cipher suite when AES is preferred, which uTLS handles correctly. This issue has been fixed in version 1.8.1."}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-1240", "description": "CWE-1240: Use of a Cryptographic Primitive with a Risky Implementation"}]}], "providerMetadata": {"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M", "dateUpdated": "2026-02-20T02:47:17.899Z"}}}, "cveMetadata": {"cveId": "CVE-2026-27017", "state": "PUBLISHED", "dateUpdated": "2026-02-20T15:20:18.976Z", "dateReserved": "2026-02-17T03:08:23.490Z", "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "datePublished": "2026-02-20T02:47:17.899Z", "assignerShortName": "GitHub_M"}, "dataVersion": "5.2"}

{"affected": [{"affectedData": [{"product": "utls", "vendor": "refraction-networking", "versions": [{"status": "affected", "version": ">= 1.6.0, < 1.8.1"}]}], "source": "security-advisories@github.com"}], "configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:a:refraction-networking:utls:*:*:*:*:*:go:*:*", "matchCriteriaId": "7B5FAB0B-7ED3-4F55-906F-0A3D31B212BF", "versionEndExcluding": "1.8.1", "versionStartIncluding": "1.6.0", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "uTLS is a fork of crypto/tls, created to customize ClientHello for fingerprinting resistance while still using it for the handshake. Versions 1.6.0 through 1.8.0 contain a fingerprint mismatch with Chrome when using GREASE ECH, related to cipher suite selection. When Chrome selects the preferred cipher suite in the outer ClientHello and for ECH, it does so consistently based on hardware support\u2014for example, if it prefers AES for the outer cipher suite, it also uses AES for ECH. However, the Chrome parrot in uTLS hardcodes AES preference for outer cipher suites but selects the ECH cipher suite randomly between AES and ChaCha20. This creates a 50% chance of selecting ChaCha20 for ECH while using AES for the outer cipher suite, a combination impossible in Chrome. This issue only affects GREASE ECH; in real ECH, Chrome selects the first valid cipher suite when AES is preferred, which uTLS handles correctly. This issue has been fixed in version 1.8.1."}, {"lang": "es", "value": "uTLS es un 'fork' de crypto/tls, creado para personalizar ClientHello para que resista la identificaci\u00f3n de huellas digitales mientras se sigue utilizando para el protocolo de enlace. Las versiones 1.6.0 a 1.8.0 contienen una falta de coincidencia de huella digital con Chrome cuando se usa GREASE ECH, relacionada con la selecci\u00f3n de la suite de cifrado. Cuando Chrome selecciona la suite de cifrado preferida en el ClientHello externo y para ECH, lo hace de forma consistente bas\u00e1ndose en el soporte de hardware; por ejemplo, si prefiere AES para la suite de cifrado externa, tambi\u00e9n usa AES para ECH. Sin embargo, el 'loro' de Chrome en uTLS codifica de forma r\u00edgida la preferencia de AES para las suites de cifrado externas, pero selecciona la suite de cifrado ECH aleatoriamente entre AES y ChaCha20. Esto hace que haya un 50% de probabilidad de que se seleccione ChaCha20 para ECH mientras se usa AES para la suite de cifrado externa, una combinaci\u00f3n imposible en Chrome. Este problema solo afecta a GREASE ECH; en ECH real, Chrome selecciona la primera suite de cifrado v\u00e1lida cuando se prefiere AES, lo cual uTLS maneja correctamente. Este problema ha sido solucionado en la versi\u00f3n 1.8.1."}], "id": "CVE-2026-27017", "lastModified": "2026-06-17T10:26:32.577", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 5.3, "baseSeverity": "MEDIUM", "confidentialityImpact": "LOW", "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N", "version": "3.1"}, "exploitabilityScore": 3.9, "impactScore": 1.4, "source": "nvd@nist.gov", "type": "Primary"}], "cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "HIGH", "attackRequirements": "NONE", "attackVector": "NETWORK", "availabilityRequirement": "NOT_DEFINED", "baseScore": 2.3, "baseSeverity": "LOW", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "PASSIVE", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "LOW", "vulnIntegrityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "security-advisories@github.com", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-27017", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2026-02-20T15:20:06.758492Z", "version": "2.0.3"}}]}, "published": "2026-02-20T03:16:01.797", "references": [{"source": "security-advisories@github.com", "tags": ["Patch", "Vendor Advisory"], "url": "https://github.com/refraction-networking/utls/security/advisories/GHSA-7m29-f4hw-g2vx"}], "sourceIdentifier": "security-advisories@github.com", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-1240"}], "source": "security-advisories@github.com", "type": "Secondary"}]}

{}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "[1.6.0,1.8.1)"}}], "enrichment": {"confidence": 100.0, "confidence_source": "cna", "scores": [{"score": 100.0, "source": "cna"}]}, "original": {"product": "utls", "source": "cna", "vendor": "refraction-networking"}, "product": "utls", "vendor": "refraction-networking"}], "analysis": {"en": {"generated_at": "2026-04-17T17:31:51.544930+00:00", "value": {"mitigation_remediation": ["Upgrade the refraction-networking uTLS library to version 1.8.1 or later.", "If an upgrade is not possible, configure the library to avoid using GREASE ECH; disabling GREASE ECH removes the mismatch, restoring fingerprint consistency.", "If disabling GREASE ECH is not feasible, or a temporary solution is needed, consider using an alternative TLS library that correctly implements ECH and preserves fingerprint integrity."], "summary": {"action": "Update", "impact": "Fingerprinting"}, "threat_synthesis": {"affected_systems": "Affected products are the refraction-networking uTLS library, specifically all releases from 1.6.0 through 1.8.0. The breach impacts any application that incorporates this library to customize TLS handshakes, such as proxies, load balancers, or custom clients that target Chrome fingerprint resistance. No operating system or external components are involved; the issue is confined to the TLS implementation within the library.", "description_and_impact": "The vulnerability stems from a mismatch in cipher suite selection in the uTLS library when GREASE ECH is used with the Chrome parrot implementation. uTLS hardcodes an AES preference for the outer ClientHello but selects the ECH cipher suite randomly between AES and ChaCha20. This yields a 50% chance of sending an outer AES cipher suite paired with an inner ChaCha20 suite, a combination that Chrome will never generate. The resulting fingerprint discrepancy allows observers to distinguish traffic that uses the vulnerable uTLS version from genuine Chrome traffic, exposing the use of the library.", "risk_and_exploitability": "The CVSS score of 2.3 indicates a low severity, and the EPSS probability is below 1%, with no entry in CISA\u2019s KEV catalog. Because the flaw only reveals a fingerprinting signature, there is no direct path to compromise confidentiality, integrity, or availability, and the attack requires that the adversary observe the TLS traffic. Consequently, the risk is minimal \u2013 a user\u2011facing privacy concern rather than a critical security vulnerability. Mitigation involves applying the official fix, but alternatives are available for immediate use."}}}}, "created": "2026-02-20T09:52:45.564832+00:00", "updated": "2026-04-17T17:45:24.335525+00:00", "vendors": ["refraction-networking", "refraction-networking$PRODUCT$utls"]}