CVE-2026-42015

What it actually does

The flaw is an off-by-one bounds-check error in GnuTLS handling of PKCS#12 bag elements. When code appends an item to a PKCS#12 bag that already contains 32 elements, it can write one element past the end of an internal fixed-size array. That out-of-bounds write causes memory corruption and is most directly expected to trigger a crash or denial of service. Because the corruption occurs in memory-managed cryptographic parsing code, other impacts cannot be fully ruled out, but the published assessment indicates availability impact only and no confirmed confidentiality or integrity impact.

Why it matters to the business

Systems and applications that use vulnerable GnuTLS code to parse or import PKCS#12 data could be remotely crashed by a specially crafted certificate/key container, disrupting services that process client certificates, certificate bundles, or other PKCS#12 inputs. The current public risk appears moderate: CVSS is 5.3, EPSS is low at 0.00727 with no 30-day upward trend, it is not listed in CISA KEV, and there is no known mature public exploit. Organizations with internet-facing certificate enrollment, authentication, VPN, mail, proxy, or management services that accept PKCS#12 files should still treat exposure as operationally relevant because exploitation requires no authentication and no user interaction when such parsing is reachable remotely.

How an attack unfolds

An attacker identifies a service, daemon, library consumer, or workflow that accepts PKCS#12 input and processes it using a vulnerable GnuTLS version. The attacker creates a malformed PKCS#12 object containing a bag already at the implementation limit of 32 elements and structured so that appending another element triggers the faulty bounds check. The attacker then submits the crafted object through the exposed protocol or upload/import path. When the vulnerable code appends to the full bag, it writes past the internal array, corrupting adjacent memory. In the expected case, the process crashes, restarts, or becomes unstable, causing denial of service for the affected application. There is currently no public evidence of in-the-wild exploitation, named threat actor use, ransomware use, or reliable code execution.

How to fix it

Upgrade GnuTLS to a vendor-fixed version as soon as packages become available for the operating system, distribution, container base image, appliance firmware, or application bundle in use. Because no exact fixed versions were provided in the input, use the relevant vendor advisory/package changelog to identify the first version containing the fix for CVE-2026-42015 and redeploy all statically or privately bundled copies of GnuTLS, not only system packages. Rebuild containers and appliances that include vulnerable GnuTLS libraries. If immediate patching is not possible, reduce exposure by disabling or restricting remote PKCS#12 import/parsing features, requiring authentication before certificate import, limiting upload size and source networks, placing vulnerable parsing services behind access controls, and using process supervision/rate limiting to reduce denial-of-service impact.

How to confirm the fix worked

Inventory GnuTLS versions across hosts, containers, appliances, and application bundles. Validate that installed packages or embedded libraries are at a vendor-fixed release by checking package manager metadata, library version output, SBOMs, and distribution security advisories. Exercise certificate import or PKCS#12 parsing functionality in a test environment after patching to confirm normal operation and absence of crashes with malformed inputs. For internet-facing services, verify that unauthenticated users cannot submit PKCS#12 data unless that functionality is intentionally required. Confirm that old vulnerable container images and statically linked application builds have been replaced, not merely patched on the underlying host.

Typical attack path

1. Find an application or service that uses GnuTLS to parse PKCS#12 certificate/key containers.
2. Confirm the PKCS#12 parsing path is reachable remotely, such as through certificate import, client-certificate enrollment, authentication setup, or management APIs.
3. Generate a crafted PKCS#12 object with a bag containing 32 elements and conditions that cause an additional append operation.
4. Submit the malformed PKCS#12 data to the vulnerable service without needing authentication or user interaction, if the parsing endpoint is exposed.
5. Trigger the off-by-one write past the internal bag element array.
6. Cause memory corruption, typically resulting in process crash, service restart, or degraded availability.

How to detect it

Look for evidence of attempted or successful denial-of-service through PKCS#12 parsing paths. Relevant data sources include application logs for certificate import/enrollment features, reverse proxy and web server access logs for uploads or API calls involving PKCS#12/PFX/P12 files, systemd or service supervisor logs for unexpected process exits and restarts, kernel logs for segmentation faults, coredump records, container orchestrator restart events, and EDR telemetry showing crashes in processes linked against GnuTLS. Focus on unauthenticated or externally sourced requests followed immediately by crashes, SIGSEGV/SIGABRT events, coredumps, or restart loops. Search for repeated uploads of .p12, .pfx, or application/x-pkcs12 content from the same source; malformed certificate import errors; and crash backtraces referencing GnuTLS PKCS#12 parsing routines. There are no currently known threat actors, campaigns, or public exploit-specific network signatures for this vulnerability, so detection should be behavior- and artifact-based rather than relying on a single payload signature.

• .p12
• .pfx
• application/x-pkcs12
• application/pkcs12
• PKCS#12
• p12
• pfx
• gnutls_pkcs12
• gnutls_pkcs12_bag
• gnutls_pkcs12_bag_set_data
• gnutls_pkcs12_import
• gnutls_x509_privkey_import_pkcs12
• Segmentation fault
• SIGSEGV
• SIGABRT
• core dumped
• coredump
• systemd-coredump
• segfault
• double free or corruption
• malloc(): corrupted top size
• corrupted size vs. prev_size

What your security team should do

• Identify externally reachable services and applications that accept PKCS#12 files or certificate/key bundle imports and determine whether they use GnuTLS.
• Prioritize patching internet-facing, unauthenticated, or high-availability services that process PKCS#12 data.
• Track vendor advisories for the exact fixed GnuTLS package versions used by each operating system, container image, appliance, and application distribution.
• Rebuild and redeploy containers and applications that bundle GnuTLS, including statically linked or vendored copies.
• Apply compensating controls where patching is delayed: restrict certificate import endpoints, require authentication, limit source IP ranges, and add upload/request rate limits.
• Monitor for crashes or repeated malformed PKCS#12 submissions, especially on TLS, certificate enrollment, VPN, mail, proxy, and management services.
• Because EPSS is low, flat, not KEV-listed, and exploit maturity is currently none, handle through normal vulnerability management unless local exposure includes unauthenticated remote PKCS#12 parsing on critical services.