CVE-2026-42014

What it actually does

This is a use-after-free vulnerability in GnuTLS within the PKCS#11 PIN-change path. When `gnutls_pkcs11_token_set_pin` is used to change the Security Officer PIN and the old PIN is supplied as NULL for a token that does not support a protected authentication path, GnuTLS can reference memory after it has been freed. A local, low-privileged attacker who can trigger this code path may be able to crash the calling process and, depending on allocator behavior and application context, potentially cause limited information disclosure or memory corruption affecting integrity.

Why it matters to the business

Systems and applications that use GnuTLS with PKCS#11 tokens for certificate, smart card, HSM, or token management could experience crashes or unreliable token administration operations. The most likely operational consequence is denial of service for the affected application or service performing PIN management. Current public risk appears moderate: the CVSS score is 6.6, EPSS is very low and flat over 30 days, there is no known public exploit maturity, and it is not listed in CISA KEV or associated with ransomware campaigns. However, organizations relying on PKCS#11-backed authentication, signing, encryption, or certificate lifecycle workflows should still patch during normal maintenance because token-management components often run in sensitive trust paths.

How an attack unfolds

An attacker first needs local access or a way to influence a local application or administrative workflow that invokes GnuTLS PKCS#11 PIN-change functionality. The attacker targets a token that lacks a protected authentication path and causes the PIN-change operation to be invoked with a NULL old PIN while changing the Security Officer PIN. This malformed state triggers incorrect object lifetime handling inside GnuTLS, leading to a use-after-free. In practical terms, exploitation is most likely to terminate or destabilize the process using GnuTLS. More advanced exploitation would require shaping heap memory around the vulnerable call and overcoming platform mitigations such as ASLR, hardened allocators, and process sandboxing.

How to fix it

Upgrade GnuTLS to a vendor-provided fixed version as soon as available for the operating system, distribution, appliance, or embedded product in use. No exact fixed versions were provided in the input, so use the security advisory from the relevant Linux distribution, package vendor, or product supplier to identify the corrected package. Where immediate patching is not possible, reduce exposure by limiting local access to token-management utilities, restricting who can perform PKCS#11 PIN changes, disabling unnecessary PKCS#11 token administration functionality, and ensuring services that use GnuTLS run with least privilege and process isolation. Avoid workflows that pass a NULL old PIN into Security Officer PIN-change operations for tokens without protected authentication paths.

How to confirm the fix worked

Confirm that installed GnuTLS packages match the fixed versions published by the relevant vendor or distribution. Validate dynamically linked applications to ensure they are loading the patched `libgnutls` library rather than an older bundled copy. Review package inventories, container images, appliances, and statically linked applications for embedded GnuTLS copies. If source-level validation is possible, verify that the vulnerable `gnutls_pkcs11_token_set_pin` behavior has been corrected. Functional validation should include testing PKCS#11 PIN-change workflows, including tokens without protected authentication paths, and confirming the application no longer crashes when old PIN handling is invalid or absent.

Typical attack path

1. Obtain local user access or access to a local workflow that can invoke PKCS#11 token PIN management through GnuTLS.
2. Identify an application, utility, or service using GnuTLS with PKCS#11 token support.
3. Target a token configuration that does not provide a protected authentication path.
4. Trigger a Security Officer PIN-change operation where the old PIN parameter is NULL.
5. Cause GnuTLS to enter the vulnerable `gnutls_pkcs11_token_set_pin` path and access freed memory.
6. Achieve process crash, denial of service, or potentially limited memory corruption depending on runtime conditions.

How to detect it

Look for evidence of attempted or successful triggering of PKCS#11 PIN-change operations followed by crashes in applications linked against GnuTLS. Useful sources include system logs, application logs, package manager audit logs, crash dumps, core dump metadata, endpoint detection telemetry, and authentication or token-management logs. Focus on events where a GnuTLS-using process performs Security Officer PIN changes, calls PKCS#11 functions such as `C_SetPIN`, and then terminates with segmentation faults, heap corruption, aborts, or sanitizer-reported use-after-free errors. Because there is no known public exploit maturity and the vulnerability requires local or locally mediated access, detection should emphasize anomalous local token-administration activity, repeated crashes by the same user, and crash stacks referencing `gnutls_pkcs11_token_set_pin` or PKCS#11 PIN-change functions. Also review recent changes to scripts or automation that perform token PIN resets using NULL or omitted old PIN values.

• gnutls_pkcs11_token_set_pin
• C_SetPIN
• CKF_PROTECTED_AUTHENTICATION_PATH
• AddressSanitizer: heap-use-after-free
• heap-use-after-free
• libgnutls
• PKCS#11
• Security Officer PIN
• SO PIN
• segfault
• Segmentation fault
• double free or corruption
• malloc(): memory corruption
• free(): invalid pointer

What your security team should do

• Inventory systems, applications, containers, and appliances that use GnuTLS with PKCS#11, smart card, HSM, certificate-token, or hardware-backed key workflows.
• Prioritize patching systems where local users can invoke token-management functions or where GnuTLS-backed PKCS#11 operations are exposed through automation, administrative tools, or multi-user environments.
• Apply vendor security updates for GnuTLS and verify that applications are using the patched library at runtime.
• Restrict access to PKCS#11 PIN-change utilities and Security Officer token-administration functions to trusted administrators only.
• Monitor for crashes or abnormal terminations in applications linked against GnuTLS, especially around token administration activity.
• For high-assurance environments, test the vulnerable workflow in staging with sanitizers or crash monitoring to confirm remediation.
• Track vendor advisories because no exact fixed versions were provided and downstream packages may publish fixes on different schedules.