CVE-2026-60147: 
Amazon Corretto JDK vulnerability analysis and mitigation

CVE-2026-60147 is an improper certificate validation vulnerability in the Security component of Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition, disclosed as part of Oracle's July 2026 Critical Patch Update. The vulnerability affects Oracle Java SE versions 8u491, 8u491-perf, 11.0.31, 17.0.19, 21.0.11, 25.0.3, and 26.0.1; Oracle GraalVM for JDK versions 17.0.19 and 21.0.11; and Oracle GraalVM Enterprise Edition version 21.3.18. It was publicly disclosed on July 21, 2026, and reported to Oracle by researchers identified as "1seal" and "tonghuaroot" (Oracle CPU July 2026). The vulnerability carries a CVSS v3.1 base score of 6.5 (Medium) (Red Hat CVE).

The root cause is a dual-interpretation flaw in OpenJDK's certificate validation logic, classified as CWE-295 (Improper Certificate Validation) and CWE-284 (Improper Access Control). Specifically, DNSName.constrains compares a wildcard SAN (e.g., *.foo.com) against an exact-host exclusion (e.g., secret.foo.com) literally during path validation, returning NAME_SAME_TYPE and failing to reject the chain. Subsequently, HostnameChecker interprets the same wildcard SAN as a template and accepts secret.foo.com for *.foo.com, allowing a certificate that should be excluded to pass hostname verification (Red Hat Bugzilla). The vulnerability is exploitable over the network without authentication via multiple protocols, including through web services that supply data to the affected APIs, or through untrusted code loaded in sandboxed Java Web Start applications or applets (Oracle CPU July 2026).

Successful exploitation allows an unauthenticated remote attacker to perform unauthorized read access to a subset of protected data and unauthorized update, insert, or delete operations on data accessible to the affected Java SE or GraalVM instances. The confidentiality and integrity impacts are both rated Low, with no availability impact, meaning an attacker could bypass Java sandbox or application-level access controls to read or modify data that should be protected. This is particularly relevant for client-side deployments running sandboxed Java Web Start applications or applets that load untrusted code from the internet (Oracle CPU July 2026, Red Hat CVE).

There is no public proof-of-concept exploit and no evidence of active in-the-wild exploitation as of the time of disclosure (Red Hat CVE). The vulnerability is rated "automatable" by NVD SSVC analysis, meaning it can be exploited without user interaction at scale. The EPSS score is approximately 0.0027 (0.27%), indicating a low near-term probability of exploitation. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Reconnaissance: Identify targets running vulnerable Java SE or GraalVM versions (8u491, 11.0.31, 17.0.19, 21.0.11, 25.0.3, 26.0.1, or GraalVM equivalents) that perform TLS certificate validation, particularly client-side applications or web services consuming external APIs.
2. Craft a rogue certificate: Create a TLS certificate with a wildcard Subject Alternative Name (SAN) dNSName (e.g., *.foo.com) where the target hostname (e.g., secret.foo.com) is listed as an excluded name in a NameConstraints extension.
3. Exploit the dual-interpretation flaw: Present this certificate to a vulnerable Java client. During path validation, DNSName.constrains compares *.foo.com and secret.foo.com literally, returning NAME_SAME_TYPE and not rejecting the chain despite the exclusion. HostnameChecker then interprets *.foo.com as a wildcard and accepts secret.foo.com, completing the bypass.
4. Achieve objective: With certificate validation bypassed, perform a man-in-the-middle attack to intercept or modify TLS-protected communications, gaining unauthorized read access to transmitted data or injecting unauthorized data into the session (Red Hat Bugzilla, Oracle CPU July 2026).

• Network: Unexpected TLS connections from Java applications to hosts that should be excluded by certificate NameConstraints; TLS sessions established with certificates bearing wildcard SANs where the connecting hostname matches an exclusion pattern.
• Logs: Java application logs showing successful TLS handshakes to hosts that should have been rejected by certificate policy; absence of CertPathValidatorException or SSLHandshakeException where certificate exclusions should have triggered them.
• Process: Java processes (e.g., java, javaw) establishing outbound connections to unexpected endpoints, particularly in sandboxed environments running Web Start or applet-based applications.

Oracle has released patches as part of the July 2026 Critical Patch Update; users should upgrade to the next available fixed versions beyond the affected releases (8u491, 11.0.31, 17.0.19, 21.0.11, 25.0.3, 26.0.1 for Java SE; 17.0.19 and 21.0.11 for GraalVM for JDK; 21.3.18 for GraalVM Enterprise Edition) (Oracle CPU July 2026). Red Hat has issued multiple errata (RHSA-2026:42876 through RHSA-2026:48845) addressing this vulnerability across RHEL 7, 8, 9, and 10, as well as OpenJDK builds 8u502, 11.0.32, 17.0.20, 21.0.12, and 25.0.4 (Red Hat Bugzilla). IBM has also released patches for IBM SDK Java Technology Edition and IBM WebSphere Application Server/Liberty affected by this issue. As a short-term workaround, restrict or disable Java Web Start and sandboxed applet execution, and block network access to untrusted endpoints from Java processes until patching is complete (Oracle CPU July 2026).

The vulnerability was tracked and addressed rapidly by major Linux distributions and enterprise vendors. Red Hat issued over a dozen errata within two days of disclosure, covering RHEL 7 through 10 and multiple OpenJDK build streams (Red Hat Bugzilla). SUSE, openSUSE, AlmaLinux, Rocky Linux, Amazon Linux, and Debian also released advisories and patches within days of the Oracle CPU publication. IBM addressed the issue in IBM SDK Java and WebSphere Application Server/Liberty. No significant independent researcher commentary or social media discussion beyond standard patch tracking has been observed, consistent with the Medium severity rating and absence of public exploit code.