TL;DR: Oracle Java SE and GraalVM JSSE certificate trust flaws let unauthenticated network attackers compromise data, according to Upwind, with CVE-2026-91403 distrusting impacted intermediates and CVE-2026-114820 removing related roots. Certificate trust governance, not just patch timing, becomes the controlling risk when runtimes embed stale trust anchors.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Upwind's report: Oracle Java SE and GraalVM JSSE certificate trust flaws allow unauthenticated network attackers to compromise data.
Why it matters: IAM, workload, and platform teams need to see certificate trust as a governed runtime dependency, because stale trust anchors can become an exposure path even when application logic is unchanged.
Context
Certificate trust is part of the runtime trust chain, not just an implementation detail. When a Java platform accepts compromised or untrusted certificate material, network attackers can reach data without authenticating through the application’s normal access controls.
That matters for identity and workload governance because the trust model may be embedded in libraries, images, and platform defaults rather than in a visible IAM policy. Certificate lifecycle management becomes relevant whenever runtimes rely on intermediates, roots, or bundled trust stores that outlive the risk they were meant to address.
Key questions
Q: How should teams manage Java certificate trust stores in production?
A: Manage the Java certificate trust store as a controlled dependency, not an afterthought. Keep its root and intermediate CA entries minimal, review every addition, remove obsolete issuers, and distribute updates consistently across the runtime trust store used by each JVM. Separate trust for internal services from public CA trust, and trace every change to an owner and approval.
Q: Why do stale certificate roots create security risk in workloads?
A: Stale certificate roots create risk because workloads may continue trusting issuers that are no longer approved, needed, or safe. That expands the set of certificates accepted during TLS handshakes, lets revoked or deprecated CAs remain trusted, and can preserve access paths long after a rotation or migration should have closed them.
Q: How does certificate validation work in Java TLS sessions?
A: Java TLS certificate validation checks the peer certificate chain against trusted CA roots, verifies the chain is complete and not expired, and confirms the certificate name matches the requested host. The JSSE stack also enforces algorithm and path constraints where configured, so a failed trust chain or hostname check aborts the session.
Q: What should security teams do first when a certificate authority is distrusted after a compromise?
A: Security teams should first identify which browsers, operating systems, services, and internal applications still trust the affected authority, then remove or replace that trust where feasible. The immediate goal is to stop accepting fraudulent certificates while preserving access to legitimate sites that may still rely on the old chain. Users should also be told to watch for certificate warnings and verify sensitive destinations through trusted channels.
Technical breakdown
How JSSE certificate trust failures create unauthenticated access
JSSE is Java’s SSL/TLS implementation layer, so its certificate validation determines which peers a runtime will trust during network sessions. If the trust store includes compromised intermediates or roots, a client or server can accept a connection that should have been rejected. That does not require the attacker to break cryptography; it requires the trust decision itself to be wrong. In practice, the exposure sits between transport security and identity assurance, because certificate validation is doing the authentication work. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practical implication: Validate runtime trust stores as a security control, not only as an update task.
Why certificate root removal is a governance problem
Root and intermediate removal is not the same as ordinary patching. A runtime may continue to trust a certificate chain long after an issuing authority has been withdrawn, especially when trust material is bundled inside a JDK, container image, or application package. That creates a persistence window for unsafe trust, even if the underlying software version is current. For practitioners, the issue is inventory and lifecycle ownership: you need to know where trust anchors live, which workloads depend on them, and how quickly changes propagate across fleets.
Practical implication: Track trust anchors as governed assets with ownership, rotation, and decommissioning dates.
Why certificate compromise becomes data exposure, not just transport risk
When certificate trust fails, the downstream impact is often data compromise rather than a visible service outage. Attackers can intercept, impersonate, or redirect trusted sessions if the runtime accepts a malicious or stale chain. That makes certificate governance a confidentiality control as much as an availability control. The operational failure is assuming transport encryption alone is enough. In reality, encryption without valid trust can protect the channel format while still authenticating the wrong endpoint.
Practical implication: Treat trust-store hygiene as part of data protection and access assurance.
Threat narrative
Attacker objective: The attacker wants to insert themselves into trusted Java network sessions and compromise data without authenticating normally.
- Entry occurs when a network attacker reaches a Java or GraalVM service that relies on vulnerable JSSE certificate validation.
- Credential access is not required because the attacker exploits trust decisions in the TLS chain rather than stealing application credentials.
- Impact follows when the runtime accepts an unsafe certificate chain and the attacker compromises data through a trusted session.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Certificate trust is an identity control, not a purely cryptographic one. The important failure here is not broken encryption but broken trust selection inside the runtime. Once a Java platform trusts the wrong root or intermediate, the authentication decision is compromised before the application sees the session. That makes certificate lifecycle governance part of identity assurance, especially for workloads that depend on bundled trust stores.
Stale trust anchors create a hidden exposure window. A runtime can stay operational while continuing to accept certificate material that should no longer be trusted. This is a classic governance gap because ownership of the trust store, the JDK, and the deployed workload are often split across teams. The practical result is that revocation and trust-anchor removal lag behind patch deployment.
This pattern shows why workload identity depends on certificate inventory discipline. If teams cannot enumerate where roots, intermediates, and private trust bundles live, they cannot prove which services still accept unsafe chains. Workload identity attestation is only as strong as the trust material behind it. Practitioners should treat trust-anchor inventory as a security baseline, not a documentation exercise.
Certificate compromise here maps to a broader machine-identity lifecycle failure. The breach condition is not merely an outdated package, but a trust relationship that persisted beyond its safe scope. That is why certificate governance must include deprecation, removal, and validation of trust stores across build artefacts, containers, and host runtimes.
Trust-store hygiene needs the same operational seriousness as secret rotation. If a service account password is left in place, the exposure is obvious; if a root certificate remains trusted after compromise, the exposure is quieter but structurally similar. The control objective is the same: remove stale trust paths before attackers can reuse them.
From our research library:
- According to the 2023 State of Machine Identity Management report, only 47% of companies have enough staff dedicated to their PKI.
- Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Trust-anchor governance will become a standard part of workload identity reviews. Teams that only review credentials and permissions will miss a class of exposure that sits below the access layer but still determines whether a session is trusted. Certificate lifecycle controls need the same operational ownership as secrets and keys.
Certificate drift will increasingly be measured as a runtime hygiene problem. The next failure mode is not whether a service encrypts traffic, but whether it still trusts the right issuers across images, clusters, and platform images. Where trust material is distributed, a single missed update can preserve an unsafe path across many services.
Trust-store inventory is the named control gap here. If a team cannot answer which workloads still bundle the affected roots and intermediates, it cannot prove exposure has been removed. That shifts certificate governance from patch tracking to asset-level accountability.
For practitioners
- Audit Java trust stores across fleets Identify every JDK, container image, and application bundle that carries its own CA or trust-store material, then map which services depend on each one.
- Remove revoked intermediates and roots quickly Build a change process that can remove impacted certificate authorities from production runtimes without waiting for unrelated application releases.
- Separate certificate trust from code deployment Treat trust-anchor updates as a security maintenance stream with its own ownership, validation, and rollback path so certificate fixes do not depend on feature releases.
- Verify external session trust on every exposed service Test internet-facing Java and GraalVM services for acceptance of unsafe chains, especially where TLS termination, proxying, or embedded trust bundles can mask the real trust source.
Key takeaways
- This incident shows that certificate trust failures can compromise data even when the underlying Java platform is otherwise patched.
- The practical risk is scale in the trust layer, because bundled roots and intermediates can survive across runtimes, images, and deployment paths.
- The most effective control is certificate lifecycle governance that inventories trust anchors, removes revoked material quickly, and validates where trust is enforced.
Related NHI Mgmt Group resources: Guide to SPIFFE and SPIRE · Machine Identity, PKI and Certificate Lifecycle Guide · Vulnerability Management Guide · Sisense breach 2024
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Unsafe trust material in runtimes behaves like exposed identity material once attackers can abuse it. |
| NHI-07 — Long-Lived Secrets | Revoked roots and intermediates are a long-lived trust problem when they remain in deployed runtimes. | |
| Recommendation — Remove exposed trust material from runtimes and revoke any certificate paths that remain trusted after compromise. Rotate and retire trust anchors on a defined lifecycle so stale certificate material does not persist in production. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate trust material functions as an authenticator asset that must be managed across its lifecycle. |
| Recommendation — Apply authenticator management to the full certificate lifecycle, including replacement and removal of revoked trust anchors. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s lifecycle issue is ownership and decommissioning of trust material across systems. |
| Recommendation — Assign explicit ownership for trust-store updates and decommission obsolete certificate authorities from every runtime. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The attack path relies on abusing trusted certificate material to gain access to sessions and data. |
| Recommendation — Treat certificate trust abuse as credential access activity and hunt for suspicious trust-chain acceptance. | ||
Key terms
- JSSE: JSSE is Java Secure Socket Extension, the Java security framework for SSL and TLS. It provides the APIs and runtime components that handle certificate validation, key management, cipher suite negotiation, and secure socket connections inside the JVM.
- Certificate Trust Store: A certificate trust store is a repository of trusted public certificates used to validate the identity of servers, clients, or code-signing authorities. During TLS or other PKI-based checks, software compares a presented certificate chain against the store to decide whether to trust it, reject it, or require another validation step.
- Trusted Certificate Authority: A trusted certificate authority is an entity that issues digital certificates used to prove a system, website, or device identity. In PKI, its root or intermediate certificates are trusted by operating systems and browsers, allowing clients to validate certificate chains, confirm ownership of a public key, and support encrypted, authenticated communications.
- SSL Certificate Chain: An SSL certificate chain is the linked set of certificates that proves a server’s identity back to a trusted root authority. Each certificate is signed by the next issuer in the chain, allowing browsers and systems to verify trust, validate the domain, and detect tampering or misconfiguration.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect certificate trust, identity assurance, and lifecycle control across modern platforms.
Published by the NHIMG editorial team on November 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org