CVE-2026-3832

What it actually does

This vulnerability affects GnuTLS clients that perform OCSP certificate-status verification during TLS handshakes. A remote attacker able to influence or intercept a TLS connection can present a specially crafted OCSP response containing multiple records. Because of a logic error in how GnuTLS evaluates those multi-record OCSP responses, the client may incorrectly treat a revoked server certificate as valid. The result is a failure of certificate revocation enforcement: confidentiality may be weakened because a client could establish trust with a server certificate that should have been rejected. The flaw does not directly provide code execution, privilege escalation, or service denial, and exploitation requires a favorable network position or control of a server presenting a revoked certificate.

Why it matters to the business

Organizations relying on GnuTLS-based clients for TLS trust decisions could unknowingly connect to systems using revoked certificates, weakening protections against impersonation and man-in-the-middle attacks. This is most relevant for applications, containers, operating-system components, or platforms that use GnuTLS with OCSP verification enabled, including affected Red Hat Enterprise Linux, OpenShift Container Platform, hardened image, and GnuTLS deployments. The CVSS score and EPSS are low, there is no known KEV listing, no ransomware association, and no public exploit maturity reported, so broad emergency exploitation is unlikely; however, systems carrying sensitive traffic should still be prioritized because the flaw undermines a core trust-control mechanism.

How an attack unfolds

An attacker first needs either control of a TLS endpoint using a revoked certificate or the ability to intercept and manipulate a victim client’s TLS connection. During the TLS handshake, the attacker presents a certificate chain along with a crafted OCSP response containing multiple records arranged to trigger the GnuTLS validation logic error. If the victim application uses a vulnerable GnuTLS version and has OCSP verification enabled, the client may accept the revoked certificate instead of rejecting the connection. The attacker can then impersonate the intended service or maintain a man-in-the-middle position for that session, potentially observing or modifying traffic depending on the broader TLS and application context. Exploitation is constrained by the need for OCSP checking, a revoked certificate scenario, and a network or service position that lets the attacker supply the crafted response.

How to fix it

Upgrade GnuTLS and vendor-distributed packages to versions that include the fix as soon as they are available for the affected operating system, container image, or platform. No exact fixed versions were provided in the input, so use the applicable vendor advisories for GNU GnuTLS, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, and Red Hat hardened images to identify corrected package builds. Rebuild and redeploy containers or base images that include vulnerable GnuTLS libraries; simply patching the host may not update embedded image layers. Restart applications and services that dynamically link to GnuTLS so they load the updated library. Where immediate patching is not possible, reduce exposure by avoiding reliance on revoked or privately managed certificates, tightening certificate lifecycle controls, disabling trust in compromised certificate authorities where applicable, and monitoring high-risk outbound TLS paths. Do not disable certificate validation as a workaround.

How to confirm the fix worked

Confirm the installed GnuTLS package version against the fixed version listed in the relevant vendor advisory. On Linux systems, inventory packages using distribution-native tooling such as rpm, dnf, yum, dpkg, apt, or vulnerability scanners that can identify linked GnuTLS libraries. Validate that container images have been rebuilt from patched base images and that running workloads were redeployed after the image update. For applications, confirm whether they link to GnuTLS and whether OCSP verification is enabled. Where feasible, use a controlled TLS test server presenting a revoked certificate and crafted multi-record OCSP response to verify that patched clients reject the connection. Also verify that certificate revocation checks remain enabled and are not bypassed by application configuration.

Typical attack path

1. Identify or obtain a server certificate that has been revoked but is still usable for handshake attempts.
2. Gain control of a TLS service using that certificate or position between a target client and the intended server.
3. Craft an OCSP response containing multiple records that causes vulnerable GnuTLS clients to make the wrong revocation decision.
4. Initiate or intercept a TLS handshake with a client that uses vulnerable GnuTLS and has OCSP verification enabled.
5. Present the revoked certificate and crafted OCSP response during the handshake.
6. Rely on the client incorrectly accepting the revoked certificate, enabling service impersonation or man-in-the-middle access.

How to detect it

Retrospective detection is difficult because successful exploitation may look like a normal TLS connection after the handshake succeeds. Focus on evidence that clients connected to services presenting revoked certificates or abnormal OCSP responses. Review TLS proxy, web gateway, network sensor, EDR network telemetry, application logs, and certificate-validation logs for connections where revocation status was inconsistent, where OCSP responses contained multiple certificate-status records, or where a revoked certificate was observed but the application connection still succeeded. Inspect packet captures, if available, for TLS handshakes using OCSP stapling with unusual multi-record OCSP responses. Review certificate transparency and internal certificate-management logs for revoked certificates that were still served by production or third-party endpoints. If a suspected man-in-the-middle path exists, compare observed server certificate fingerprints from endpoint, proxy, and external vantage points for mismatches. No named threat actors, campaigns, KEV exploitation, or ransomware use were provided for this vulnerability.

What your security team should do

• Inventory systems, applications, and container images that include GnuTLS, especially Red Hat Enterprise Linux, OpenShift, hardened images, and internet-facing or sensitive client workloads.
• Prioritize patching for systems that initiate TLS connections to sensitive services, use mutual TLS, handle regulated data, or rely heavily on OCSP-based revocation checking.
• Track vendor advisories for exact fixed GnuTLS package versions and apply updates through standard OS, platform, and container-image maintenance processes.
• Rebuild and redeploy affected container images and restart long-running services so patched libraries are actually loaded.
• Review certificate revocation monitoring and ensure revoked certificates are removed from service promptly rather than relying only on client-side OCSP enforcement.
• Monitor for unusual TLS certificate errors, revoked-certificate events, unexpected certificate-chain changes, or OCSP anomalies on critical network paths.
• Because exploitation is not known to be active and EPSS is low and flat, handle as a scheduled-but-prioritized cryptographic trust fix rather than an incident unless suspicious certificate or OCSP activity is observed.