CVE-2026-31790

What it actually does

This is an information disclosure flaw in OpenSSL’s RSA/RSASVE key encapsulation handling. When an application calls EVP_PKEY_encapsulate() with RSA/RSASVE using an attacker-supplied invalid RSA public key, the underlying RSA_public_encrypt() call can fail and return -1. The affected logic checks only for a non-zero return value, so failure can be treated as success. As a result, the encapsulation operation may return output lengths and expose the caller-provided ciphertext buffer even though no valid ciphertext was produced. That buffer may contain stale or uninitialized memory from the current or previous execution context, potentially leaking sensitive data. The issue affects OpenSSL FIPS modules in the 3.6, 3.5, 3.4, 3.3, 3.1, and 3.0 lines.

Why it matters to the business

An unauthenticated network attacker may be able to make vulnerable applications disclose memory contents if those applications accept untrusted RSA public keys and use RSA/RSASVE key encapsulation without validating the key first. The practical impact depends heavily on how the application uses OpenSSL and what data may remain in the affected buffer, but leaked material could include secrets, tokens, fragments of prior messages, cryptographic material, or other sensitive process data. The CVSS score indicates high confidentiality impact, but current public exploit maturity is listed as none, EPSS is low at 0.01202 and flat over 30 days, and it is not currently listed in CISA KEV or associated with ransomware campaigns. Organizations should still prioritize review for internet-facing or partner-facing systems that process externally supplied public keys, especially where OpenSSL FIPS modules are used.

How an attack unfolds

An attacker targets an application protocol or workflow where the peer can provide an RSA public key that the application later uses with EVP_PKEY_encapsulate() and RSA/RSASVE. The attacker supplies a malformed, invalid, or otherwise unsuitable RSA public key designed to make RSA_public_encrypt() fail during encapsulation. Because the vulnerable OpenSSL code treats any non-zero return value as success, the -1 error value can be misinterpreted as a successful encryption result. The application then sends what it believes is a valid KEM ciphertext back to the attacker. Instead, the returned ciphertext buffer may contain stale or uninitialized data already present in memory. The attacker collects repeated responses and analyzes the leaked bytes for sensitive material. Exploitation requires a vulnerable application pattern: RSA/RSASVE encapsulation, attacker-controlled public keys, and no prior EVP_PKEY_public_check() or EVP_PKEY_public_check_quick() validation.

How to fix it

Upgrade OpenSSL when vendor-fixed versions become available for the affected OpenSSL branches and FIPS modules. No exact fixed versions were provided in the input, so track the OpenSSL advisory and operating system, appliance, container, language runtime, and application vendor updates that bundle OpenSSL. As an immediate mitigation, validate RSA public keys before RSA/RSASVE encapsulation by calling EVP_PKEY_public_check() or EVP_PKEY_public_check_quick() before EVP_PKEY_encapsulate(). Reject keys that fail validation. Where feasible, avoid accepting unauthenticated or untrusted peer-supplied RSA public keys for encapsulation workflows, disable RSA/RSASVE KEM paths that are not required, and prefer safer protocol designs where public keys are authenticated and validated before use. Rebuild and redeploy statically linked applications, containers, and embedded products that include their own OpenSSL copy rather than relying on the system library.

How to confirm the fix worked

Confirm exposure by identifying applications and components linked against OpenSSL 3.0, 3.1, 3.3, 3.4, 3.5, or 3.6 FIPS modules and determining whether they call EVP_PKEY_encapsulate() with RSA/RSASVE. Source-code review should verify that EVP_PKEY_public_check() or EVP_PKEY_public_check_quick() is called successfully before encapsulation when the RSA public key can be supplied by an external peer. Binary or dependency inventory should distinguish dynamically linked OpenSSL from statically bundled copies. After remediation, verify the deployed OpenSSL package or embedded library version matches the vendor-fixed release, and run negative tests using invalid RSA public keys to confirm the application rejects the key before encapsulation and does not return a ciphertext-like buffer. Confirm that application logs show validation failure rather than successful encapsulation for malformed keys.

Typical attack path

1. Identify an application endpoint, protocol, or integration that accepts peer-supplied RSA public keys.
2. Determine whether the application uses OpenSSL EVP_PKEY_encapsulate() with RSA/RSASVE for key encapsulation.
3. Submit an invalid or malformed RSA public key intended to cause RSA_public_encrypt() to fail.
4. Trigger the encapsulation workflow and receive the application’s purported KEM ciphertext response.
5. Extract stale or uninitialized bytes from the returned ciphertext buffer.
6. Repeat requests to increase the chance of recovering useful process memory fragments.
7. Analyze recovered data for secrets, tokens, credentials, private material, or sensitive application data.

How to detect it

There are no reliable universal network or host indicators proving exploitation, because successful exploitation may look like normal application traffic carrying an invalid RSA public key and receiving a ciphertext-like response. To investigate possible prior exploitation, review application logs, API gateway logs, TLS-terminating proxy logs, and protocol-specific audit logs for endpoints that accept public keys or perform key establishment. Look for bursts of malformed RSA public keys, repeated key encapsulation failures, unusual clients repeatedly initiating key setup without completing normal workflows, and responses of consistent ciphertext length following failed or invalid key validation. Review OpenSSL error logging, if captured by the application, for RSA encryption or public-key validation errors around the same timestamps as outbound encapsulation responses. For forensic analysis, inspect application code paths and memory-safety telemetry to determine whether invalid key submissions could have reached EVP_PKEY_encapsulate() without EVP_PKEY_public_check() or EVP_PKEY_public_check_quick(). If suspected, treat any data returned by the affected endpoint during the suspicious window as potentially exposed and rotate secrets that may have been resident in the vulnerable process memory.

What your security team should do

• Inventory OpenSSL usage across applications, containers, appliances, and third-party products, prioritizing systems that use OpenSSL FIPS modules in the affected 3.x branches.
• Identify code paths that accept externally supplied RSA public keys and use EVP_PKEY_encapsulate() with RSA/RSASVE.
• Apply vendor patches as soon as fixed OpenSSL and downstream package versions are released; rebuild statically linked software and container images.
• Implement the documented workaround immediately by validating public keys with EVP_PKEY_public_check() or EVP_PKEY_public_check_quick() before encapsulation.
• Add regression tests that submit invalid RSA public keys and assert that encapsulation is not attempted and no ciphertext response is returned.
• For exposed services, add rate limiting and anomaly monitoring around public-key submission and key-establishment endpoints.
• Review recent logs for repeated malformed RSA key submissions, encapsulation failures, or unusual client behavior against key exchange endpoints.
• Coordinate with vendors for appliances, commercial software, and managed runtimes that bundle OpenSSL, because system package patching may not remediate embedded copies.