From Documentation to Zero-day Vulnerabilities: LLM-Driven Fuzzing of JavaScript Engines in PDF Readers
This paper introduces PDFuzzer, a novel LLM-driven fuzzer that leverages large language models to infer API relationships and generate complex call sequences, thereby significantly improving code coverage and discovering 31 zero-day vulnerabilities in mainstream PDF readers compared to existing state-of-the-art tools.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine a digital document that does more than just sit on a screen; it can think, calculate, and react. This is the promise of the Portable Document Format, or PDF, when it is equipped with a built-in computer program called a JavaScript engine. Just as a physical book might have a hidden compartment that opens only when a specific page is turned, a PDF can contain code that runs inside the reader application, allowing for interactive forms, spell-checking, and dynamic menus. However, this power comes with a risk. If a hacker can trick this engine into making a mistake, they can potentially take control of the computer reading the file, stealing data or installing malicious software. For years, security researchers have tried to find these hidden traps by throwing random variations of documents at PDF readers, hoping to see the program crash. But this method is often like throwing darts in the dark; it misses the complex, specific sequences of actions required to trigger the most dangerous flaws.
A team of researchers at the University of California, Santa Barbara, has developed a new approach to this problem, moving from blind guessing to intelligent reasoning. They created a tool called PDFuzzer, which acts less like a dart thrower and more like a student who has thoroughly studied the instruction manual before attempting a task. Instead of relying on simple, isolated commands, this system learns how different parts of the PDF engine's programming language depend on one another. It understands that to perform a specific action, a user might need to set up a condition first, or that two different commands must use the exact same name to work together. By teaching a computer to read and understand the complex, written documentation of these software engines, the researchers were able to generate highly sophisticated test cases that previous tools simply could not conceive.
The core of this new method lies in how it handles the "rules" of the software. In the past, automated testing tools often struggled because they only understood basic connections, such as one command handing a result to the next like a baton in a relay race. They missed more subtle relationships, such as when two commands must use the same specific value to interact correctly, or when a command sets a hidden state that a later command relies on. PDFuzzer uses a large language model, a type of artificial intelligence trained on vast amounts of text, to read the official manuals and technical traces of the software. It then constructs a detailed map of how every function relates to every other function. It translates these written descriptions into strict logical rules, ensuring that when it generates a test, the parameters match perfectly. For instance, if a command requires a specific name to be used, the system ensures that the same name is used in the subsequent command that needs it, rather than guessing randomly.
To test their creation, the researchers applied PDFuzzer to three of the most popular PDF readers used around the world: Adobe Acrobat Reader, Foxit PDF Reader, and PDF-XChange Editor. They ran their tool for weeks, comparing its performance against the best existing methods used by security experts today. The results were striking. While the older tools managed to explore only a fraction of the software's internal logic, PDFuzzer reached significantly deeper, covering up to 48 percent more of the code. More importantly, this deeper exploration led to the discovery of 31 previously unknown security flaws, known as zero-day vulnerabilities. These were not minor glitches; many were serious issues that could allow an attacker to execute arbitrary code, essentially taking full control of a victim's computer, or to leak sensitive information. In contrast, the other tools combined found at most six such vulnerabilities during the same period.
The researchers did not stop at finding the bugs; they worked directly with the software manufacturers to fix them. Through a coordinated process, they disclosed the details of the 31 vulnerabilities to the companies responsible for the PDF readers. The industry responded quickly, with 26 of the issues confirmed and patched, and ten receiving official security identifiers to warn users. The researchers also received financial rewards, known as bug bounties, totaling $2,450 for their work. This outcome highlights the practical value of their approach: by automating the difficult task of understanding complex software relationships, they were able to find and fix dangers that human experts and older automated tools had missed.
A key part of the success was how the tool handled the vast amount of information in the software manuals. The documentation for these engines can be hundreds of pages long, filled with technical details that are difficult for a computer to parse automatically. The researchers found that simply asking an artificial intelligence to generate test cases from scratch was slow and often produced nonsense. Instead, they used the AI to act as a translator, converting the natural language of the manuals into precise, machine-readable rules. They broke down the process into steps: first, extracting the basic structure of the commands; second, inferring the hidden details for commands that were not fully documented; and third, using a mathematical solver to ensure that the generated test cases satisfied all the logical constraints. This hybrid approach, combining the reasoning power of artificial intelligence with the precision of mathematical logic, proved to be far more efficient and effective than relying on the AI alone.
The study also revealed that the most dangerous vulnerabilities often required a specific sequence of events that previous tools could not replicate. For example, one flaw involved a situation where a user interface element was created and then immediately deleted, but a later command tried to use it again. To trigger this, the test case needed to create the element, use it, delete it, and then try to access it again, all while ensuring that the names and values used in each step were identical. Older tools, which treated each command as an isolated event, could not generate this specific chain of events. PDFuzzer, by understanding the relationship between the commands, could construct the exact sequence needed to expose the flaw. This ability to model complex dependencies was the deciding factor in finding the majority of the new vulnerabilities.
Beyond the immediate success with PDF readers, the researchers suggest that their method could be applied to other areas of software security where detailed documentation exists. They tested their pipeline on the programming language used for Microsoft Word macros, a different but similarly complex environment, and found that the same types of relationships and dependencies existed there as well. This indicates that the challenge of understanding how software components interact is not unique to PDF readers, but is a widespread issue in modern computing. The ability to automatically turn written manuals into rigorous testing rules offers a new path forward for securing the software that powers our daily lives.
In the end, the work demonstrates that the future of software security may lie in teaching computers to read and understand the instructions we write for them. By bridging the gap between human-written documentation and machine-generated testing, the researchers have shown that we can find and fix dangerous flaws more quickly and thoroughly than before. The 31 vulnerabilities they uncovered serve as a reminder of how much complexity remains hidden in the software we use every day, and how much safer we can be when we have tools smart enough to find the cracks before the bad actors do. The process was not about magic or luck, but about building a system that could think through the logic of the software, ensuring that every test case was a meaningful attempt to break the system, rather than a random guess.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.