Patching the JVMs you didn't install: Java inside vendor products

When security teams talk about "patching Java," they usually mean the JDKs their own engineers install: the runtime on the standard server build, the base container image, the app-server installation. Those matter, and they're the easy part.

The harder part is the Java that arrived inside something else. A large share of the JVMs in a typical enterprise were never installed as Java at all. They came bundled inside a commercial product, an appliance, a build tool or a desktop application, each with its own runtime, update schedule and support rules.

Where bundled JVMs hide

Common places we find private Java runtimes:

• Application servers and middleware installed from vendor media, which often include their own JDK.
• Database and data-platform tooling: management consoles, client tools, ETL and integration products.
• Search and analytics engines. Some ship with a bundled JDK by default. Elasticsearch is a well-known example.
• CI/CD and developer tooling: build agents, artifact repositories and IDEs that bundle their own runtime.
• Monitoring, backup and security products: collectors, agents and management servers.
• Collaboration and ticketing platforms whose installers include a JRE.
• Network and storage appliances, virtual or physical, with management interfaces written in Java.
• Desktop applications that bundle a private JRE to avoid depending on the system Java.

Each of these has a runtime that's often several updates behind, sometimes a full major version behind, and owned in practice by nobody.

Why your scanners miss them

Most inventory and vulnerability tools find Java by asking the operating system: the package manager, the Windows installed-programs list, or the java on the PATH. Bundled runtimes usually bypass all three:

• They're unpacked into the product's own directory, not installed as a package.
• They're not on the PATH, because only the product's launcher uses them.
• Their version may not appear in any registry or package database.
• In containers, the JDK is a layer inside a vendor image you pull, not something you install.

Some scanners do file-system or running-process checks and catch more. Even then, results are often reported as "Java vulnerability on host X" with no link to the product that owns the runtime. That leaves the ticket with nowhere useful to go.

Good discovery looks at running processes, the file system (for release files, libjvm and java binaries outside standard locations), container images and artifact repositories. It then ties each runtime back to the product and owner responsible for it. We describe that approach in finding every JVM in your estate.

The supportability question

Once you've found an outdated bundled runtime, the obvious fix is to replace it with a patched JDK. Before you do, ask: will the vendor still support the product if you do?

Vendors fall into roughly four groups:

Check the product's certification matrix or supported-platforms documentation. Where it's silent, ask the vendor directly and get the answer in writing. "Support told us on a call that it's fine" won't help much when an incident review asks why the runtime was changed.

Your options, in order of preference

1. Take the vendor's update

If the vendor ships the patched runtime as part of a product release, upgrading the product is the supported path. Measure how long the vendor takes to ship Java CPU fixes. A vendor that routinely lags two or three quarters behind the Java security schedule is a risk worth raising at renewal.

2. Do a supported runtime replacement

If the vendor documents how to use an external or newer JDK, do it within those limits. Treat it like any other JVM patch: smoke test, canary where possible and keep a rollback. Remember that the product's next upgrade may silently restore its bundled runtime, so re-check after every product update.

3. Apply compensating controls

When you can't patch the runtime without losing support, reduce the exposure instead:

• Network isolation. Restrict who and what can reach the product, especially management interfaces.
• Disable unused features that expose vulnerable code paths, such as remote management, deserialization endpoints or unused protocols.
• Tighten TLS and authentication at a proxy or load balancer in front of the product.
• Increase monitoring on the host, and document the accepted risk with a named owner and a review date.

Compensating controls are a legitimate risk decision, but they should be recorded as one, not left as an undocumented exception. The governance side is covered in getting faster JVM patching approved by your CAB.

4. Use commercial pressure

Vendors respond to contract terms more reliably than to support tickets. At renewal or in new contracts, consider asking for:

• A commitment to ship Java security updates within a defined window after each quarterly CPU.
• A software bill of materials (SBOM) that lists the bundled runtime, version and vendor.
• A documented, supported procedure for replacing the bundled runtime.
• Support for current LTS Java releases within a reasonable period after release.

The Oracle licensing nuance

Bundled runtimes also complicate Oracle Java licensing, in both directions.

Some commercial products, including some Oracle products and some third-party products, include a Java SE license that's restricted to running that product. An Oracle JDK bundled that way may not create exposure by itself, but it generally doesn't allow general-purpose use by other applications on the same machine.

The opposite also happens. A product may have been installed with an Oracle JDK that someone downloaded separately, with no licensing coverage from the product vendor at all.

So don't assume either way. For each bundled Oracle runtime, check the product's license terms and record the conclusion. This matters because of how Oracle's employee-based Java metric works: one uncovered install can put the whole organization in scope. For the timing pressure on JDK 21 in particular, see what the end of the free update window means.

Making it sustainable

Bundled runtimes don't stay fixed. Products get upgraded, reinstalled and replaced, and each change can bring a different runtime. The practical approach:

1. Keep the inventory of bundled runtimes linked to products and owners.
2. Track each product's Java update lag against the quarterly CPU calendar.
3. Record the support position and license position per product.
4. Re-scan continuously, not once a year, so a product upgrade that restores an old runtime gets noticed.

What to do next

Our third-party application advisory works through bundled runtimes product by product, from support position to vendor escalation. Continuous drift monitoring catches it when a product upgrade quietly brings an old JVM back.