An actively exploited zero-day in Adobe Reader has been compromising targets since at least November 2025. As of today, there is no patch. There is no CVE. Adobe has not publicly acknowledged the vulnerability.
The exploit was discovered on March 26, 2026 by EXPMON, a sandbox-based exploit detection platform built by security researcher Haifei Li. It works on the latest version of Adobe Reader (26.00121367) without requiring any user interaction beyond opening a PDF. That alone would make it noteworthy. What makes it significant is the class of vulnerability being exploited: privileged JavaScript APIs callable from sandboxed PDF code. The same architectural flaw that researchers documented in 2014.
Twelve years later, the trust boundary is still broken.
A Three-Stage Reconnaissance Platform
This is not a simple document exploit. It is a multi-stage intelligence collection operation designed to profile targets before delivering follow-on payloads.
Stage 1: JSFuck Loader. The PDF contains obfuscated JavaScript that uses character arithmetic to decode a payload hidden in a form field. It triggers via app.setTimeOut, a technique that introduces a 500-millisecond delay to evade behavioral sandboxes that only monitor initial execution.
Stage 2: Fingerprinting. The decoded payload is 73,936 characters of obfuscated JavaScript. It collects the target's language settings, Adobe Reader version, platform, OS version (extracted by parsing ntdll.dll binary data), antivirus status, and the PDF's file path on disk. It probes for Windows Server features and Citrix environments. All of this data is encrypted with AES-CTR and exfiltrated to command-and-control servers in Cyprus and Latvia.
Stage 3: Conditional Payload Delivery. The C2 server evaluates the fingerprint data and returns an AES-encrypted, zlib-compressed JavaScript payload for execution within Adobe Reader's context. For sandboxes and low-value targets, the server returns an empty JavaScript comment: //. For targets that match attacker-specified criteria, it delivers the actual payload.
This selective targeting has a critical implication: the most dangerous payloads, likely remote code execution and sandbox escape, may never appear in threat intelligence feeds. If only high-value targets receive the weaponized stage, sandboxes and security researchers will only ever see the reconnaissance phase. It follows the same exploit proliferation path that turned government iOS exploit chains into mass criminal tools: fingerprint first, weaponize selectively, and keep the most damaging capabilities out of researcher hands for as long as possible.
The campaign uses Russian-language lures referencing the oil and gas industry, suggesting targeted intelligence collection against specific individuals in the energy sector.
The Same Architectural Flaw, a Different Decade
The exploit abuses two privileged Acrobat APIs: util.readFileIntoStream() for arbitrary file access from the sandbox, and RSS.addFeed() for C2 communication and data exfiltration. These are not obscure, undocumented functions. They are documented privileged APIs that should never be callable from untrusted PDF JavaScript. This is the same pattern of weaponizing native platform features that SentinelOne documented across cloud environments: using the platform exactly as designed, just not for the intended purpose.
This is the same class of vulnerability that CVE-2014-0521 exploited over a decade ago: privileged API access from an untrusted execution context. In 2014, the sandbox allowed JavaScript in a PDF to call APIs that crossed trust boundaries. In 2026, the sandbox still allows JavaScript in a PDF to call APIs that cross trust boundaries. The specific functions changed. The architectural problem did not.
Adobe's response to the 2014 era of sandbox bypasses was to patch individual API misconfigurations rather than redesigning the trust model. The approach treated each bypass as a discrete bug rather than a symptom of a fundamentally flawed privilege architecture. The forensic analysis of the current exploit identifies at least seven privileged APIs being abused, including app.trustedFunction() for privilege escalation and SOAP.streamDecode() for base64 decoding. Each one represents a trust boundary violation that a properly designed sandbox would prevent by default.
The question nobody is asking: how many more privileged APIs are callable from untrusted PDF JavaScript? If the same class of bug has survived twelve years of patching, the answer is likely "more than Adobe knows."
Five Months of Detection Failure
The first malicious PDF sample (Invoice540.pdf) appeared on VirusTotal on November 28, 2025. At the time of discovery, it was flagged by 5 out of 64 antivirus engines, a 7.8% detection rate.
The C2 infrastructure paints an even worse picture. The domain ado-read-parser.com was registered on February 6, 2025, over fourteen months before public disclosure. At the time of the forensic analysis, it had a VirusTotal detection rate of 0 out of 94. Zero. The primary C2 IP address (188.214.34.20) also scored 0/94. The secondary IP (169.40.2.68) managed 1/94.
This is not a temporary detection gap. These indicators were available for months. Malicious samples were sitting in VirusTotal's corpus. The C2 domain was registered, active, and resolvable. The entire security industry's detection infrastructure, 94 vendors worth of it, collectively failed to flag a domain that was actively exfiltrating data from compromised targets. It is the same CVE gap that left GrafanaGhost invisible to every vulnerability scanner: when there is no CVE, there is no signal for the tools that enterprises depend on.
The exploit's evasion techniques are sophisticated but not unprecedented: anti-VM checks, anti-debug routines, Citrix environment detection, and sandbox-aware C2 responses. The User-Agent string masquerades as "Adobe Synchronizer," and persistence is achieved through a registry Run key with the same cover name. These are well-understood TTPs mapped to MITRE ATT&CK (T1203, T1059.007, T1547.001, T1082, T1573). Detection should be possible. It just did not happen.
For defenders, the most actionable indicator right now is the User-Agent header. Monitor for "Adobe Synchronizer" in outbound HTTP traffic. It should not appear in normal operations.
PDFs Still Get a Free Pass
Office macros lost their presumption of safety years ago. Microsoft disabled macros by default in documents from the internet. Enterprise security policies routinely block or sandbox Office files with active content. Users have been trained to be suspicious of Word documents asking to enable macros.
PDFs have received no equivalent reckoning. Despite supporting JavaScript execution, embedded multimedia, form actions, network callbacks, and now documented sandbox escape paths, PDFs are still treated as safe documents in most enterprise environments. It is the same pattern where trusted infrastructure becomes the attack surface: the thing you assumed was safe is the thing being exploited. Email gateways pass them through. Document management systems render them automatically. HR platforms process PDF resumes without sandboxing. Legal and financial workflows auto-open PDFs with zero human oversight.
Every one of those automated pipelines is a potential target for this exploit. The fingerprinting stage requires nothing more than the PDF being opened by Adobe Reader. No click. No prompt. No user decision. If your document processing infrastructure uses Adobe Reader or Acrobat to render PDFs, the exploit can fingerprint those systems silently, and the C2 server can decide whether the environment is worth a follow-on payload.
Adobe did release security bulletin APSB26-26 patching CVE-2026-27220, CVE-2026-27278, and CVE-2026-27221. That bulletin explicitly states Adobe is "not aware of any exploits in the wild for any of the issues addressed in these updates." Those are separate vulnerabilities. The EXPMON-discovered zero-day remains unpatched.
What to Do Right Now
There is no patch. There is no official workaround from Adobe. But there are steps that reduce exposure.
Disable JavaScript in Adobe Reader. Edit > Preferences > JavaScript > uncheck "Enable Acrobat JavaScript." This breaks the entire exploit chain at Stage 1. It will also break some legitimate PDF functionality, particularly interactive forms. For environments where PDFs are informational rather than interactive, this is the most effective mitigation available.
Monitor for the "Adobe Synchronizer" User-Agent. This string in outbound HTTP traffic is a direct indicator of compromise. Add it to your network detection rules.
Block the known C2 infrastructure. IPs 188.214.34.20 and 169.40.2.68; domain ado-read-parser.com. These will change, but blocking known indicators buys time.
Audit automated PDF processing. Identify every system in your environment that opens PDFs with Adobe Reader or Acrobat without human interaction. These are highest-priority targets for mitigation because they combine automatic execution with minimal monitoring.
Consider alternative PDF readers for sensitive workflows. The exploit specifically targets Adobe Acrobat's JavaScript engine and privileged API surface. Alternative readers that do not implement Adobe's JavaScript API are not vulnerable to this class of attack.
The broader pattern here extends beyond one zero-day. Adobe's PDF JavaScript sandbox has failed the same way, through privileged API access from untrusted contexts, for over a decade. Until that architecture is redesigned rather than patched incrementally, this class of vulnerability will keep recurring. The only question is how many more times it gets exploited before someone at Adobe decides that patching individual API calls is not a substitute for fixing the trust model.
