On October 21, 2026, Oracle published a security alert for CVE-2026-91403, identifying a critical vulnerability affecting Java SE and GraalVM. The vulnerability stems from the discovery of eight compromised certificate authorities (CAs) operated by eMudhra.

Following the eMudhra intermediate CA certificate compromise, browser vendors and other software providers have taken action to block the affected certificates and protect users from potential misuse.

Our analysis of the related Java vulnerability, CVE-2026-91403, highlights a similar risk for Java applications that rely on the built-in Java trust store.

Java applications require separate attention. Customers should verify their Java environments and apply the relevant security updates or mitigations where required.

What Happened with the eMudra TLS Certificates

On October 17, 2026, a security researcher reported that eight eMudhra intermediate CA private keys were compromised due to a serious weakness in their generation. The keys were generated with too little randomness, making them exceptionally easy to recover; reportedly, one key was the single digit 4. If exploited, attackers could create fraudulent certificates for websites or services they didn’t control.

For example, an attacker able to intercept traffic between an organization and a legitimate service could present a forged TLS certificate. If the connecting application trusted the compromised intermediate CA, it could accept the fraudulent certificate and establish an encrypted connection with the attacker’s server. This creates opportunities for man-in-the-middle (MITM) attacks, potentially allowing attackers to intercept sensitive information or alter data in transit.

In its October 21 statement, eMudhra explained that a flaw in a key generation procedure produced weak keys alongside the intended strong keys. The company revoked the eight intermediate certificates on October 18.

How Java is Affected

The primary concern is the trust store used by Java applications, specifically whether it continues to trust the compromised eMudhra intermediate CA certificates. Oracle’s security alert assigned the vulnerability a CVSS 3.1 score of 9.1 (Critical).

Applications using an affected Java runtime or bundled Java trust store may continue to trust these certificates unless the relevant security update or mitigation has been applied. This could expose them to risks associated with fraudulent certificates, including potential server impersonation and interception of encrypted communications.

The impact depends on the Java distribution, runtime version, trust store configuration and whether the affected certificates remain trusted.

The reason why the vulnerability scores 9.1 on the CVSS vector is due to a complete impact on Confidentiality and Integrity, combined with network access. Generally, attacks requiring that traffic is intercepted carry the access vector of an adjacent network which lowers the scoring. However, as the affected certificates have permission to also issue client certificates, this provides a path to a second mode of compromise, and the CVSS is the aggregate store. This attack path, however, is partially mitigated as the system trust store is also used to validate in this scenario.

Is This a Java Vulnerability or Is There a Wider Problem?

Importantly, this is not a java vulnerability per se. It is a vulnerability in every piece of software that carries its own trust store which is not automatically updated, but included in software bundles. The fact Oracle assigned a CVE means this is visible here, but organizations may silently carry the very same risk in other trust stores.

How Outpost24 Customers Can Patch CVE-2026-91403

Step 1: Identify Exposed Java Assets with EASM

Outpost24’s external attack surface management (EASM) continuously identifies the internet-facing assets linked to your organization. It discovers domains, subdomains and hosts, including forgotten or shadow IT assets that were never inventoried, ensuring you know exactly what could be exposed.

For vulnerabilities like Java and PHP2Shell, EASM gives you a current, outside-in view of your exposure as a starting point for remediation.

Outpost24 EASM provides detailed breakdowns for vulnerabilities like CVE-2026-91403, including what actions to take.

Step 2: Confirm and Prioritize Patching with OutscanNX

Once you’ve identified where Java runs, the next question is which assets are vulnerable to CVE-2026-91403. Outpost24’s risk-based vulnerability management tool OutscanNX delivers that visibility with both external and internal scans:

• Scan your internet-facing assets from the cloud.
• Identify Java assets that aren’t internet-facing with local scanners from inside your environment.

Both detect vulnerable Java runtimes and rank findings by risk. This ensures your team have the right information to patch the most exposed systems first, then work through the rest and verify fixes with rescans.

Furthermore, the Outpost24 TLS scanning component will alert you should any certificates issued by any of the compromised certificates be detected when your estate is scanned for vulnerabilities.

What You Should Do Now

• Identify Java runtimes across platforms, applications, containers and scanning components, including bundled runtimes.
• Review certificate trust stores to determine whether the affected eMudhra certificates are still trusted. Verify that the affected certificates are blocked where applicable.
• Apply the appropriate security updates or mitigations recommended by the relevant Java vendor.
• Assess exposure and determine whether remediation or customer communication is necessary based on product impact. For those operating in the EU market, also consider the Cyber Resilience Act reporting requirements.

Organizations can identify and prioritize their exposure with the Outpost24 product suite. If you’re interested in seeing how our EASM and vulnerability management could work in your organization, contact us today for a demo.