The patch is not the end of the check
CVE-2026-31790 affects OpenSSL RSA KEM RSASVE when a failed public encryption operation is treated as success. The fix requires the corrected library behavior and a caller that handles failure as failure. Oracle's October 2026 Critical Patch Update provides the product patch for Oracle Business Intelligence Enterprise Edition Visual Analyzer (OpenSSL) versions 8.2.0.0.0 and 26.01.0.0.0.
A deployment can look compliant while an older library remains loaded, a static binary stays in the release path, or a custom wrapper preserves the old error semantics. Verification should test the artifact that runs, not just the package declared in a manifest.
Confirm the product build
For Oracle BI, record the patch identifier and affected component versions. Confirm the installed build through Oracle's supported inventory and administration interfaces. Verify that the update reached every node in a clustered deployment and every environment that shares the production configuration.
Do not infer patch success from a title match. Oracle BI is a product name that can appear on login pages, documentation, shared portals, and unrelated services. The ZoomEye query in this report is an inventory aid, not a patch verifier.
Confirm the library behavior
For self-managed OpenSSL, establish the actual loaded version. The advisory's fixed releases are 3.6.2, 3.5.6, 3.4.5, 3.3.7, and 3.0.20. A distro backport can be valid, but it needs maintainer evidence showing that the specific fix is present.
Inspect the ciphertext buffer lifecycle in the application. On an invalid RSA public key, the operation should return an error, avoid setting a successful output length, and prevent transmission of the buffer. If the application uses the documented workaround, confirm the check runs before every affected EVP_PKEY_encapsulate() call.
Test the negative case
Build a regression test that supplies an invalid key through the real application interface. The test should assert failure at each boundary: library return, application state, output length, and outbound message. A test that only proves valid-key encryption still works does not validate the vulnerability fix.
Run the test against the production-like artifact, including container images and vendor packages. If the integration is remote, verify that the server cannot return a ciphertext buffer after the failed key check. Record the test result without including keys, plaintext, or sensitive buffer contents.
Reassess external exposure
After patching, re-run the selected discovery query and compare results with the original timestamp. ZoomEye's broad title query returned 3,127 matches. The CVE-specific filter returned zero and the application fingerprint returned zero. A later result should be interpreted with the same limits: product-title discovery does not prove vulnerability or compromise.
Use the discovery result to identify owners, then verify version, patch state, internet reachability, and data sensitivity. If a system disappears from a title query, that can reflect a change in page content or network visibility rather than remediation. Combine external evidence with internal configuration data.
Residual questions
The public sources do not establish that any particular Oracle BI system was exploited through CVE-2026-31790. They do not show which internal Oracle call path uses RSASVE or whether a deployed service ever accepted an attacker-supplied key. If those facts matter to a specific investigation, examine the application and vendor guidance directly.
The upstream advisory describes possible stale or uninitialized memory disclosure. It does not guarantee that a particular buffer contained a secret. Post-patch risk assessment should distinguish the fixed code path from unproven impact on historical data.
Closure criteria
A defensible closure record includes the affected product or dependency, the applied fix, the runtime artifact that was verified, the date, and the test result for invalid-key handling. It should also state any remaining exposure, unknown environment, or investigation limitation.
That record is more useful than a simple status change. It shows that the team addressed both the OpenSSL error path and the application behavior that made the failure observable.