In December 2025, threat researchers confirmed that attackers had been silently exploiting an unpatched vulnerability in Adobe Reader and Acrobat — no clicks required, no warning dialogs, no user error to blame. A specially crafted PDF lands in an inbox, the recipient opens it, and the exploit runs. As of disclosure, it worked on the latest builds. If your enterprise trusts PDFs — and nearly every enterprise does — this is an active problem on your attack surface right now.
This post breaks down exactly how the exploit works, what the attacker gains, how to detect it, and what defensive steps you can realistically implement before a patch arrives. No filler. No marketing language.
How the Adobe Reader Zero-Day Actually Works
The JavaScript Execution Problem
Adobe Reader supports embedded JavaScript — a feature designed to enable interactive forms and dynamic document behavior. The exploit weaponizes this by embedding heavily obfuscated JavaScript that executes automatically on document open, mapped to MITRE ATT&CK technique T1059.007 (JavaScript execution via client-side interpreter).
Critically, the attacker's script doesn't simply run in a sandboxed scripting environment. The vulnerability allows the script to call privileged Acrobat APIs that are supposed to be inaccessible to untrusted document content. Think of it as a JavaScript payload that picks a locked door — the door was supposed to stay locked, but the lock is broken.
What the Script Collects
Once those privileged APIs are accessible, the script can query the Reader context for:
- Active username and system hostname
- Operating system version and architecture
- Installed application list
- Network interface configuration
This maps directly to T1005 (local data collection) and provides an attacker with exactly the reconnaissance data needed to profile a target before deploying follow-on payloads. Researchers have described the exploit as a first-stage loader, meaning data exfiltration is not the endgame — it's the entry survey before RCE and sandbox escape.
Exploit Delivery: Targeted, Not Spray-and-Pray
This is not commodity phishing. Campaign characteristics align with T1566.001 (spear-phishing with attachment). The lure PDFs are tailored, likely referencing documents relevant to the specific target — invoices, contracts, regulatory filings, HR materials.
Why Targeted Delivery Matters for Detection
Defenders often calibrate email gateway rules around volume. Targeted spear-phishing campaigns deliberately stay below the noise threshold. A single malicious PDF sent to one employee in your finance team will not trigger a volumetric alert. It will look like a normal business communication.
Important: If your email security relies primarily on spam scoring and sender reputation, you may be blind to this campaign. PDF file inspection — including static analysis of embedded JavaScript streams — needs to be in your pipeline, not just attachment sandboxing.
Sophos published a forensic breakdown of the exploit's structure and JavaScript logic, which is directly useful for writing detection rules against the obfuscation patterns in the embedded scripts.
Detection Engineering: What to Look For
The table below maps each attack stage to detection opportunities. Not all stages are equally visible — defenders tend to see stage 1 or stage 5, but rarely stages 2–4 without dedicated tooling.
| Attack Stage | MITRE Technique | Detection Opportunity | Tooling |
|---|---|---|---|
| Spear-phishing delivery | T1566.001 | Email gateway, attachment inspection | SEG, CAS |
| PDF opened, JS executes | T1059.007 | PDF sandbox detonation, Reader process spawning child processes | Sandbox, EDR |
| Privileged API calls | T1203 | Reader making unusual API calls, process behavior anomaly | EDR telemetry |
| Data exfil from Reader | T1005 | Network connection from AcroRd32.exe, DNS queries to unknown hosts | NDR, FW logs |
| RCE / sandbox escape | T1055 | Unexpected process injection, Reader spawning shell processes | EDR, SIEM |
Your richest detection signal will come from endpoint telemetry (EDR). Look specifically for:
AcroRd32.exeorAcrobat.exespawningcmd.exe,powershell.exe, orwscript.exe- Network connections initiated by Reader to non-Adobe infrastructure
- Reader processes attempting to read from directories outside
%USERPROFILE%\Documents
Recommended Mitigations Before a Patch Ships
Adobe has not released a patch as of disclosure. That means defenders are operating in the gap, and mitigation requires active configuration choices — not passive waiting.
Disable JavaScript in Adobe Reader
Adobe Reader allows JavaScript to be disabled via the application preferences (Edit → Preferences → JavaScript → uncheck "Enable Acrobat JavaScript"). For enterprise environments, this setting can be enforced via Group Policy or the Adobe Customization Wizard. This is the single most effective immediate control.
Pro Tip: JavaScript in PDFs serves legitimate purposes in some workflows (interactive forms, calculation fields). Before pushing a blanket disable via GPO, audit which internal PDF workflows genuinely require it. In most organizations, the answer is fewer than you expect.
Enforce PDF Sandboxing
Reader includes a Protected Mode (sandboxing) that runs rendering in a low-privilege process. Verify this is enabled and not disabled by legacy application compatibility policies. Many enterprises quietly disabled Protected Mode years ago to fix a software conflict and never re-enabled it.
Deploy PDF Detonation in Your Email Gateway
Static scanning of PDF attachments is insufficient against obfuscated JavaScript. Dynamic analysis (sandbox detonation) forces the PDF to execute in an instrumented environment where behavioral indicators — API calls, network connections, child process spawning — are observable before delivery.
| Mitigation | Risk Reduction | Complexity | Cost |
|---|---|---|---|
| Disable PDF JavaScript (GPO) | High | Low | None |
| Enable Reader Protected Mode | Medium | Low | None |
| PDF sandbox detonation at email gateway | High | Medium | Vendor dependent |
| Network monitoring for Reader processes | Medium | Medium | EDR/NDR tooling |
| Patch (when available) | Definitive | Low | Standard patch cycle |
Framework Alignment
This incident maps to several controls across security frameworks:
- NIST CSF 2.0: DE.CM-1 (network monitoring), PR.PS-1 (configuration management)
- CIS Controls v8: Control 7 (email/web browser protections), Control 8 (malware defenses), Control 13 (network monitoring)
- ISO 27001:2022: A.8.7 (protection against malware), A.8.22 (filtering of web services)
For organizations under PCI DSS or HIPAA, this vulnerability is particularly relevant — both frameworks require prompt patching of known vulnerabilities and compensating controls when patches are unavailable.
Incident Response: If You Suspect Exposure
If a user reported opening a PDF that behaved unexpectedly — Reader crashed, an unusual dialog appeared, or their system became slow after opening a document — treat it as a potential compromise.
Immediate steps:
- Isolate the endpoint from the network
- Preserve a forensic image before remediation
- Pull EDR telemetry for the affected host, focusing on Reader process activity in the window around the suspicious open
- Search your email gateway logs for the sender and any other recipients of the same attachment
- Query your NDR/firewall logs for outbound connections from Reader processes across the fleet
Consider the event a potential multi-stage intrusion, not merely a malware infection. If the exploit completed successfully, the attacker may have already delivered a second-stage payload. Containment scope should reflect that possibility.
Key Takeaways
- Disable JavaScript in Adobe Reader immediately using GPO or Acrobat's preferences, and document any workflows that require it as exceptions.
- Verify Protected Mode is active across your fleet — this may already be misconfigured.
- Enable behavioral PDF inspection at the email gateway; static file scanning will not catch this exploit.
- Hunt for AcroRd32.exe anomalies in existing EDR telemetry — lateral movement may have already occurred in targeted environments.
- Treat any suspicious PDF-opening event as a potential first-stage intrusion, not just malware execution.
- Monitor Sophos threat intelligence and Adobe's security advisory feed for the official patch and any IOC updates as the campaign evolves.
Conclusion
Zero-days exploiting ubiquitous enterprise software — particularly file formats like PDF that carry implicit trust — are among the hardest threats to defend against. The Adobe Reader vulnerability active since December 2025 is notable not just for the absence of a patch, but for the exploit's architecture: it collects, it profiles, and it chains. An organization that detects only the final RCE stage has missed the opportunity to interrupt the attack earlier.
The practical next step is not waiting for Adobe. It's auditing your PDF JavaScript policy, verifying Protected Mode is enforced, and reviewing your email gateway's PDF handling capabilities this week. Document your current state against the CIS Controls and NIST CSF mappings above. That audit will surface the gaps before an attacker does.
Frequently Asked Questions
Do I need to click anything inside the PDF for the exploit to run? No. The JavaScript executes automatically when the document is opened in a vulnerable version of Adobe Reader or Acrobat. There is no secondary interaction required, which is what makes this particularly dangerous in environments where users routinely open attachments.
Does this affect Adobe Reader on macOS and Linux, or only Windows? Confirmed samples work on the latest Adobe Reader builds across platforms at time of disclosure. You should treat all operating systems as potentially affected until Adobe's security advisory specifies otherwise.
Will disabling JavaScript break our existing PDF workflows? It depends on your environment. Standard read-only PDFs, contracts, and reports are unaffected. PDFs with interactive form calculations, dynamic field population, or submit buttons that use JavaScript will lose that functionality. Audit before deploying broadly.
We use a third-party PDF reader, not Adobe. Are we affected? This vulnerability is specific to Adobe Reader and Acrobat's JavaScript engine and the privileged API layer it exposes. Third-party readers (Foxit, PDF-XChange, browser-native renderers like Chrome's PDFium) are not affected by this specific vulnerability. However, PDFs that attempt exploitation will simply fail silently in those readers — they will not generate an alert.
How do we know if we've already been compromised?
Hunt in your EDR telemetry for AcroRd32.exe or Acrobat.exe spawning child processes (especially command shells), initiating outbound network connections to non-Adobe infrastructure, or reading from unusual file paths. Cross-reference against email gateway logs for PDFs received from external senders around the December 2025 timeframe onward. Absence of evidence is not evidence of absence — if your EDR retention is short, consider this a gap.
Enjoyed this article?
Subscribe for more cybersecurity insights.