CVE-2026-60147

What it actually does

This is a network-exploitable authorization bypass in the Security component of Oracle Java SE and Oracle GraalVM-based JDK distributions. An unauthenticated attacker can trigger vulnerable Java APIs, including indirectly through applications or web services that pass attacker-controlled data into those APIs. Successful exploitation can allow unauthorized read access to a subset of data accessible to the Java runtime and unauthorized update, insert, or delete access to some accessible data. The impact is limited to confidentiality and integrity; the vulnerability is not described as causing code execution or service availability loss. The issue also affects legacy client-side Java deployments that rely on the Java sandbox, such as sandboxed Java Web Start applications or applets running untrusted internet-supplied code.

Why it matters to the business

Java is commonly embedded in business applications, middleware, developer tooling, and server-side services, so vulnerable runtimes may exist both on servers and endpoints. If exposed through an application interface, the flaw could let an unauthenticated attacker view or alter data that the Java process can access, potentially causing data integrity issues, unauthorized disclosure, audit discrepancies, and downstream business process errors. The current exploitation signal is low: EPSS is 0.00287, it is not listed in CISA KEV, ransomware use is not reported, and exploit maturity is listed as none. Even so, because the affected technology is broadly deployed and the attack requires no authentication or user interaction, organizations should patch during the next prioritized Java update cycle and accelerate remediation for internet-facing Java services or environments that run untrusted Java code.

How an attack unfolds

An attacker first identifies a Java- or GraalVM-based application, service, or client workflow that exposes functionality backed by the vulnerable Security component. In server-side scenarios, the attacker sends crafted input over a supported network protocol to a web service or application endpoint that passes that data into the affected Java APIs. Because exploitation is unauthenticated and low complexity, the attacker does not need prior access if the vulnerable function is reachable. If the vulnerable code path is exercised, Java’s intended security checks can be bypassed, allowing the attacker to read a limited subset of data available to the runtime or perform unauthorized updates, inserts, or deletes against data the runtime can access. In client-side scenarios, the attacker may entice a user or system into loading untrusted sandboxed Java Web Start or applet content, where the bypass undermines sandbox assumptions. There are no named threat actors, public exploit maturity, or KEV evidence in the provided intelligence, so defenders should focus on exposure-driven risk rather than known campaign-specific tradecraft.

How to fix it

Upgrade affected Java and GraalVM runtimes to vendor-fixed builds and restart all Java processes so the updated runtime is actually loaded. For Red Hat packages, apply RHSA-2026:50281 or later. Fixed Red Hat package versions include: java-11-openjdk 11.0.32.0.9-1.el7_9, 11.0.32.0.9-1.el8, or 11.0.32.0.9-1.el9; java-17-openjdk 17.0.20.0.8-1.1.el8 or 17.0.20.0.8-1.1.el9; java-1.8.0-openjdk 1.8.0.502.b07-1.1.el7_9, 1.8.0.502.b07-1.1.el8, or 1.8.0.502.b07-1.2.el9; java-21-openjdk 21.0.12.0.8-1.1.el10_2, 21.0.12.0.8-1.1.el8, or 21.0.12.0.8-1.2.el9; java-21-openjdk-main and java-21-openjdk-portable-main 21.0.12.0.8-0.1.hum1; java-25-openjdk 25.0.4.0.7-1.1.el10_2 or 25.0.4.0.7-1.1.el9; and java-25-openjdk-portable-main 25.0.4.0.7-2.0.2.hum1. For Oracle Java SE and Oracle GraalVM, apply the corresponding Oracle Critical Patch Update or later supported release that supersedes affected versions 8u491, 8u491-perf, 11.0.31, 17.0.19, 21.0.11, 25.0.3, 26.0.1, GraalVM for JDK 17.0.19 and 21.0.11, and GraalVM Enterprise Edition 21.3.18. Where immediate patching is not possible, reduce exposure by blocking unauthenticated access to Java-backed endpoints that pass untrusted input into security-sensitive APIs, disabling legacy Java Web Start or applet execution where feasible, enforcing strong application-layer authorization before Java API invocation, and running Java services with least-privilege data access.

How to confirm the fix worked

Confirm installed runtime versions using operating-system package inventory and runtime checks. On Red Hat systems, use commands such as rpm -q java-11-openjdk java-17-openjdk java-1.8.0-openjdk java-21-openjdk java-25-openjdk and verify the installed release is equal to or newer than the fixed package for the platform. Also run java -version from each application runtime path, including bundled JRE/JDK directories in application installations and containers, because applications may not use the system default Java. For containers, rebuild base images and verify the patched runtime inside the running image rather than only on the host. Confirm all Java services were restarted after patching by checking process start times and mapped runtime paths. Exposure validation should identify externally reachable Java-backed services, legacy JNLP/Web Start usage, browser applet remnants, and applications that accept untrusted input and pass it to Java Security component APIs. If vendor scanners are used, ensure they detect both Oracle and Red Hat OpenJDK/GraalVM package names and the exact fixed versions listed in RHSA-2026:50281 or later.

Typical attack path

1. Identify an internet-facing or network-accessible application running an affected Oracle Java SE, OpenJDK, or GraalVM runtime.
2. Map reachable endpoints or protocols that accept attacker-controlled input and invoke Java Security component APIs directly or indirectly.
3. Send crafted unauthenticated requests or data that reach the vulnerable API path.
4. Bypass intended authorization or sandbox restrictions when the vulnerable component processes the input.
5. Read data accessible to the Java process or perform unauthorized insert, update, or delete operations within the process’s accessible data scope.
6. Use the unauthorized data access or modification to support fraud, tampering, lateral discovery, or follow-on attacks against the application or business workflow.

How to detect it

There are no public, unique exploit strings or campaign-specific indicators in the provided intelligence, so retrospective detection should be behavior- and exposure-based. Review application, API gateway, WAF, reverse proxy, and load balancer logs for unauthenticated requests to Java-backed endpoints followed by data reads or modifications that normally require authorization. Correlate suspicious requests with application audit logs showing unexpected insert, update, delete, or read operations, especially where the application user is anonymous, unauthenticated, missing, or inconsistent with the affected records. Examine Java application logs for security-check anomalies, authorization decision inconsistencies, sandbox violations, unexpected SecurityException handling followed by successful operations, or unusual access-control debug output around the same timestamps. On endpoints, review EDR and proxy logs for java, javaw, javaws, or GraalVM processes loading untrusted JNLP, applet, or remote code content, particularly if followed by unexpected file, network, or data access. For servers, correlate inbound network activity with Java process activity, database audit logs, object-store access logs, message queue operations, and file modifications performed by the Java service account. Because the vulnerability affects confidentiality and integrity rather than availability, absence of crashes is not meaningful evidence of non-exploitation.

What your security team should do

• Prioritize patching internet-facing Java services, authentication-adjacent services, data-modifying APIs, and any environment that executes untrusted Java code.
• Apply RHSA-2026:50281 or the relevant Oracle Critical Patch Update across all affected Java SE, OpenJDK, and GraalVM installations, including containers, embedded runtimes, build agents, and endpoint software bundles.
• Inventory non-default Java installations using filesystem, package, EDR, and container image data; do not rely only on the system java command.
• Restart Java applications after patching and verify running processes are using the updated runtime path and version.
• Temporarily restrict unauthenticated access to Java-backed endpoints that process untrusted input until patching is complete.
• Disable or tightly control Java Web Start, applets, and other legacy sandboxed Java client technologies where they are still present.
• Review application authorization controls around data read/write functions exposed through Java services, especially where Java process privileges exceed user privileges.
• Hunt for suspicious unauthenticated requests followed by unusual data reads, inserts, updates, or deletes in Java-backed applications since publication on 2026-07-21.
• Because this is not currently KEV-listed and EPSS is low, track threat intelligence for exploit publication or EPSS movement and adjust remediation urgency if exploitation emerges.