Security response · October 2026
Java CVE-2026-91403 and eMudhra update checklist
A major Java version is too broad to close a security update ticket. Use the product and build information below to identify the installed runtime, choose its vendor-supported response, and verify the application after replacement.
Incident guidance can change. Use the linked vendor notices for current scope and instructions.
Quick answer
For CVE-2026-91403, identify the Java distribution and full build used by each application. Apply the vendor's update or documented mitigation for the affected eMudhra certificates, then verify the running deployment. A version shown by a developer's terminal does not establish the runtime or certificate controls used by production.
What did Oracle publish
Oracle released its alert on 21 October 2026 for Oracle Java SE and GraalVM products, with a CVSS v3.1 score of 9.1. The component is JSSE, Java's secure socket extension. Oracle release announcement and risk matrix.
Oracle's remediation addresses distrust of impacted eMudhra intermediate CA certificates. That is the specific security change an operator needs to verify. Oracle advisory.
Which products and versions does the alert list
| Product | Supported versions identified as affected |
|---|---|
| Oracle Java SE | 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1 |
| Oracle GraalVM for JDK | 17.0.21, 21.0.13 |
| Oracle GraalVM Enterprise Edition | 21.3.20 |
These are affected versions from Oracle's machine-readable advisory, not a table of fixed builds. An older release absent from the supported-products table is not automatically unaffected.
For another Java distribution or a product bundling its own runtime, obtain that supplier's guidance. Do not transfer an Oracle build number to every OpenJDK distribution.
What can exploitation affect
Oracle describes unauthenticated network exploitation through the specified component's APIs, with confidentiality and integrity impacts. The advisory also discusses certain sandboxed client deployments. Its description concerns access to data available to the affected product. Oracle's detailed risk description.
Use that scope when communicating risk. The advisory does not establish that your application was attacked, which data an attacker reached, or that a public website scan can reproduce this issue.
How do you identify the update to install
Use the current advisory and your runtime supplier's package documentation. When checked on 22 October, Oracle's download page listed these JDK builds:
| JDK line | Download build displayed by Oracle |
|---|---|
| 8 | 8u511 b32 |
| 11 | 11.0.33.0.2 |
| 17 | 17.0.21.0.2 |
| 21 | 21.0.13.0.2 |
| 25 | 25.0.5.0.2 |
| 27 | 27.0.1.0.2 |
Oracle Java downloads. These are a dated download inventory. Confirm the applicable package and instructions before installation; the table is not a GraalVM patch matrix.
Notice that the Java 8 download retains the 8u511 label while displaying a build number. Record the complete package/build identity and vendor evidence. “Java 8” or an abbreviated release string is insufficient for that comparison.
Oracle's alert links a patch availability document for product-specific instructions. Use the appropriate support or distribution channel for GraalVM and other packages.
What if you cannot update immediately
Oracle's operational guidance describes two mitigation routes: installing the vendor-provided certificate blocklist, or enabling the specified revocation checks. It gives different blocklist filenames for Java 8 and later JDKs and tells operators to preserve custom entries. Follow the complete instructions for the runtime and operating system involved. Oracle eMudhra operational guidance.
Keep the mitigation as an explicit change with an owner and verification result. If a TLS-dependent integration fails afterward, investigate the certificate chain with its operator. Avoid disabling certificate validation to make the symptom disappear.
Three checks that can leave the response unfinished
| Check performed | What remains unresolved | Better evidence |
|---|---|---|
| A terminal shows a recent Java version | The application can use a bundled or separately configured runtime | Application process, runtime path, distribution, and full build |
| An updated image exists in the registry | Running tasks can still use the old image | Deployed image identity and process replacement |
| The public website has a valid TLS certificate | That does not identify a backend Java runtime's certificate controls | Runtime supplier evidence and validation of the affected application's configuration |
Apply the inventory to APIs, workers, scheduled jobs, CI services, and other Java applications that your team operates. These are places to investigate, not a claim that every Java process is exploitable in the same way.
What should you ask a managed host or software supplier
Please confirm how CVE-2026-91403 applies to [service/product]. Which Java distribution, runtime path, full package/build, and application configuration are in use? Which supplier advisory establishes the update or mitigation? When did it reach the running application, and were the previous processes replaced? Please identify any bundled runtimes, other instances, or customer actions still outstanding.
Keep the answer with a deployment record rather than only a general assurance about the provider's infrastructure.
What evidence closes the update
- Service, environment, and responsible owner:
- Java distribution, full build, and runtime path:
- Applicable supplier advisory:
- Update or documented mitigation selected:
- Package, image, or deployment identifier:
- Certificate-control change evidence:
- Replacement of old processes:
- Normal application and TLS integration checks:
- Recovery artifacts reviewed:
- Completion time and remaining investigation:
Test the application's intended integrations and keep the results. A successful deployment or a working homepage alone cannot establish every item in that record.
Questions app owners ask
Does this apply because my website uses JavaScript
JavaScript and Java are different languages. Inventory the actual backend and supporting services. A JavaScript frontend alone does not establish that the application uses an affected Java runtime; the same product can also have separate Java services.
Does a website security scan verify this patch
A public scan cannot establish the full Java build and certificate controls of every backend process. Obtain runtime and supplier evidence for the patch claim. An external scan can complement that work by examining reachable application exposures. Choose evidence for each security claim.
Cite this guide
Vibe App Scanner. “Java CVE-2026-91403 and eMudhra update checklist.” Technical sources reviewed 22 October 2026. Vendor facts, the dated download inventory, and the operational verification template are distinguished; this guide contains no VAS measurement of exposed Java applications.