CVE-2026-33929: 
Java vulnerability analysis and mitigation

CVE-2026-33929 is a path traversal vulnerability (CWE-22) in the ExtractEmbeddedFiles example code of Apache PDFBox. The flaw is an incomplete fix for a prior related vulnerability (CVE-2026-23907): the boundary check introduced in versions 2.0.36 and 3.0.7 fails to account for the file path separator, allowing a malicious PDF to write files to unintended directories that share a common prefix with the intended output directory (e.g., writing to /home/ABCDEF when only /home/ABC is authorized). Affected versions are Apache PDFBox 2.0.24 through 2.0.36 and 3.0.0 through 3.0.7. It was disclosed on April 14, 2026, with a CVSS v3.1 base score of 4.3 (Medium) (Github Advisory, Feedly).

The root cause is an incomplete directory boundary check in the extractFile() method of ExtractEmbeddedFiles.java. The flawed check used startsWith(directoryPath) to validate that extracted file paths remained within the intended output directory, but did not append a file separator (File.separator) to the prefix. This means a path like /home/ABCDEF would incorrectly pass validation when the intended directory is /home/ABC, because the string /home/ABCDEF does start with /home/ABC. The correct fix, provided in GitHub PR #427, changes the check to parentCanonical.equals(directoryPath) || parentCanonical.startsWith(directoryPath + File.separator), ensuring only true subdirectories are permitted (Github Advisory, PR #427). This vulnerability is classified as CWE-22 and is exploitable over the network by a low-privileged attacker with no user interaction required.

Successful exploitation allows an attacker to craft a malicious PDF that, when processed by an application using the vulnerable ExtractEmbeddedFiles example code, causes arbitrary files to be written to directories outside the intended restricted path. The primary impact is on integrity — unauthorized file creation or modification in unintended filesystem locations — with no direct confidentiality or availability impact. This could potentially be leveraged to overwrite configuration files, plant malicious scripts, or corrupt application data, depending on the write permissions of the process running PDFBox (Github Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.019% (0.000190), indicating a very low probability of exploitation in the near term. Exploitation requires the attacker to supply a crafted PDF to a system running production code derived from the vulnerable example, and the attacker must have at least low-level network access.

1. Identify a target: Locate an application that has incorporated the Apache PDFBox ExtractEmbeddedFiles example code into production and accepts PDF uploads or processes PDFs from untrusted sources, running a vulnerable version (2.0.24–2.0.36 or 3.0.0–3.0.7).
2. Craft a malicious PDF: Create a PDF containing an embedded file with a filename that exploits the path prefix bypass — for example, if the output directory is /home/ABC, embed a file with a path like ../ABCDEF/malicious.sh or use a filename that resolves to /home/ABCDEF/malicious.sh after canonicalization.
3. Submit the PDF: Upload or otherwise deliver the crafted PDF to the target application so it is processed by the vulnerable ExtractEmbeddedFiles code path.
4. Trigger file write: The flawed startsWith(directoryPath) check passes for the crafted path, and the embedded file is written to the unintended directory (e.g., /home/ABCDEF/) with the permissions of the PDFBox process.
5. Achieve objective: Depending on write permissions and the target directory, the attacker may overwrite configuration files, plant web shells, or corrupt application data to enable further compromise (Github Advisory, PR #427).

• File System: Unexpected files appearing in directories adjacent to (sharing a prefix with) the configured PDFBox output directory (e.g., files in /home/ABCDEF/ when the intended output is /home/ABC/); newly created or modified files in sensitive directories owned by the PDFBox process user.
• Logs: Application logs showing PDF processing activity followed by file write operations to unexpected paths; Java stack traces or error messages referencing ExtractEmbeddedFiles or embedded file extraction.
• Process: Unusual file creation events by the Java process running PDFBox, particularly writes outside the expected output directory; monitoring tools (e.g., auditd, inotify) alerting on writes to directories not normally accessed by the application.

Users should upgrade to Apache PDFBox version 2.0.37 or 3.0.8 once available, as these versions contain the corrected boundary check. As an interim measure, apply the fix from GitHub PR #427, which changes the directory check to use equals() combined with startsWith(directoryPath + File.separator). Organizations that have copied the ExtractEmbeddedFiles example into their own production code must apply this fix manually. Additionally, restrict the write permissions of the PDFBox process to only the minimum necessary directories, and implement input validation when handling embedded files from untrusted PDFs (Github Advisory, IBM Advisory).

IBM issued advisories noting that pdfbox-2.0.28.jar used in IBM Maximo Application Suite and Cloudera Data Platform Private Cloud Base is affected, and published remediation guidance for impacted products (IBM Advisory, IBM Advisory 2). The vulnerability was also flagged in openSUSE security announcements and picked up by security aggregators shortly after disclosure. Community reaction has been relatively muted given the moderate severity and limited exploitability, with no notable researcher commentary or significant media coverage identified.