MuPDF and Foxit Build PDF AES-256 Keys From the Clock, V12 Finds, and Recovery Takes Seconds

Anyone holding a PDF encrypted by MuPDF before version 1.28.5, or by Foxit PDF Reader 2026.1.3.36551, can recover the file's AES-256 key without either password, according to Rick de Jager of V12. His October 27 write-up says both programs derive the key from the current time rather than from a cryptographic random source, so the 256-bit key protects far less than 256 bits.

The attacker needs only the encrypted file. No CVE identifiers appear in the post.

MuPDF: 512 possible keys

MuPDF seeds a 48-bit drand48-style generator with the current time in seconds. Only about 9 bits of that timestamp change the output bytes, which leaves 512 possible key streams. The same generator produces the document /ID, which gives an attacker a built-in check on each guess.

De Jager wrote that he recovered the key for a test document in about 11 milliseconds using unoptimised Python. His post says the issue was disclosed to the vendors and, in MuPDF's case, fixed. MuPDF 1.28.5 is the first fixed version, and the post gives no release date. The project's GitHub releases page lists no releases, so a version-level confirmation was not available from that source.

Foxit: a SHA-256 of the timestamp

In Foxit PDF Reader 2026.1.3.36551 the file key is the SHA-256 of three things: the current timestamp, a 32-byte buffer that is uninitialised and zero-filled in practice, and the constant string "there". The /Perms block holds known plaintext, so each candidate key costs one hash and one AES block decryption to test.

On an AMD Ryzen 9 7950X, de Jager's Rust tool tested about 370 to 376 million timestamps per second. Searching every second back to 1970 took about 4.85 seconds. A date range is unnecessary at that speed.

Software	Version in post	Weak input	Fixed
MuPDF	before 1.28.5	9 effective timestamp bits, 512 key streams	Yes, per the post
Foxit PDF Reader	2026.1.3.36551	SHA-256 of timestamp, zero buffer, "there"	Not stated
OpenPDF	3.0.5	ARC4 seeded with millisecond time and JVM free memory	Not stated
iText	9.7.1	Same IVGenerator pattern	Not stated

The 2014 origin

The Foxit derivation is old. The post links the initial public commit of PDFium, dated May 2014, and the file header credits Foxit Software for the original code. That file's AES-256 routine hashes time(NULL), the 32-byte key buffer and the string "there", the same recipe de Jager describes.

He writes that other editors may have inherited the pattern through PDFium. Neither the post nor the 2014 file establishes whether today's PDFium, or Chrome's PDF viewer, still creates keys this way, so that remains open.

Java libraries behave differently

OpenPDF 3.0.5 and iText 9.7.1 both route randomness through an IVGenerator class. It uses an ARC4 stream seeded with the millisecond clock and the JVM's free memory, and the same stream produces the file key and the 32 bytes of salts stored in plaintext in /U and /O. De Jager says there is more variance here, so recovery is harder, but the advertised 256-bit strength is still undermined.

What to do about existing files

There is no fix for a file that has already been distributed. De Jager says copies published earlier cannot be protected retroactively. V12 released decryptors for MuPDF and Foxit on GitHub, in a pdf_decryptors folder with mupdf and foxitpdf subfolders.

For new files, the safe route is to encrypt with MuPDF 1.28.5 or later, or to treat PDF password protection from the other products as obfuscation until their vendors respond. Two other recent disclosures with a patch-status gap are the EDK2 PXE bug and Oracle EBS's CVE-2026-101767.

The post does not say whether Foxit, OpenPDF or iText have accepted the reports, and it gives no patch dates for any of them.