CyberWire Daily - When “safe” documents aren’t. [Research Saturday]

Episode Date: March 28, 2026

Omer Ninburg, CTO of Novee Security, joins us on this episode of Research Saturday to discuss their work on "From PDF to Pwn: Scalable 0day Discovery in PDF Engines and Services Using Multi-Agent LLMs." Historically, Portable Document Formats – the immutable, localized PDF – was once considered a “safe” component inside enterprise environments. That is no longer the case. To demonstrate how PDF services and engines can be exploited, the team at Novee used their proprietary, multi-agent LLM system to uncover vulnerability patterns, and systematically scale them into a broad discovery campaign across two PDF vendor ecosystems. The research uncovered 16 verified vulnerabilities across client-side PDF viewers, embedded plugins, and server-side PDF services. The research and executive brief can be found here: ⁠From PDF to Pwn: Scalable 0day Discovery in PDF Engines and Services Using Multi-Agent LLMs Hacker-Trained AI Discovers 16 New 0-Day Vulnerabilities in PDF Engines Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyberwire Network, powered by N2K. When WestJet first took flight in 1996, the vibes were a bit different. People thought denim on denim was peak fashion, inline skates were everywhere, and two out of three women rocked, the Rachel. While those things stayed in the 90s, one thing that hasn't is that fuzzy feeling you get when WestJet welcomes you on board. Here's to WestJetting since 96. Travel back in time with us and actually travel with us at westjet.com slash 30 years.

Hello everyone and welcome to the CyberWires Research Saturday. I'm Dave Bittner and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems and protecting ourselves in our rapidly evolving cyberspace. Thanks for joining us. PDF engines are something that a lot of companies embed into their applications and then if you have a vulnerability in one PDF engine, so as a third-party attack,

you can compromise lots of companies and customers just by them integrating those PDF engines inside of their applications. That's Omer Ninberg, CTO of Novi Security. The research we're discussing today is titled from PDF to Pone. So before you all brought AI into this process, What did you all do to manually identify the issues inside of some of these PDF viewers? What made you think there's something deeper here? This is worth pursuing. When we start to investigate any application, you don't know if there is a vulnerability or not.

But you always presume that there is. The mindset of a vulnerability researcher is there's always another vulnerability. There is still something that nobody else has found before, and if you keep on digging, you'll find it or find traces that will lead you to the correct way. We didn't start this whole process because we thought we're going to find thousands of vulnerabilities, but we wanted to understand what's the limits that we can do with AI. And then we just started with the first engine, which was a PDF trend by Uprise, because we found a few of our customers that had that engine. Well, let's walk through it together.

It can take us through the story of how you all dug into these and what sorts of things started to be unveiled for you. So I think the first thing that once we started that we found out, that a lot of the engines, or if I'll talk specifically about PDF, the engine itself is embedded in the engine. the application as an eye frame. What that means is any application that uses that engines in order to render PDFs, for example, it needs to communicate with that iFram via post message or something like that. And we started to investigate the trust layers between the application itself, the

hosting application, which is unknown because it can be any application. And the engine of PDFTron or the embedded JavaScript in the side of the iFframe, once we try to understand all the connectivity between the two, we found interesting post messages that

the parent of the iFram sends to the iFram itself in order to initiate it. So for example, one of the things that we found that there's a parameter that's unrequired, but you can't

provide it and it has UI configurations that changes the way that the engine displays the rendering application. So think about it, the PDF engine, what it is, is a place where you can edit files, add annotations, put comments, add signing, and things like that. And once we started to investigate all the inputs that are available, and we found something that's undocumented, but it had something that appeared to be a very massive changer to the application itself, we just started to dig deeper and deeper. And this whole thing is obfuscated minified JavaScript, which is always nice.

And when we started to dig deep and deeper and, deeper, what we found is that some of the inputs that you're able to provide from the configuration, the external configuration, we have the post message, it gets into a sync that just evaluates JavaScript. It didn't end there. We still needed to bypass some kind of mechanisms because we were able to inject JavaScript code into an image tag, but we couldn't supply, let's say, for SVG, we couldn't supply JavaScript inside the SVG. And then there we did something that was also very nice.

Inside the SVG, we embedded HTML, the DOM processor. Once it saw that we're in the context of SVG, and then we're again in the context of HTML. so didn't parse the internal context of HTML as SVG, and then all the bypasses that were in the code, we just bypassed them altogether. And then we found a way to execute JavaScript, which was really nice.

Must have been an exciting moment. Yeah, for sure. Now, in the research you talk about this problem of scaling. You found these things manually, but then you had to go back and say, can we do this again and again at scale? Why is that so difficult in these dynamic applications? The places where scaling is a lot easier

is when code is just code. And programs are statically by nature, so it's a lot easier because then you have a very distinct path from sync to source. That means from user input into a dangerous function. if it's easy to go and draw that path, so it's usually easy to create an exploitation and then prove that it's a vulnerability.

But in dynamic applications, and most single-page application and modern applications are dynamic by nature, it's very, very hard to understand how you connect the dots. So in JavaScript, a lot of the times you have objects or you have tables and functions that call entries inside of tables, that call different entries of different tables and like indexes all over the place and everything is dynamic.

And the only place that the actual code flow can be investigated is actually at runtime. And that's something that, let's say the old tools, it was very difficult for them to understand. And in order to find vulnerabilities, in that case, you actually need to live in runtime. You need to run on real applications that are actually running now. And then you need to understand how to add tracing or instrumentation to the application itself in order to be able to investigate them or give AI or any code, any program, the tools in order to investigate in real time. We'll be right back.

At Desjardin, our business is helping yours. We are here to support your business through every stage of growth, from your first pitch to your first acquisition. Whether it's improving cash flow or exploring investment banking solutions, with Desjardin business, it's all under one roof. So join the more than 400,000 Canadian entrepreneurs who already count on us, and contact Desjardin today. We'd love to talk.

Business. Where are my gloves? Come on, heat. Winter is hard, but your groceries don't have to be. This winter, stay warm. Tap the banner to order your groceries online at voila.ca. Enjoy in-store prices without leaving your home. You'll find the same regular prices online as in-store.

Many promotions are available both in-store and online, though some may vary. One of the things that caught my eye in the research, when you all were going to the process of, of teaching your LLM agents. You say that the edge wasn't just running LLMs on code. You describe it as embedding elite researcher instincts. What does that really mean in practice? Yeah, so in practice, if you look for, again, sinks and sources, as I said before,

you'll find tons of potential links and tons of things that you should look for. But when somebody that knows how to research vulnerabilities and done it for years, so they just have instincts of what's more important than the other things. When you go into a specific path, where are the hurdles that you will probably meet and how do you need to mitigate them? If you're blocked, let's say what I explained before with the SVG and then HTML inside it and then another SVG inside of it.

So that's like a bypass technique that you need to know about. And in order to do or to create an agent that's able to do that, you need to give it tons of tricks and intuition. And we actually train our agents on those intuitions and we try to navigate their preferred path to paths that actually correlate to finding more vulnerabilities. How do you teach an agent to think in terms of these trust boundaries instead of just like pattern matching?

That's something that we didn't cover in the blog itself, but we are going to provide another blog that's a lot more AI related. Can you give us a preview? Yeah, yeah, for sure, no problem. Like what we need to do in order to be able to do something like that, we need data. In vulnerability research of real applications, data is actually environments. So what we need is hundreds or thousands of environments with vulnerabilities that the

agent didn't learn on because we don't want the environments to be contaminated. They need to be something that the agents don't know. and then we actually just give them the task, let's say, find an SSS in this specific part of the application, and we do that across thousands of applications, and that's our data. And it's not a single action, but it's an iterative motion that the goal is at the end

to find a vulnerability. And once we have tons of data and traces, So after we have all that, we can actually optimize the path and quantify it. What changes can we make in order to make the agent better? And what does it mean better? It just means that statistically it finds more vulnerabilities. You all describe this as a collaborative swarm. You talk about tracer, resolver, and bypass.

Can you explain that to us? You can have a generic agent that does everything, but like most things, if you have something generic, then it's not specialized. So the way we try to tackle that task is we do create specialized agents, and we do have flows that match the way that researchers research. So, for example, we start by investigating what are all the sinks?

What is all the attack surface? So syncs is something actually pretty far, pretty advanced, but we start by understanding what is the attack surface that an attacker can have. And after we have that, so we can continue and then ask what are all the sinks that are available in the code. We don't have code all the time,

but if we have, that's great. And then we try to create hypothesis that connect sinks to source, because if you have a connection that it means you have a vulnerability, but let's say we did that, then we have to optimize on actually creating an exploit. And there is a big difference between a potential connection,

sync to source, and actually working exploit in a live environment. And each tasks, from the tax that I just described requires different a bit of a different mindset. So let's say for creating the exploitation, what we understood is what you actually need

is a very good coding agent because creating an exploitation is actually creating code. We need to create a POC script that proves that what we've done actually works. but in the previous steps, let's say finding sinks inside of a source file, that's something that you can do statically. But connecting it to dynamic patterns,

that's something very hard. So there you need an agent that's very good at instrumentation and reading logs. And each different task requires different skills that the agent needs to embed inside itself. you all make a claim. It's a strong claim that most AI security tools produce vibes, not actual proof. But you say your approach is different.

What distinguishes what you all are doing there? Yeah, I think that our end product is not an assumption or like a claim that we have a vulnerability. and our platform, what we actually strive for and provide to our customers is full validation that we have of honorability. And the way that we are able to provide full validation is by actually creating reproducible code that proves something is vulnerable. So let's say if we're talking about IDOR, for example, so we prove that from one user context,

you can access data from a different user context. And the way to prove that is writing a code that logs in has a user context. And then being able to provide some kind of request, for example, and then extract data of a different user. And that's something that's verifiable. And if we do XSS, for example, so we prove it by instrumenting the browser, for example, and then validating that we were able to spawn an alert box, for example.

So the proof that we provide is actual something that you can just take, run, and then you'll say, ah, yeah, this makes sense. It does exactly what I would expect it to do, and it's not just a very nice hypothesis. From a defender's point of view, what should security teams take away from this research? This research is really talking about offensive security and how to find vulnerabilities. But I think in today's world, you don't have the privilege to not use a tool like this or use AI in order to look for vulnerabilities yourself inside your applications and even the most niche ones.

Because if once you could have thought of why should an attacker look inside some niche place and do whatever, maybe it made sense, okay, but it's still something that's high effort. And if today there is a tool that can find vulnerabilities that yesterday were impossible to find that scale and you're as a defender, you're not using that tool to discover those before. with the bad guys. So you're going to be in trouble. So from a defender point of view, I think this research and other researchers, research in the same field, just proves that defenders must move a lot quicker than before because it's just easier now to automate and scale everything. Our thanks to Omar Ninberg from NoVe Security for joining us. The research is titled from PDF to Pone. We'll have a link in the show notes. And that's Research Saturday, brought to you by N2K CyberWire.

We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you like our show, please share a rating and review in your favorite podcast app. Please also fill out the survey in the show notes or send an email to Cyberwire at n2K.com. This episode was produced by Liz Stokes. by Elliot Pelsman and Trey Hester. Our executive producer is Jennifer Ibin. Peter Kilby is our publisher, and I'm Dave Bittner.

Thanks for listening. We'll see you back here next time. Getting ready for a game means being ready for anything. Like packing a spare stick. I like to be prepared. That's why I remember, 988, Canada's Suicide Crisis Hubline. It's good to know, just in case. Anyone can call or text for free confidential support from a train responder any time.

988 suicide crisis helpline is funded by the government in Canada.