The maven-assembly-plugin packages your project's classes, resources, and dependencies into a single distributable archive such as a fat JAR or a tar.gz, and because it only creates archives rather than extracting them, several archive-related vulnerabilities that scare people do not actually apply to it. The most-cited example is Zip Slip, a path-traversal flaw in archive extraction. maven-assembly-plugin uses the same underlying plexus-archiver library that the Zip Slip advisories named, but it uses the write path, not the read path, so it is not vulnerable to that class. Understanding this distinction is the whole point of a security guide for this plugin: knowing which risks are real for a build-time tool and which are noise.
What the plugin does
An "assembly" in Maven is a defined grouping of files, directories, and dependencies collected into an archive format for distribution. The maven-assembly-plugin (current stable line is 3.8.0) reads an assembly descriptor and produces the artifact you actually ship, most commonly the jar-with-dependencies fat JAR that bundles every runtime dependency into one executable jar.
A minimal configuration looks like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>com.example.Main</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
Because the plugin runs at build time, its threat model is a build-time threat model. It does not process attacker-controlled archives at runtime; it assembles artifacts from inputs your build already trusts.
Why Zip Slip does not apply here
Zip Slip is an arbitrary-file-write vulnerability achieved with a crafted archive whose entry names contain ../ path-traversal sequences. When a naive extractor concatenates an entry name onto the target directory without validating the result, a malicious entry can write outside that directory, potentially overwriting a config file or a binary.
The vulnerable component in the Maven ecosystem was plexus-archiver, with the flaw affecting versions in the [,3.4] range plus 3.5, and fixes landing in 3.4.1 and 3.6.0. Many Maven packaging plugins depend on plexus-archiver, which is why the advisory swept them all up in scanner results.
The key fact: the maven-assembly-plugin only creates archives. Zip Slip is an extraction vulnerability. Creating an archive from your own build outputs never traverses attacker-supplied entry names, so the plugin is among those that use plexus-archiver but are not affected. If a dependency scanner flags maven-assembly-plugin for Zip Slip, that is a case where you can document the finding as not applicable, ideally with a VEX statement so the false positive does not resurface on every scan.
The risks that are real
Ignoring the non-issue leaves the risks that genuinely apply to any build-time plugin.
The fat JAR bundles every runtime dependency, so its security is the sum of everything you pulled in. maven-assembly-plugin does not introduce those vulnerabilities, but it packages them, which means a vulnerable transitive dependency ships inside your artifact. This is where software composition analysis matters: you want to know the CVEs in the tree before you bundle them, not after a scanner opens the shipped JAR. An SCA tool inventories the transitive dependencies the assembly bundles and flags known issues before release.
Plugin provenance is the other real risk. Maven plugins execute arbitrary code during your build, so a compromised or typosquatted plugin coordinate is a direct supply chain attack. Always resolve plugins from a trusted repository, pin exact versions (never a range), and verify the checksums Maven records.
# fail the build if dependency checksums do not match what is locked
mvn --strict-checksums verify
Manifest and descriptor hygiene rounds it out. If your assembly descriptor pulls files by wildcard from a directory that other build steps write to, be sure nothing untrusted lands there first. Keep the descriptor explicit about what goes into the archive.
Hardening the build
A few concrete measures raise the bar without much effort.
Pin the plugin version and keep it current with upstream, since fixes and hardening land in the plugin itself over time. Prefer the maven-shade-plugin if you need relocation or class-level merging that assembly does not handle; for straightforward bundling, assembly is fine.
Run dependency scanning as a build gate, not an afterthought. The moment to catch a vulnerable dependency is before it is sealed into the artifact you distribute:
# example gate before packaging
mvn org.owasp:dependency-check-maven:check
mvn clean package # assembly runs here, only after the tree is clean
Reproducibility helps too. Setting project.build.outputTimestamp produces byte-identical archives across builds, which makes tampering detectable because an unexpected change in the output hash signals something in the inputs changed. Our academy covers reproducible builds and build-time supply chain controls in more depth.
FAQ
Is maven-assembly-plugin vulnerable to Zip Slip?
No. Zip Slip is an archive-extraction vulnerability, and maven-assembly-plugin only creates archives. It shares the plexus-archiver library named in the advisories, but it uses the write path, so the extraction flaw does not apply. A scanner flagging it can be documented as not applicable.
What is the real security risk of using maven-assembly-plugin?
Two things: the fat JAR it builds bundles every transitive dependency, so it packages whatever CVEs those carry, and Maven plugins run arbitrary code at build time, so plugin provenance matters. Scan dependencies before packaging and pin plugin versions from trusted repositories.
Which version of maven-assembly-plugin should I use?
Use the current stable release (the 3.8.0 line at the time of writing) and pin the exact version rather than a range. Keep it updated as upstream ships fixes and hardening.
Should I use maven-assembly-plugin or maven-shade-plugin?
Use assembly for straightforward bundling into a fat JAR or tar.gz. Use shade when you need class relocation, service-file merging, or to avoid classpath conflicts between bundled dependencies. Both are legitimate; the choice depends on how complex your packaging is.