EUVD-2026-95139
GHSA-9mfx-g534-q3pc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain man-in-the-middle network position
-
DeliveryPresent certificate with invalid extensions
-
ExploitGnuTLS 3.8.13 accepts invalid cert
-
ExecutionEstablish impersonated TLS session
-
ImpactDecrypt or modify application traffic
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V12 - Secure Communication Certificate validation
|
| Exploitation Conditions | Exploitation requires an active man-in-the-middle position so the attacker can present a malicious certificate during the TLS handshake; the specific trigger is a certificate containing invalid extensions that GnuTLS 3.8.13 accepts instead of rejecting. It applies to applications performing certificate verification via the affected GnuTLS 3.8.13 code path. Limiting factors: the attacker must be able to intercept and inject into the TLS connection (not purely remote-at-will), must supply a crafted certificate, and the target must be using the affected GnuTLS version for validation; no authentication or user interaction is needed once the MITM position exists. |
| Impact | Signals are moderately strong but partly conflicting. The input CVSS is 9.1 (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:N) and SSVC rates Technical Impact 'total' with Automatable 'yes', which argues for high priority. However, CWE-295 improper certificate validation of this type (accepting certs with invalid extensions) is a man-in-the-middle class flaw: realistic exploitation requires an active intercepting position, which normally warrants AC:H rather than the AC:L in the provided vector - this inflates the input score, so treat the raw 9.1 with caution. SSVC exploitation is 'poc' (not active exploitation), and the references do include a public gist and a GitHub PoC, so exploit code exists but there is no evidence of in-the-wild use. EPSS is not provided and the CVE is not on CISA KEV, so there is no probabilistic or active-exploitation signal to corroborate urgency. Net: a genuine, widely-reachable library flaw with public PoC, but the practical risk is gated by the need for a privileged network position, making it an important patch-soon item rather than an emergency drop-everything issue. |
| Exploit ScenarioDerived | An attacker positioned on the network path (e.g., rogue Wi-Fi, ARP/DNS spoofing, or a compromised upstream) presents a TLS certificate bearing invalid extensions that a GnuTLS 3.8.13 client should reject but instead accepts. The handshake succeeds, letting the attacker impersonate the server and decrypt or tamper with the session. Public exploit code exists (referenced gist and GitHub PoC), lowering the barrier to reproduction. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 08, 2026
Improper certificate validation in GnuTLS 3.8.13 causes applications that rely on it for TLS trust decisions to accept certificates carrying invalid extensions, letting an attacker who can intercept a connection impersonate a trusted server and read or modify the protected traffic. The assessed vector requires a man-in-the-middle position rather than remote-at-will access, but once that position exists no credentials or user interaction are needed, and the NVD score of 9.1 reflects high confidentiality and integrity impact. Publicly available exploit code exists (a GitHub PoC repository and an associated gist), CISA's SSVC evaluation marks the issue as PoC-exploited, automatable, with total technical impact, and no CISA KEV entry has been recorded at time of analysis.
RemediationAI
No vendor-released patch identified at time of analysis, and no exact fix version is provided in the available advisory data, so remediation currently depends on compensating controls while the vendor response at http://gnutls.com is monitored and the NVD record at https://nvd.nist.gov/vuln/detail/CVE-2026-95210 is tracked for an update; if and when a later GnuTLS release is published as fixed, upgrade affected hosts and container images promptly and re-verify the bundled library version. In the interim, applications that must keep running on 3.8.13 should shift certificate verification to an unaffected TLS stack (for example an alternative library or a validating reverse proxy/load balancer) - the trade-off is added architectural complexity and the need to keep the substituted stack patched. Enforce certificate or public-key pinning for high-value outbound connections so that even an accepted forged certificate cannot impersonate the pinned endpoint, accepting the operational burden of rotating pins when legitimate certificates change. Because exploitation depends on a man-in-the-middle position, tightening network controls genuinely reduces exposure: block or tightly restrict outbound TLS to approved destinations, segment management and payment paths, and deploy TLS-inspecting egress that rejects certificates with malformed or contradictory extensions, at the cost of visibility gaps for encrypted traffic you choose not to inspect. Monitoring for anomalous certificate contents at connection setup and prioritizing detection of ARP/DNS spoofing or rogue proxies is also warranted given the published PoC.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The issue is rooted in CWE-295 (Improper Certificate Validation) within GnuTLS 3.8.13, the widely deployed TLS/SSL library used by many Linux distributions and applications for certificate chain verification. In a correct implementation, X.509 certificate extensions (for example basicConstraints, keyUsage, or name constraints) are parsed and enforced during path validation, and a certificate whose extensions are malformed or contradictory must be rejected. GnuTLS 3.8.13 instead accepts such certificates, so the trust anchor logic that a client relies on to distinguish a legitimate server from an impostor can be bypassed. Because the failure occurs in the library's validation code path rather than in a specific application, any product that performs server or client certificate verification through the affected GnuTLS build inherits the weakness. EUVD records the affected version data as 'n/a n/a', and no CPE identifiers were supplied, so the scope should be confirmed against the deployment's bundled GnuTLS version rather than assumed from the advisory alone.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Certificate-validation bypass requires a MITM position to present the crafted cert, so AC:H; no auth or UI needed (PR:N/UI:N); traffic interception and tampering give C:H/I:H, A:N.
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
5DescriptionCVE.org
Improper certificate validation in gnutls v3.8.13 causes the application to accept certificates containing invalid extensions.
Executive ViewAI
GnuTLS 3.8.13, a TLS library embedded in many Linux distributions and third-party applications, can be induced to trust certificates it should reject, allowing an adversary who already sits on the network path to impersonate trusted servers and read or alter encrypted traffic. Because the flaw affects the trust layer itself, any service relying on GnuTLS for TLS verification - customer-facing endpoints, internal APIs, and partner integrations - may be exposed wherever an attacker can intercept connections. With no vendor patch yet and publicly available exploit code circulating, leadership should treat this as a material risk to data confidentiality and integrity and prioritize mitigation planning while a fix is developed.
No vendor-released patch identified at time of analysis. Interim mitigations include substituting an alternative TLS library or platform-native TLS stack where feasible, enforcing certificate pinning or explicit trust-anchor allowlists within applications that depend on GnuTLS, terminating TLS at a hardened proxy or load balancer using a different implementation, tightening network segmentation and egress filtering to limit man-in-the-middle positioning, and increasing monitoring of TLS handshakes and certificate validation failures for signs of interception.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB