OpenSSL Flaws Expose Sensitive Data via RSA K Multiple Vulnerabilities

OpenSSL has issued a broad security update for April 2026, patching seven vulnerabilities across its supported branches. Among these, CVE-2026-31790 stands out as a moderate-severity flaw. This particular vulnerability, found in RSA KEM RSASVE encapsulation, risks exposing uninitialized memory to a malicious peer.

The advisory directs users of vulnerable 3.x releases to move to OpenSSL 3.0.20, 3.3.7, 3.4.5, 3.5.6, or 3.6.2, depending on the branch in use.

OpenSSL Vulnerabilities Expose Data

The most serious issue, CVE-2026-31790, affects applications that use EVP_PKEY_encapsulate() with RSA/RSASVE to derive a shared secret from an attacker-supplied RSA public key without validating that key first.

According to OpenSSL, the underlying bug is an incorrect return-value check: RSA_public_encrypt() returns -1 on failure, but the affected code only checked whether the value was non-zero, allowing encapsulation to appear successful even when encryption had actually failed.

That logic error creates a dangerous outcome for developers using caller-supplied ciphertext buffers. If the RSA operation fails, the API can still set output lengths and return control as though a valid KEM ciphertext was generated, leaving stale or uninitialized bytes in the ciphertext buffer to be sent back to the peer.

OpenSSL warned that those bytes could contain sensitive data left over from a previous execution of the application process, turning what looks like a failed cryptographic operation into a data leakage condition.

The vendor said the flaw affects OpenSSL 3.0, 3.3, 3.4, 3.5, and 3.6, while OpenSSL 1.0.2 and 1.1.1 are not affected. FIPS modules in versions 3.6, 3.5, 3.4, 3.3, 3.1, and 3.0 are also impacted, making the issue relevant not only to general-purpose deployments but also to regulated environments that rely on validated cryptographic boundaries.

As an immediate mitigation, OpenSSL recommends calling EVP_PKEY_public_check() or EVP_PKEY_public_check_quick() before invoking EVP_PKEY_encapsulate().

That guidance matters because exploitation depends on the application accepting an invalid attacker-controlled RSA public key in the first place, which means environments that already validate imported public keys are in a much better position than applications that treat key material as implicitly trusted.

Alongside the moderate-severity RSASVE bug, OpenSSL fixed six low-severity flaws that are more situational but still important for defenders tracking library exposure.

These include an out-of-bounds read in AES-CFB-128 on x86-64 systems with AVX-512 and VAES support (CVE-2026-28386), a use-after-free in uncommon DANE client configurations (CVE-2026-28387), a delta CRL NULL dereference (CVE-2026-28388), two CMS NULL dereference issues in KeyAgreeRecipientInfo and KeyTransportRecipientInfo handling (CVE-2026-28389 and CVE-2026-28390), and a heap buffer overflow during oversized OCTET STRING hexadecimal conversion on 32-bit platforms (CVE-2026-31789).

Most of those issues primarily create denial-of-service conditions, but they highlight a recurring risk pattern in cryptographic libraries: edge-case parsing and error-handling paths often become attack surfaces when applications process untrusted certificates, CMS objects, CRLs, or public keys.

For security teams, the update is a reminder that OpenSSL exposure is not limited to TLS termination alone; mail gateways, certificate-processing tools, CMS/S/MIME services, and custom applications using modern KEM APIs may all need review.

OpenSSL said CVE-2026-31790 was reported by Simo Sorce of Red Hat on February 23, 2026, and the fix was developed by Nikola Pajkovsky.

Organizations still running affected builds should prioritize patching and add explicit public-key validation to any workflow using RSA-based encapsulation, especially where remote or user-supplied key material can reach the API surface.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.