How a PDF profiled your system before deciding whether to attack it

The Context

Adobe Acrobat Reader is one of the most widely deployed desktop applications on the planet. It is the default PDF viewer for millions of enterprise workstations, used daily by employees in finance, legal, government, healthcare, and energy. Its ubiquity is precisely what makes it a high-value target: a working exploit against Acrobat Reader is a working exploit against a significant fraction of the world's knowledge workers.

The JavaScript engine embedded in Acrobat Reader exists for legitimate reasons. PDF forms use it to validate inputs, calculate totals, and automate workflows. But that engine is also a full-featured scripting environment, and like any scripting environment, it can be turned against the user if the underlying code has a flaw.

The exploitation began in November 2025, but Adobe's disclosure on April 11, 2026 was the first public indication the vulnerability existed. Organizations had no way to know they were targeted for at least five months.

The Attack, Phase by Phase

Phase 1: Silent Delivery and Prototype Pollution Trigger

The attack begins with a crafted PDF. The malicious JavaScript inside it is hidden in a form field and encoded using JSFuck (which rewrites any JavaScript using only six characters) and encrypted with AES-CTR. This combination made the payload unrecognizable to most antivirus engines: as few as 5 out of 64 engines on VirusTotal flagged the file at the time of discovery.

The PDF uses a standard mechanism called /OpenAction to execute the JavaScript automatically the moment the file is opened. No macros. No prompts. No clicks. The prototype pollution flaw in Reader's JavaScript engine then allows the script to break out of its normal boundaries and gain access to privileged APIs that are supposed to be off-limits to document-level scripts.

Phase 2: System Fingerprinting and Data Exfiltration

With privileged access established, the exploit calls util.readFileIntoStream(), an Acrobat API normally used for document processing, to read arbitrary files on the victim's system. It reads system libraries like ntdll.dll to extract the OS version, language settings, exact Reader version number, and local file paths.

That reconnaissance package is sent to an attacker-controlled server using a second abused API, RSS.addFeed(), designed for subscribing to news feeds. The outbound traffic is disguised with the User-Agent string Adobe Synchronizer, which looks like routine Adobe software activity to any network monitoring tool that does not inspect traffic deeply.

The two known C2 servers were 169.40.2.68:45191 and 188.214.34.20:34123. Both used previously unseen IP addresses. The second server's port was firewall-filtered to be invisible to internet-wide scanning tools like Shodan.

Phase 3: Selective Payload Delivery to High-Value Targets

The attacker's server evaluates the fingerprint it received and makes a decision about each victim individually.

Victims who do not meet the attacker's criteria receive a response containing only //, an empty JavaScript comment. No payload, no trace. Automated sandbox tools receive this empty response and classify the file as benign. The file passes through email security gateways with a clean bill of health.

Victims who do meet the criteria receive an encrypted JavaScript payload capable of full remote code execution (RCE) or sandbox escape (SBX). Remote code execution means the attacker can run any program on the victim's machine. Sandbox escape means the attacker can break out of Reader's own security containment layer entirely.

EXPMON researcher Haifei Li, who discovered the exploit, modified the malicious PDF to connect to his own server and confirmed that a returned JavaScript payload executed successfully inside Reader. He also confirmed the exploit could read and exfiltrate a local image file from the system32 directory without any second-stage payload at all.

Phase 4: Patch, Disclosure, and Continued Development

EXPMON's Haifei Li published his technical findings on April 7 to 9, 2026. Adobe released an emergency out-of-band patch, security bulletin APSB26-43, on April 11 with a Priority 1 rating, requiring enterprise deployment within 72 hours. CISA added CVE-2026-34621 to its Known Exploited Vulnerabilities catalog on April 13, 2026, requiring U.S. federal agencies to patch by April 27.

Both known C2 servers went offline after public disclosure. Forensic analysis of C2 server logs found a /s12 endpoint targeting newer Reader versions, suggesting the threat actor was already developing a third variant before the patch arrived.

What Made This Possible

1. A JavaScript engine with privileged API access. Adobe Reader's embedded JavaScript engine had access to APIs that could read local files and make outbound network connections. The prototype pollution flaw allowed document-level scripts to reach those APIs without authorization. Any application that embeds a capable scripting engine inherits that engine's full vulnerability class, including attack types historically associated only with web browsers and servers.

2. Security tools tuned for the wrong signals. Email gateways, sandboxes, and antivirus engines are built to detect behavioral indicators: macro execution, link clicks, known malicious signatures, suspicious process launches. This exploit triggered on file open, used only legitimate built-in APIs, added a 500-millisecond execution delay to outlast time-limited sandbox analysis, and returned empty responses to automated scanners.

3. A five-month detection gap with no feedback loop. The earliest known malicious sample was uploaded to VirusTotal on November 28, 2025. The patch arrived April 11, 2026. During those four-plus months, the exploit was publicly visible on a platform used by security researchers worldwide, yet the low detection rate meant no alarm was raised.

The attack did not succeed despite being visible. It succeeded because visibility without detection is not protection.

What Should Have Stopped This

Every defense that would have meaningfully limited this attack shares one trait: it does not depend on recognizing the malicious payload.

• Application update enforcement. The patch closes the prototype pollution flaw entirely. The exploit was in the wild for five months before a patch existed, but the patch has existed since April 11, 2026. Unpatched systems remain vulnerable today.

• Network egress filtering. Blocking or alerting on outbound connections from desktop applications like Adobe Reader to arbitrary IP addresses on non-standard ports would have interrupted the exfiltration step. Reader has no legitimate reason to initiate outbound connections to unknown servers.

• User-Agent string inspection. Filtering or alerting on HTTP/HTTPS traffic containing the Adobe Synchronizer User-Agent string from endpoints where no legitimate Adobe synchronization process is running is a specific, actionable detection rule that does not require recognizing the payload at all.

• Behavioral application controls. Policies that prevent Reader from spawning child processes or reading files outside expected directories would have limited what the exploit could accomplish even after the prototype pollution triggered.

The Takeaway

This attack is a precise illustration of how detection systems can be selectively blinded by an attacker who understands what those systems are looking for. The exploit was not invisible. It was on VirusTotal. It was using real network infrastructure. It was making real outbound connections. But it was designed, at every step, to look like something legitimate: a normal PDF, a normal API call, a normal Adobe network request, a normal empty response to a scanner.

The same pattern appeared in the Axios supply chain attack covered in a prior CyberBytes Daily post: malicious code used legitimate infrastructure that security tools trusted by design. Here, the attacker used legitimate PDF APIs and network traffic patterns that security tools had no reason to flag. The meta-pattern is consistent: when an attacker operates inside a trusted channel, tools that rely on recognizing malicious content fail. The defense has to shift to controlling what trusted channels are allowed to do, not just watching what they carry.

Pattern to remember: A tool that profiles its target before attacking can defeat any defense that depends on analyzing the attack payload, because high-value targets receive a payload and everyone else receives nothing.

What changed: Detection systems can be selectively blinded by attackers who control what those systems see, turning the security tool's own trust model into a filter that hides the attack.

The Technical Mechanism

CVE-2026-34621 is classified as CWE-1321 (Improperly Controlled Modification of Object Prototype Attributes), commonly called prototype pollution. In JavaScript, every object inherits properties from Object.prototype, the root prototype of the object hierarchy. If an attacker can write to Object.prototype (for example, via an unsanitized property assignment using __proto__, constructor, or prototype keys), those injected properties propagate to every object in the runtime, including internal engine objects.

In Adobe Reader's embedded JavaScript engine (based on a modified V8 or SpiderMonkey variant), the prototype pollution allowed the exploit to override internal property checks that gate access to privileged Acrobat-specific APIs. Specifically, the exploit gained unauthorized access to:

• util.readFileIntoStream(path): Reads arbitrary files accessible to the Reader process into a stream object. Used here to read ntdll.dll and other system libraries for OS and version fingerprinting, and to exfiltrate arbitrary local files.
• RSS.addFeed(url): Designed for RSS feed subscription. Abused here to make outbound HTTP requests to attacker-controlled C2 infrastructure and to receive and execute returned JavaScript.

The exploit payload was encoded using JSFuck-style character substitution and encrypted with AES-CTR before embedding in the PDF's AcroForm structure. The /OpenAction dictionary entry caused automatic execution on document open. A 500-millisecond setTimeout delay was added to outlast time-limited sandbox analysis environments.

The C2 communication used the HTTP User-Agent string Adobe Synchronizer. The primary C2 was 169.40.2.68:45191 and the secondary was 188.214.34.20:34123. The secondary port was firewall-filtered to block internet-wide scanners. The server returned // (an empty JavaScript comment) to non-qualifying targets and sandbox environments, and returned an AES-encrypted JavaScript payload to qualifying targets. C2 server logs revealed a /s12 endpoint indicating active development of a third exploit variant targeting Reader v25.x builds.

PDF metadata was intentionally sanitized: creator tool set to PyMuPDF, document title set to Blank Page, language set to en-US.

CVE and Advisories

• CVE-2026-34621: Adobe Acrobat and Reader Prototype Pollution Vulnerability. CVSS score 8.6 (revised from 9.6 on April 12, 2026; attack vector adjusted from Network to Local to reflect the requirement for a user to open the file).
• Adobe Security Bulletin APSB26-43: Vendor advisory confirming active exploitation, Priority 1 rating, and patched version numbers.
• CISA KEV Catalog Entry, April 13, 2026: CISA SSVC assessment rated Technical Impact as "total" and Exploitation as "active."

MITRE ATT&CK Mapping

Indicators of Compromise

Known malicious file names: Invoice540.pdf, yummy_adobe_exploit_uwu.pdf.

Known C2 infrastructure: 169.40.2.68:45191 (primary), 188.214.34.20:34123 (secondary). Both servers went offline after public disclosure on April 11-13, 2026. Infrastructure rotation should be assumed; these IPs are no longer active but may appear in historical network logs.

Key network indicator: Any HTTP or HTTPS request containing the User-Agent string Adobe Synchronizer that does not originate from a known Adobe update or synchronization process. Help Net Security specifically recommended blocking all traffic containing this string as a detection rule.

Detection difficulty is high for the initial stage. The server-side victim filtering means that most automated sandbox and email gateway tools received empty // responses and classified the file as benign. Retrospective log analysis for the Adobe Synchronizer User-Agent string in the November 2025 to April 2026 window is the most actionable detection path for organizations assessing historical exposure.

Attribution

No confirmed attribution has been established by Adobe, CISA, or any named threat intelligence firm as of the patch date. Multiple indicators are consistent with a nation-state-linked Advanced Persistent Threat (APT) group. Both identified malicious PDF samples contained Russian-language decoy content referencing gas supply disruptions and emergency response in Russia's oil and gas sector, confirmed by malware researchers Giuseppe Massaro and Gi7w0rm. Forensic researcher N3mes1s described the operation as "high-precision espionage by a nation-state or professional APT group," citing intentionally anonymized PDF metadata, purpose-built C2 infrastructure with no prior reputation history, active version development (v3 in progress before patch release), and selective payload delivery consistent with targeted intelligence collection. No specific group name or nation-state has been formally attributed.

Primary Sources