Adobe Reader Zero-Day Exploited via PDF for 4 Months, Unpatched RCE Still Active
Contents
EXPMON’s Haifei Li and researcher Gi7w0rm disclosed that an unpatched zero-day vulnerability exists in Adobe Reader/Acrobat and has been actively exploited in real-world attacks since at least late November 2025.
The exploitation has continued for over 4 months without a patch, affecting all versions including the latest at the time of disclosure (Adobe Reader 26.00121367).
What’s Happening
Simply opening a malicious PDF triggers the attack.
A two-stage vulnerability chain is used to bypass Adobe Reader’s sandbox and ultimately achieve remote code execution (RCE).
The antivirus detection rate is extremely low at 6/77 (7.8%).
Confirmed samples are lure PDFs targeting Russian-speaking organizations, disguised as official documents related to gas supply, labor safety, and emergency response.
This is suspected to be a targeted attack aimed at energy infrastructure and government agencies.
Adobe had not commented or provided a patch at the time of disclosure.
Sandbox Bypass via Two-Bug Chain
The attack is a logic-based vulnerability chain that does not rely on memory corruption.
Bug 1: JavaScript Injection into Internal UI
Acrobat’s dialog rendering API fails to properly validate input strings.
From the PDF context within the sandbox, arbitrary JavaScript can be executed targeting internal APIs that should not be accessible.
This is a pure logic flaw rather than a buffer overflow — the sandbox fails to isolate “different contexts within the same process.”
Bug 2: Privilege Escalation via Prototype Pollution
Object.prototype.__defineGetter__() is used to hijack property definitions and seize control of an undocumented internal authentication API.
This grants unrestricted access to all internal Acrobat APIs.
Prototype pollution is a technique that tampers with properties of Object.prototype — the common ancestor of all JavaScript objects — to alter the behavior of every object.
Chaining the two bugs unlocks the following normally restricted APIs.
| API | Purpose |
|---|---|
util.readFileIntoStream() | Arbitrary file read |
RSS.addFeed() / removeFeed() | C2 (command-and-control server) communication and data exfiltration |
app.trustedFunction() | Further privilege escalation |
SOAP.streamDecode() | Base64 decoding |
Attack Flow
flowchart TD
A[Victim opens PDF] --> B[Stage 1: JSFuck obfuscated<br/>loader executes]
B --> C[Decodes attack code from<br/>hidden form fields]
C --> D[500ms delay to evade<br/>sandbox detection]
D --> E[Stage 2: 73936-char obfuscated<br/>JavaScript executes]
E --> F[Bug1+Bug2 chain achieves<br/>sandbox bypass]
F --> G[Fingerprints OS, AV software,<br/>Reader version]
G --> H[Sends beacon to C2<br/>via HTTP GET]
H --> I{Running in sandbox?}
I -->|Yes| J[Returns empty JS / no-op]
I -->|No| K[Stage 3: Receives AES-CTR<br/>encrypted JS from C2]
K --> L[Decrypts and evals / RCE achieved]
L --> M[Persistence via Registry Run key]JSFuck is an obfuscation technique that reconstructs arbitrary strings using only JavaScript operators, like ({}+[])[[+!+[]]], to evade API name detection by static analysis tools.
Fingerprinting Details
The following system information is collected before being sent to the C2.
| Item | Collection Method |
|---|---|
| Language setting | app.language |
| Reader version | getProdVersionString |
| OS version (detailed) | Binary analysis of ntdll.dll |
| Platform | app.platform |
| Antivirus products | Plugin enumeration |
| PDF local path | Document object |
The use of ntdll.dll to determine the OS version is notable.
While app.platform provides a rough OS identification, Windows build numbers (minor versions like 10.0.19041.1288) are extracted separately through binary analysis.
This is used for precise targeting to distinguish analysis sandbox environments from real endpoints.
C2 communication spoofs its User-Agent as Mozilla/3.0 (compatible; Adobe Synchronizer 23.8.20533) to blend in with legitimate Adobe Synchronizer traffic.
IOCs (Indicators of Compromise)
Network
| Type | Value |
|---|---|
| C2 IP 1 | 188.214.34.20:34123 (Cyprus, EDIS GmbH) |
| C2 IP 2 | 169.40.2.68:45191 (Latvia, VEESP) |
| Domain | ado-read-parser.com (registered February 6, 2025) |
| User-Agent | Mozilla/3.0 (compatible; Adobe Synchronizer 23.8.20533) |
Endpoint
| Type | Value |
|---|---|
| Registry persistence | HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Adobe Reader Synchronizer |
| Mutex | Global_MSIExecute, Global\AdobeCrashProcessorLocalLowLock |
| SHA-256 (v2) | 54077a5b15638e354fa02318623775b7a1cc0e8c21e59bcbab333035369e377f |
| SHA-256 (v1) | 65dca34b04416f9a113f09718cbe51e11fd58e7287b7863e37f393ed4d25dde7 |
The C2 infrastructure reportedly went offline after disclosure, but there is a possibility the campaign will continue with switched infrastructure.
Current Mitigations
Since no patch exists, interim workarounds are the only option.
Immediate Actions
- Do not open PDFs from suspicious senders
- Detect and block outbound traffic containing “Adobe Synchronizer” in the User-Agent on the network side
- Block C2 IPs (188.214.34.20, 169.40.2.68) and domain (ado-read-parser.com)
Alternative PDF Viewers
Browser built-in PDF viewers (Chrome, Firefox) do not have Acrobat’s JavaScript API and are therefore not affected by this exploit.
In high-risk environments, opening PDFs in a browser instead of Adobe Reader is an effective operational measure.
Temporarily switching to Sumatra PDF or Foxit Reader is also an option, though there is no guarantee that they are free of their own vulnerabilities.
As a related client-side attack, the Magento PolyShell RCE (/articles/magento-polyshell-rce) used a different approach (server-side polyglot files), but shares the tactic of “disguising code execution as a legitimate file.”
This article will be updated when Adobe releases an official patch.