Introduction
A logic error in GnuTLS's X.509 certificate chain validation silently discards permitted name constraints from subordinate Certificate Authorities, effectively widening the trust scope of certificates that should be narrowly scoped. For any system relying on GnuTLS for TLS certificate verification, this means a carefully constructed certificate chain could pass validation even when the leaf certificate's Subject Alternative Name falls outside the namespace the issuing CA was authorized to certify.
GnuTLS is a widely used secure communications library implementing the SSL, TLS, and DTLS protocols. It provides a C language API for accessing secure communications protocols and for parsing and writing X.509, PKCS #12, and related structures. The library serves as a foundational TLS backend across many Linux distributions and is integrated into a broad range of applications and services.
Technical Information
Root Cause
The vulnerability, tracked as CVE-2026-42011 and classified under CWE-295 (Improper Certificate Validation), stems from a logic error in the name_constraints_node_list_intersect() function in lib/x509/name_constraints.c. This function is responsible for computing the intersection of accumulated permitted subtrees with new ones introduced by a subordinate CA in the certificate chain.
In the vulnerable code, an early return guard existed at approximately line 803:
// VULNERABLE CODE (removed by the patch) if (gl_list_size(permitted1->items) == 0 || gl_list_size(permitted2->items) == 0) return GNUTLS_E_SUCCESS;
This check treated an empty permitted list as "nothing to do" and returned immediately with success. The problem is that in RFC 5280's Name Constraints model, an empty permitted set semantically represents the universal set, meaning all names are permitted. When a subordinate CA then narrows this with, say, permittedSubtrees = [good.com], the correct intersection of Universal ∩ {good.com} should yield {good.com}. Instead, the early return silently discarded the subordinate's constraints, leaving the universal set intact.
Attack Flow
For exploitation, the following certificate chain configuration is required:
-
A Root CA with a
nameConstraintsextension containing onlyexcludedSubtrees(for example, excludingevil.com). Crucially, this Root CA has nopermittedSubtrees, so the accumulated permitted set starts empty (universal). -
An Intermediate CA issued by the Root, with a
nameConstraintsextension containingpermittedSubtrees(for example, permitting onlygood.com). -
A Leaf certificate issued by the Intermediate CA with an arbitrary Subject Alternative Name, such as
attacker.com.
During certificate chain processing, when GnuTLS encounters the Intermediate CA's permitted constraints, it calls name_constraints_node_list_intersect() to intersect the accumulated permitted set (empty, meaning universal) with the Intermediate's permitted set (good.com). The buggy early return fires because permitted1->items has size 0, and the function returns without modifying anything. The Intermediate's restriction to good.com is silently dropped.
The result: the leaf certificate for attacker.com passes validation, even though the Intermediate CA was only supposed to issue certificates for good.com. A remote attacker in a man in the middle position could present such a certificate chain to impersonate arbitrary domains, subject only to the Root CA's excluded list.
The CVSS 3.1 vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, scoring 7.4 High. The High attack complexity reflects the requirement for an active network interception position. Both Confidentiality and Integrity impacts are rated High, while Availability is unaffected.
Patch Information
The GnuTLS project patched CVE-2026-42011 in version 3.8.13, released on April 29, 2026, through merge request !2102. The closing commit is 1dead2fa, authored by Alexander Sosedkin, with the message "x509/name_constraints: fix intersecting empty constraints".
The fix is elegant in its simplicity: a four line deletion. Here is the diff from the commit:
--- a/lib/x509/name_constraints.c +++ b/lib/x509/name_constraints.c @@ -800,10 +800,6 @@ static int name_constraints_node_list_intersect( san_flags_t types_in_p1 = 0, types_in_p2 = 0; static const unsigned char universal_ip[32] = { 0 }; - if (gl_list_size(permitted1->items) == 0 || - gl_list_size(permitted2->items) == 0) - return GNUTLS_E_SUCCESS; - /* First partition PERMITTED1 into supported and unsupported lists */ ret = name_constraints_node_list_init(&supported1); if (ret < 0) {
By removing the early return entirely, the function now always falls through into the full intersection logic, which already correctly handles the case where one of the permitted lists is empty. When permitted1 is empty (universal) and permitted2 contains entries, the intersection naturally produces the entries from permitted2, exactly as RFC 5280 Section 6.1.4 step (b) mandates.
It is worth noting the background complexity here. A parallel refactoring effort in !2083, which rewrote the name constraints system to use rbtree backed sorted lists, had already changed the data structures from the original size based arrays to gl_list based containers. The maintainer Alexander Sosedkin noted in the issue discussion that an intermediate version of !2083 had already dropped this early return, which made the final fix for CVE-2026-42011 possible as a simple deletion. Two separate backport patches were prepared: 1824-3.8.12-v1.patch for systems still on the pre rework 3.8.12 codebase, and 1824-3.8.13pre-v1.patch for the post rework code that shipped in 3.8.13.
Alongside the code fix, the commit was accompanied by expanded test coverage in tests/name-constraints-merge, specifically exercising the scenario of an empty permitted set being intersected with a non empty one, ensuring the regression cannot silently reappear.
Patch Status Across Ecosystems
| Ecosystem / Distribution | Fixed Version | Status |
|---|---|---|
| GnuTLS Upstream | 3.8.13 | Released |
| Red Hat Hardened Images | gnutls-3.8.13-1.hum1 | Released |
| Fedora 43 | 3.8.13 | Released |
| Debian 13 | No fixed version | Pending |
Organizations should prioritize patching internet facing services that use GnuTLS for certificate validation. For Debian 13 environments, administrators should monitor vendor advisories until a fixed version of the gnutls28 package becomes available.
Affected Systems and Versions
Anyone using certificate authentication in any version of GnuTLS prior to 3.8.13 is potentially affected. The vulnerability is present in the name_constraints_node_list_intersect() function in lib/x509/name_constraints.c.
The fixed version is GnuTLS 3.8.13, released April 29, 2026. All prior versions that implement X.509 name constraints processing are vulnerable when the specific certificate chain configuration (Root CA with only excluded constraints, Intermediate CA with permitted constraints) is encountered.
Vendor Security History
The GnuTLS project has a documented history of addressing security vulnerabilities in its TLS and X.509 implementation. Notable past issues include CVE-2014-3466, a memory corruption vulnerability, and CVE-2014-3566, related to the POODLE attack against SSLv3. The project maintains a public security advisory page and tracks issues through its GitLab instance. CVE-2026-42011 was reported in the issue tracker by Haruto Kimura and assigned the advisory identifier GNUTLS-SA-2026-04-29-6.
References
- NVD: CVE-2026-42011
- Red Hat CVE Page: CVE-2026-42011
- Red Hat Bugzilla: Bug 2467437
- GnuTLS GitLab Issue #1824: Name Constraints Bypass via Empty Permitted Subtrees Intersection
- GnuTLS GitLab Commit 1dead2fa: Fix intersecting empty constraints
- GnuTLS GitLab Commit 1dead2fa (diff)
- GnuTLS GitLab Merge Request !2102
- GnuTLS GitLab Merge Request !2083: rbtree list refactor
- GnuTLS Security Advisories
- RHSA-2026:13274 Security Advisory
- Fedora 43 GnuTLS 3.8.13 Security Update
- Snyk: CVE-2026-42011 in gnutls28 (Debian 13)
- GnuTLS Project Homepage
- GnuTLS Historical Security Advisories
