A newly disclosed flaw in OpenSSL could allow attackers to access sensitive data stored in application memory.
Tracked as CVE-2026-31790, this moderate-severity vulnerability affects the handling of RSA Key Encapsulation Mechanism (KEM) RSASVE encapsulation.
OpenSSL issued the security advisory on April 7, 2026, urging users to apply patches immediately. The core issue revolves around improper failure handling in the encryption process.
When applications use RSASVE key encapsulation to establish a secret encryption key, they rely on specific functions to verify success. Unfortunately, a coding oversight causes the system to improperly validate return values.
How the Exploit Works
The flaw exists within the RSA_public_encrypt() function, which is supposed to return the number of bytes written on success or a -1 on error.
However, the affected code only checks if the return value is non-zero. If the RSA encryption fails and returns -1, the system incorrectly registers it as a non-zero success.
This false positive prompts the encapsulation process to continue. The application sets the output lengths and treats the ciphertext buffer as if a valid key was generated.
If an attacker supplies an invalid RSA public key and the application fails to validate it first, the system will process the error and leak the uninitialized contents of the buffer back to the attacker.
This stale memory could contain highly sensitive data from previous application processes.
Simo Sorce of Red Hat reported the flaw in February 2026, and Nikola Pajkovsky developed the fix. Older versions of OpenSSL, specifically 1.0.2 and 1.1.1, are entirely unaffected by this bug.
If you are running an impacted version, including the respective FIPS modules, you must upgrade to the latest patched releases.
Available security updates include:
- OpenSSL 3.0 users should upgrade to 3.0.20
- OpenSSL 3.3 users should upgrade to 3.3.7
- OpenSSL 3.4 users should upgrade to 3.4.5
- OpenSSL 3.5 users should upgrade to 3.5.6
- OpenSSL 3.6 users should upgrade to 3.6.2
Administrators who cannot immediately patch their systems can implement a code-level workaround. Developers must ensure their applications validate public keys before processing them.
Specifically, calling EVP_PKEY_public_check() or EVP_PKEY_public_check_quick() before running EVP_PKEY_encapsulate() will successfully mitigate the vulnerability and block the memory leak.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
