CVE-2026-42010

What it actually does

GnuTLS servers that enable RSA-PSK authentication may incorrectly compare a supplied PSK username/identity containing a NUL byte against stored usernames after truncation. Because C-style string handling treats NUL as a terminator, an attacker can craft an identity such as a longer malicious value with an embedded NUL so it is matched as a shorter valid username. The result is an authentication bypass for affected RSA-PSK configurations, allowing unauthorized access to services that rely on GnuTLS PSK identity matching. The issue is network-reachable, low-complexity, requires no user interaction, and primarily impacts confidentiality with some integrity impact.

Why it matters to the business

Services using affected GnuTLS RSA-PSK authentication may allow an unauthorized remote party to log in as another identity or gain access to protected application, API, or infrastructure functions. In business terms, this can lead to exposure of sensitive data, unauthorized actions under a trusted identity, and loss of confidence in systems that depend on mutual or pre-shared-key authentication. The vulnerability affects widely deployed Linux and container ecosystems including GnuTLS, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, and Red Hat hardened images, so organizations should prioritize inventory and mitigation even though it is not currently listed in CISA KEV, has no known mature public exploit, and has a low, stable EPSS score.

How an attack unfolds

An attacker first identifies a TLS service using GnuTLS with RSA-PSK cipher suites enabled. The attacker then initiates a TLS handshake and supplies a crafted PSK identity/username containing an embedded NUL character. If the vulnerable server performs identity comparison using NUL-terminated string semantics, the supplied identity is truncated during matching and may be accepted as a legitimate shorter username. Once the handshake completes under the matched identity, the attacker can access whatever service capabilities are granted to that identity, potentially reading protected data or performing limited unauthorized operations. Exploitation is configuration-dependent: systems not using GnuTLS RSA-PSK authentication are not directly exposed to this flaw.

How to fix it

Apply vendor updates for GnuTLS and downstream platform packages as soon as fixed packages are available from the operating system, container image, or appliance vendor. No exact fixed versions were provided in the input, so remediation should be tied to the relevant vendor security advisory for GnuTLS, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, and Red Hat hardened images. Where immediate patching is not possible, disable RSA-PSK cipher suites and any GnuTLS PSK authentication mode that accepts externally supplied usernames until the fix is applied. Prefer certificate-based mutual TLS or a PSK mechanism that explicitly rejects NUL bytes and validates identity length using length-aware comparisons. Rebuild and redeploy affected container images after base-image updates, and restart services so patched GnuTLS libraries are loaded. Treat configuration changes as compensating controls, not permanent substitutes for applying the corrected library.

How to confirm the fix worked

Confirm exposure by inventorying services and containers that link to GnuTLS and checking whether RSA-PSK cipher suites or PSK authentication are enabled. Verify installed GnuTLS packages against the vendor advisory for this vulnerability once fixed builds are published. For containers, confirm the running image digest was rebuilt from an updated base image, not merely that the source image tag changed. Validate the mitigation by ensuring RSA-PSK cipher suites are no longer advertised or accepted, or by testing in a controlled non-production environment that PSK identities containing embedded NUL bytes are rejected rather than matched to truncated usernames. After patching, restart or redeploy dependent services and confirm the process has loaded the updated GnuTLS shared library.

Typical attack path

1. Scan for externally or internally reachable TLS services that support RSA-PSK cipher suites or PSK-based authentication backed by GnuTLS.
2. Determine or infer valid PSK identity naming patterns from documentation, service behavior, leaked configuration, logs, or prior low-privilege access.
3. Craft a PSK username/identity containing an embedded NUL byte so that the vulnerable comparison logic truncates it to a valid identity.
4. Initiate a TLS RSA-PSK handshake using the crafted identity.
5. If the identity is incorrectly matched, complete authentication as the truncated valid user.
6. Use the resulting authenticated session to access protected data or perform actions allowed to that identity.
7. Attempt to avoid detection by relying on log truncation, where recorded usernames may show only the legitimate-looking prefix before the NUL byte.

How to detect it

Look for evidence of crafted PSK identities containing embedded NUL characters or alternate encodings of NUL in TLS termination logs, application authentication logs, GnuTLS debug logs, service audit logs, reverse proxy logs, and packet captures from affected services. Because NUL bytes can truncate or corrupt log output, compare raw network captures with application logs when investigating suspicious authentications: the log may show only a legitimate-looking username prefix while the raw handshake contains additional bytes after a NUL. Focus on successful authentications to PSK-backed identities from unusual source IPs, new geographies, unexpected service accounts, or clients that previously failed authentication. Also search for parsing anomalies, malformed identity errors, unexpected zero-length or shortened usernames, and authentication events where the recorded username differs from the raw PSK identity. If exploitation is suspected, preserve packet captures, TLS service logs, authentication audit trails, process start times, loaded GnuTLS library versions, and container image digests to determine whether the vulnerable library was active at the time of access.

• \x00
• %00
• NUL
• RSA-PSK
• PSK identity
• psk_identity
• gnutls_handshake
• GNUTLS_DEBUG_LEVEL
• TLS_RSA_PSK_WITH_AES_128_CBC_SHA
• TLS_RSA_PSK_WITH_AES_256_CBC_SHA
• TLS_RSA_PSK_WITH_AES_128_GCM_SHA256
• TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
• TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256

What your security team should do

• Prioritize discovery of internet-facing and sensitive internal services using GnuTLS with RSA-PSK or PSK authentication enabled.
• If RSA-PSK is not required, disable it immediately across servers, load balancers, appliances, and application configurations.
• Track vendor advisories for GnuTLS and downstream Red Hat products and deploy fixed packages or rebuilt container images as soon as available.
• Restart affected services after patching to ensure the vulnerable library is no longer resident in memory.
• Review recent authentication logs for unusual PSK identities, identity truncation, malformed usernames, or authentication successes from unexpected clients.
• Increase logging at TLS termination points or GnuTLS debug-capable services temporarily where operationally safe, focusing on PSK identity handling.
• Add SIEM detections for NUL-encoded identity attempts such as raw NUL, escaped \x00, URL-encoded %00, or suspicious PSK identity parsing errors.
• Limit network reachability to PSK-authenticated services using allowlists, VPNs, service mesh policy, or firewall controls.
• Rotate PSKs for high-value services if exploitation is suspected, because a successful bypass may have exposed or abused trusted service access.
• Document any accepted use of RSA-PSK and migrate to stronger, easier-to-monitor authentication patterns such as certificate-based mutual TLS where feasible.