Fifty Shades of JAR: A Love Story Between Devs and CVEs

Picture this. It’s April 15, 2025. The government has just stepped in to stabilize the National Vulnerability Database. Relief ripples across Twitter and LinkedIn. The CVE system, for now, has been saved.

You glance at your recent SCA scan. Everything looks clean. Your dashboard is green.

Or so it seems.

Meanwhile, hidden inside your applications, thousands of real vulnerabilities are quietly nesting in the code. They do not appear in your scanner. They are not listed in the CVE database. And no one is talking about them, because no one knows they are there.

At Hopper, we recently uncovered over 2.5 million of these vulnerabilities. They are not theoretical. They are not edge cases. They are real, exploitable flaws buried in widely used Java packages.

These blind spots live inside the Maven ecosystem, wrapped into Uber JARs and renamed through shading. Most modern SCA tools still fail to detect them.

If we are serious about fixing open-source risk, we cannot stop at package names and manifests. The lights may be back on at the CVE Program, but deep in your codebase, the real threats remain hidden.

The JARs, the Uber JARs, and the Shaded Truth

To understand where the blind spots begin, we need to look at how Java applications are built.

In Java, JAR files (short for Java ARchives) bundle compiled classes and metadata into a single archive. When published to Maven Central or an internal repository, they typically include a POM (Project Object Model) file. A POM is an XML file that defines project metadata, dependencies, and build rules.

Build tools like Maven, Gradle, Bazel, or Ivy read the POM and resolve the full dependency graph, often pulling in dozens or even hundreds of transitive packages.

For a Java application to run, it is necessary to specify the exact location of each dependency. With hundreds of them, this quickly becomes difficult to manage.

This is where Uber JARs, also known as fat JARs, come in. An Uber JAR is a single, self-contained file that packages the application together with all of its dependencies. It ensures everything needed to run is included in one place, reducing deployment complexity.

However, bundling everything introduces new challenges. Different libraries may bring in conflicting versions of the same dependency. It is not always clear which one will be used at runtime.

To prevent these conflicts, developers use shading. Shading solves this by performing a controlled copy-and-paste of a dependency. It relocates package paths and changes namespaces so that the embedded code does not clash with other versions. It is like cloning a library, giving it a new identity, and tucking it safely away under a different name.

While this helps ensure compatibility, it also removes any obvious trace of the original code.

That is where security visibility begins to break down.

When Does a Vulnerability Become Invisible?

Shading does more than bundle code. It also trims the metadata.

When tools like the Maven Shade Plugin generate an Uber JAR, they often produce a reduced POM. This is a simplified file that lists only direct dependencies, based on the assumption that everything else has already been packaged inside.

The moment a dependency is removed from the POM is exactly the moment your SCA will ignore its existence, it is exactly the moment it will ignore the risks it’s bringing in and this is precisely the moment when a vulnerability becomes invisible.

Who Owns the Blind Spot?

Every blind spot has a cost. This one brings millions of them.

When vulnerabilities are hidden inside shaded code or buried deep within Uber JARs, no single system or team is clearly responsible for catching them. The issue lives between the layers, not because of neglect, but because of structural gaps in how modern software is assembled and how risk is assessed.

And that is the heart of the problem.

Vulnerability Databases

You might expect public databases like NVD, GHSA, and OSV to catch vulnerabilities in shaded or repackaged code. These databases often list multiple affected products for a single CVE, but that information typically comes from the vendor or researcher who reported the vulnerability.

The problem is that these systems rely on official package names and versions to track vulnerable code. When a library is shaded or repackaged, those identifiers change. The vulnerable code is still present, but the link to its original identity is lost.

Public databases do not account for entire ecosystems like Maven Central or analyze repackaged binaries. Their scope is limited to what is disclosed, not what is discovered through deep inspection. That is why vulnerabilities buried inside Uber JARs often go unrecognized.

We will return to this gap later, because it plays a central role in the industry’s visibility problem.

A New Responsibility

This is exactly the gap Hopper was built to fill.

We believe visibility into risk must reflect the way software is really built. That means analyzing what is in the binary, not what is written in a manifest. It means identifying whether a vulnerable function is actually present, whether it can be executed, and how it got there.

Ownership starts with visibility. And visibility starts by looking in the right place.

The Scale of the Problem

To understand the true scope, we conducted one of the largest studies ever on shaded and embedded Java vulnerabilities. Hopper analyzed over 16 million artifacts in Maven Central, the backbone of modern Java development.

The results were staggering:

• Over 231,000 packages contained shaded dependencies
• Over 1.4 million distinct packages were hidden inside them
• About half of those contained at least one known vulnerability
• In total, we identified more than 2.5 million vulnerabilities

Of those:

• 425,000 were critical
• 1.2 million were high severity
• More than 8,000 appeared in the CISA Known Exploited Vulnerabilities catalog
• Over 3,000 instances of Log4j (CVE-2021-44228) remained in shaded form
• 4,500 vulnerable packages were still present in their latest version with no fix available, exposing more than 100,000 vulnerabilities

This is not just a theoretical issue. It is already happening inside real organizations.

By enabling shaded package scanning for a Fortune 200 company, we uncovered 47% more vulnerabilities that had previously gone undetected, significantly enhancing their security visibility. We have observed similar jumps at companies of every size.

These are not false positives. They are real risks, hiding in real builds, and most tools are not catching them.

This is not just a tooling flaw. It is a visibility crisis.

Turning the Lights On: How Hopper Addresses It

We built Hopper to confront the messy reality of how modern software is assembled. Code today is not just written. It is constructed from deeply nested dependencies, repackaged modules, and Uber JARs that often obscure what is actually included in the final build.

Most traditional SCA tools rely on surface-level metadata. They read manifests like pom.xml and assume the declared dependencies tell the full story. But that assumption often breaks down, especially when code has been shaded, relocated, or embedded.

Hopper does not rely on declarations alone. It verifies what is in the binary.

Our platform inspects the actual bytecode across the full dependency graph. This includes shaded libraries, transitive imports, and internal components. Hopper answers the critical questions that most tools cannot:

• Is any vulnerable code, shaded or unshaded, present in the binary?
• Can that code be executed by the application?
• Is this binary a runnable service or an internal library?
• Where did the vulnerable function come from, and how can it be fixed?

This depth of visibility is enabled by three core capabilities:

• A function-level vulnerability database
• A binary composition analysis engine
• A static call-graph engine that traces potential execution paths

We statically analyze function calls and build accurate call graphs, even when code has been renamed, relocated, or buried in shaded packages. If a vulnerability exists and can be exploited, Hopper will find it and identify its origin.

This is not just about surfacing more issues. It is about delivering clear, actionable context that shows what matters and why.

Hopper brings visibility not only to vulnerabilities, but also to the paths they take and the code that introduced them.

The Bottom Line

The Java ecosystem is rich, vast, and full of innovation — but also full of hidden complexity. Uber-JARs, shaded dependencies, and reduced POMs have made it easier to ship software… and easier to hide vulnerabilities.

At Hopper, we’ve seen what’s hiding in plain sight. Our research uncovered millions of vulnerabilities buried deep in repackaged binaries — invisible to conventional tools but very real in production.

Our function-level reachability analysis cut over 93% of this noise and let focus on real and actual risks.

It’s time to stop relying on metadata. It’s time to analyze the actual code.

‍

Ready to see what your tools are missing?

Let us show you what’s really in your software. See Hopper in action.

‍