MuPDF and Foxit generate AES-256 PDF keys from as little as nine bits of entropy

An investigation published on the security blog v12.sh, which surfaced on the front page of Hacker News, found that several PDF implementations derive their AES-256 file encryption keys from random state small enough to simply enumerate. In MuPDF the effective entropy comes down to nine bits; in Foxit's PDF reader the key is essentially a function of the clock. In both cases, documents encrypted with AES-256 can be decrypted without knowing either password.

How PDF encryption is supposed to work

Modern PDF encryption, revision 6, does not encrypt content with the password directly. According to the writeup, the implementation generates a random 32-byte file key that encrypts the document, and the password plus a salt are hashed to derive a second key that wraps the file key. A user password opens the document and an owner password governs permissions, but either one unlocks the same file key, and permission restrictions are enforced only by the reader. The security of the whole scheme therefore rests on the file key being unpredictable, which is exactly the property these implementations failed to deliver.

MuPDF: nine bits of real randomness

MuPDF versions before 1.28.5 seeded a drand48-style linear congruential generator once, using the current Unix time in seconds. When the library needed random bytes for a key, it took them from bits 17 through 24 of the generator's state. Because LCG arithmetic carries bits upward but never downward, everything above bit 24 of the state can be ignored, and the bottom 16 bits are initialized to a fixed constant. That leaves nine bits from the timestamp: timestamps 512 seconds apart produce identical byte streams.

The authors demonstrated that enumerating all 512 candidate keys takes about 11 milliseconds even in an unoptimized Python script, and the recovered key decrypted a test document without either password. MuPDF also generates the document ID from the same generator and stores it in the trailer in plaintext, which gives an attacker a convenient way to confirm the correct stream.

Foxit: the clock as a key

Foxit PDF Reader 2026.1.3.36551 builds its file key by hashing a little-endian 32-bit timestamp, 32 uninitialized bytes that in practice turn out to be zero, and the constant string "there" with SHA-256. Since the permissions block in the document contains known plaintext, testing a guess costs one hash and one AES block decryption, with no password hashing and no document decryption.

A multithreaded Rust implementation written by the authors sustained 370 to 376 million guesses per second on a Ryzen 9 7950X. Searching every timestamp since the Unix epoch took 4.85 seconds, and for a recently created document recovery lands in the order of milliseconds.

A bug with shared ancestry

The same timestamp-based derivation appears in PDFium's first public commit from May 2014, and the file header credits Foxit with the original code. The researchers conclude the pattern originated at Foxit and may have spread to other PDF editors through PDFium, which would explain why it shows up in multiple suites.

OpenPDF and iText show the same pattern

OpenPDF 3.0.5 and iText 9.7.1 route their cryptographic randomness through an IVGenerator class that seeds an ARC4 stream with a string combining a millisecond timestamp and the JVM's free memory. The same stream produces both the file key and the salts stored in plaintext, giving an attacker material to test guesses against. The state space here is considerably larger than in MuPDF or Foxit, but as the writeup puts it, the advertised 256-bit security is still undermined by non-cryptographic randomness.

Why it matters

AES-256 provides no protection when the key comes from a source an attacker can enumerate. Revisions 5 and 6 of the PDF encryption standard were meant to improve on older keys derived directly from user passwords, but weak random number generation quietly undid that upgrade: the strength of an author's password becomes irrelevant once the underlying file key can be guessed. That matters most for the confidential legal, medical, and financial documents that password protection is typically relied upon for, since anyone who later obtains an encrypted file can open it. The authors state that the issues were disclosed to the affected vendors, and they pin MuPDF's vulnerable range to versions before 1.28.5, pointing affected users toward upgrading.