Multi-agent LLMs are scaling PDF engine zero-day discovery

At a glance

What this is: This is a security research post showing how multi-agent LLMs were used to scale zero-day discovery across PDF engines and cloud services, producing 13 vulnerability categories.

Why it matters: It matters because the same trust-boundary failures that expose web applications also affect identity-adjacent workflows, where untrusted configuration, embedded content, and delegated access can turn into account takeover or code execution.

By the numbers:

• The result was the discovery of 13 distinct vulnerability categories, ranging from critical XSS to OS Command Injection.

👉 Read Novee’s analysis of multi-agent LLMs for zero-day discovery in PDF engines

Context

PDF engines combine untrusted content, complex rendering logic, and delegated browser or server-side execution paths, which makes trust boundaries the real security problem rather than the document format itself. This post is about multi-agent LLMs as a research method, but the underlying issue is familiar to identity and security teams: when attacker-controlled input is treated as trusted state, the resulting blast radius can include account takeover, script execution, and server-side abuse.

The identity angle is strongest where embedded configuration, postMessage handling, and document annotations cross from one trust domain into another. That is why this research is relevant beyond application security teams: the same governance failure pattern appears wherever secrets, tokens, or session state are handed between systems without strong validation and isolation.

Key questions

Q: How should security teams govern PDF platforms that accept untrusted configuration or document metadata?

A: Treat PDF viewers and converters as application platforms with multiple trust boundaries, not as passive readers. Validate every configuration source, isolate document-derived metadata from privileged rendering paths, and review any browser sink that can execute script or load remote content. If a feature can change UI state, fetch a URL, or influence the DOM, it needs explicit control ownership.

Q: Why do document viewers become high-risk when they include remote configuration or embedded script paths?

A: Because attacker-controlled input can cross from a document or URL into rendering logic that the application treats as trusted. That creates a direct path from untrusted state to code execution, and in server-side workflows it can also expose internal services. The risk is not the file format itself, but the authority the platform grants to content.

Q: What do security teams get wrong about XSS in complex browser applications?

A: They often focus on payload filtering and miss the real issue, which is trust assignment across components. If a query parameter, message event, or annotation field can influence a DOM sink after re-rendering, the exploit will usually survive superficial sanitisation. Strong controls come from origin validation, output encoding, and eliminating unsafe rendering patterns.

Q: How should teams respond when a platform mixes browser UI, document parsing, and server-side conversion?

A: Separate the layers in your risk model and test each one independently. The browser UI needs origin validation and sink review. The parsing engine needs fuzzing and parser hardening. The backend conversion service needs SSRF controls, network segmentation, and strict egress policy. One control set cannot protect all three layers.

Technical breakdown

How multi-agent LLMs accelerate exploit pattern discovery

The article describes a human-agent symbiosis model. Human researchers first identify the structural pattern of a bug, then teach the agent what the exploit “scent” looks like. The agent can then search widely, test variations, and correlate similar failure modes across a large codebase. That is materially different from signature scanning, because it is reasoning about exploitability, not matching known indicators. In practice, the model scales discovery only after a human defines the trust boundary, the likely sink, and the expected data flow.

Practical implication: treat agentic research systems as force multipliers for human-led analysis, not as substitutes for threat modeling or verification.

Trust boundaries in PDF web viewers and server-side SDKs

Web-based PDF platforms often split responsibilities across an iframe UI, a client-side parsing and rendering engine, and optional server-side conversion services. Each layer introduces a different failure mode. Client-side configuration can become DOM XSS if query-string or postMessage inputs are trusted. Core rendering engines can fail in parsing or sanitisation. Server-side conversion can create SSRF or internal network reachability because the service fetches attacker-controlled content. The security lesson is that a PDF viewer is really an application platform with multiple control planes, not a passive file renderer.

Practical implication: map trust boundaries per layer and test each input path separately, especially configuration channels and document-derived metadata.

Why DOM sinks and message handlers stay exploitable

The post highlights two recurring patterns: data flows into dangerous DOM sinks, and origin validation is performed incorrectly. A field like uiConfig can direct the application to fetch remote JSON, which then influences rendering. A message handler can compare a user-controlled string instead of the browser-enforced event.origin, letting an attacker impersonate a trusted sender. In both cases, the bug is not simply XSS. It is a control failure in how trust is assigned, propagated, and rechecked across browser boundaries.

Practical implication: validate the source of every cross-frame or cross-origin command, and treat any innerHTML or script injection path as a review blocker.

Threat narrative

Attacker objective: The attacker’s objective is to convert untrusted PDF or message inputs into code execution, account takeover, or backend abuse within a trusted application origin.

1. Entry begins with attacker-controlled configuration, embedded content, or cross-origin messages being accepted by the PDF platform as if they were trusted inputs.
2. Escalation occurs when those inputs reach DOM sinks, script-loading paths, or server-side fetch logic without sufficient validation or encoding.
3. Impact is arbitrary JavaScript execution, stored persistence in annotations, SSRF, filesystem exposure, or command execution depending on the vulnerable layer.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Multi-agent LLMs are becoming a force multiplier for exploit discovery, not a replacement for security judgment. The research shows that human analysts still need to identify the vulnerable pattern, the relevant trust boundary, and the exploit shape before the agent can search at scale. That makes agentic research useful for coverage, but only where the underlying reasoning has been disciplined by human expertise. Practitioners should expect better discovery throughput, not automated certainty.

PDF platforms expose a classic trust-boundary problem that security teams often under-model. A viewer is not just a file parser. It is a browser application, a document-processing engine, and often a server-side transformation service wrapped together, which creates multiple paths from attacker-controlled data to privileged execution. The governance failure is assuming the document itself is the threat rather than the trust path around it. Practitioners should model each data ingress point as a separate control surface.

Configuration channels and annotation fields are identity-adjacent attack paths because they can carry trust across systems. When a query string, postMessage payload, or document annotation influences rendering or script execution, the platform has effectively granted authority to untrusted input. That is a familiar pattern in NHI governance too: tokens, secrets, and delegated permissions become dangerous when origin, scope, and lifecycle are not enforced. Practitioners should review any feature that lets content carry state across boundaries.

Exploit scaling changes the economics of vulnerability research, which will pressure defenders to improve input isolation. The article’s named concept is exploit reasoning at scale, meaning structured vulnerability discovery driven by agents that generalise from one trusted pattern to many similar surfaces. That raises the bar for web application and PDF platform hardening, because attackers no longer need a unique manual breakthrough for each target. Practitioners should assume repetitive control failures will be found quickly once one example is taught to an agent.

From our research:

• The result was the discovery of 13 distinct vulnerability categories, ranging from critical XSS to OS Command Injection, according to LLMjacking.
• The same research found that attackers attempted access to publicly exposed AWS credentials within an average of 17 minutes, showing how quickly secret exposure can turn into abuse.
• The pattern aligns with our AI LLM hijack breach analysis, where stolen cloud credentials became the enabling layer for downstream AI compromise.

What this signals

Exploit reasoning at scale: once a human identifies a reliable trust-boundary pattern, agents can generalise that pattern across many implementations faster than traditional manual review. For practitioners, that means code review and runtime validation need to assume attackers can industrialise discovery, not just exploit a single bug.

Security teams should expect browser-delivered applications with embedded document handling to remain attractive targets because they combine rich input channels with privileged rendering. The practical response is to reduce the number of places where untrusted state can influence execution, and to harden the remaining paths with layered validation, encoding, and isolation.

Where a platform also handles credentials, sessions, or delegated access, the identity impact grows quickly. Security programmes should connect application security findings to IAM and NHI governance so that unsafe configuration channels, token leakage, or account takeover are assessed as one control problem rather than separate alerts.

For practitioners

• Audit cross-origin configuration channels Inventory every query-string, postMessage, JSON config, and fragment-based input that can alter rendering or execution in browser-delivered applications. Validate sender origin, schema, and allowed values before the data reaches UI state or script-loading logic.
• Block dangerous DOM sinks in code review Treat innerHTML, script creation, DOMParser to HTML transitions, and unsafe SVG handling as review-blocking patterns unless they are paired with robust sanitisation and encoding. Re-test any component that re-renders user-controlled fields after state changes.
• Separate document metadata from trusted state Keep annotation fields, author names, titles, and document-derived attributes out of privileged rendering paths unless they are strictly encoded and isolated. Assume metadata is attacker-controlled even when it arrives inside an otherwise legitimate file.
• Model server-side conversion as an exposed service If your PDF workflow fetches remote content, renders HTML, or transforms files on the backend, test it for SSRF, internal resource reachability, and command injection. Apply allowlists and network egress controls before the service is placed in production.

Key takeaways

• Multi-agent LLMs can accelerate exploit discovery, but only after humans identify the trust boundary and failure pattern worth scaling.
• PDF viewers, annotation flows, and server-side conversion services create multiple paths from untrusted input to script execution or backend abuse.
• Security teams should focus on validation, output encoding, and isolation across every layer where document content can influence trusted state.

Key terms

• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• DOM sink: A DOM sink is any browser API or rendering path that can place untrusted data into executable or dangerous HTML context. Examples include innerHTML, script creation, and unsafe SVG handling. If untrusted input reaches a sink without encoding or sanitisation, the result can be script execution.
• Server-side conversion service: A server-side conversion service transforms user content into another format, such as HTML to PDF or PDF to thumbnails, on behalf of a web application. These services often fetch content, parse complex files, and interact with internal resources, which makes them attractive targets for SSRF and injection attacks.
• Agentic exploit discovery: Agentic exploit discovery uses AI systems that can reason over code, test variations, and expand on human-identified patterns to find vulnerabilities at scale. The method is most effective when humans provide the exploit model and the agents handle breadth, repeatability, and variation.

What's in the full report

Novee's full article covers the technical detail this post intentionally leaves for the source:

• RCA walkthroughs for each vulnerability category, including the exact sink and source paths in Apryse and Foxit.
• Payload design details showing why standard SVG and postMessage protections failed in the tested code paths.
• Agent workflow notes on how human researchers taught the model to recognise vulnerability patterns and expand coverage.
• Appendix-level findings across 16 named issues, including severity and affected components.

👉 The full Novee post covers the exploit chains, sink analysis, and agent workflow in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It is designed for practitioners who need to connect identity controls to broader security engineering and governance programmes.