cveadobeacrobat-readerzero-dayphishing

Adobe Reader Zero-Day CVE-2026-34621: Prototype Pollution + Use-After-Free Exploited Since November 2025

CVE-2026-34621 (CVSS 8.6) is a prototype pollution + use-after-free in Adobe Acrobat Reader's JavaScript engine. Exploited via malicious PDFs in phishing campaigns since November 28, 2025. CISA KEV April 13, 2026. Technical breakdown, IOCs, detection rules, and patch verification for the 134-day in-the-wild window.

Diego Diaz
8 min

TL;DR

CVE-2026-34621 is a critical (CVSS 8.6) prototype-pollution-to-use-after-free chain in Adobe Acrobat Reader's embedded JavaScript engine. An attacker delivers a malicious PDF; the moment a victim opens it in a vulnerable Reader build, obfuscated JavaScript triggers the use-after-free condition and executes arbitrary code with the user's privileges. The earliest in-the-wild sample was uploaded to VirusTotal on November 28, 2025; a second sample appeared March 23, 2026. Adobe shipped an emergency patch on April 8, 2026; CISA added the CVE to KEV on April 13, 2026; FCEB agencies were required to patch by April 27. The realistic 0-day window is at least 134 days, and the attack requires nothing more than "open this PDF."

What Happened

Adobe's emergency Acrobat Reader bulletin (APSB26-43) acknowledged active exploitation of CVE-2026-34621 alongside several adjacent fixes. The vulnerability lives in the JavaScript subsystem that Reader ships to support form interactivity, embedded actions, and document automation — a feature that has been the source of the majority of Reader's RCE history.

What's noteworthy here is the bug-class composition. Prototype pollution alone is an information-flow vulnerability — it lets an attacker mutate the prototype chain of JavaScript objects and influence later property lookups. By itself, it can leak data or change behavior. Combined with a use-after-free in the same engine — where freed memory is referenced again as if it were still valid — it becomes a remote code execution primitive: the attacker pollutes the prototype to control object metadata, frees the underlying object, and then dereferences the dangling pointer through a polluted property to land arbitrary code execution.

The exploit ships inside a PDF. PDFs containing JavaScript are not unusual; many enterprise workflows depend on form scripts. The malicious PDFs use standard obfuscation (string concatenation, eval-loops, mangled property names) to evade signature-based detection. Once the JavaScript runs, it harvests local environment data and pulls a second-stage payload over the network.

Why This Specific Bug Class Matters

Three properties make CVE-2026-34621 interesting beyond the immediate severity:

  • Open-and-execute, not click-and-execute. Some Reader CVEs require the user to interact with a form or click a malicious link inside the PDF. This one fires on document open, before any user interaction past double-clicking the file.
  • Email-deliverable. Phishing campaigns deliver the PDF as an attachment. Email gateways and DLP solutions inspect document content but rarely emulate Reader's full JavaScript engine. A polluted-prototype payload looks like ordinary JS to a static scanner.
  • Long 0-day window. 134 days between first observed exploitation and patch. Anyone who opened an attachment in that window from a non-trusted sender on a vulnerable build is a candidate for forensic triage.

Compare against the Reader CVE landscape: most months ship a Patch Tuesday batch of Reader fixes, but only a small fraction (single digits per year) make CISA's KEV. CVE-2026-34621 made KEV within days because exploitation was confirmed in active phishing campaigns targeting enterprise users.

Affected Versions and Patches

ProductVulnerable BuildsPatched BuildPlatform
Acrobat DC / Reader DCAnything below the patch line26.001.21411Windows + macOS
Acrobat 2024 (perpetual)Anything below the patch line24.001.30362Windows
Acrobat 2024 (perpetual)Anything below the patch line24.001.30360macOS

The patched 26.x builds rolled out on April 8, 2026 via Adobe's automatic update channel. Enterprise deployments using SCCM, Intune, or third-party patch management often lag the public channel by days to weeks; verify your installed build, do not assume.

Exploitation Timeline

DateEventSource
Nov 28, 2025First malicious PDF sample uploaded to VirusTotalVirusTotal telemetry
Dec 2025 – Mar 2026Active phishing campaigns against enterprise users in finance, legal, government verticalsPublic reporting
Mar 23, 2026Second distinct exploit sample observed in VirusTotalVirusTotal telemetry
Apr 8, 2026Adobe ships emergency patch (APSB26-43)Adobe security bulletin
Apr 13, 2026CISA adds CVE-2026-34621 to KEVCISA Known Exploited Vulnerabilities catalog
Apr 27, 2026FCEB compliance deadline (per BOD 22-01)CISA mandate

Net 0-day window: ~134 days. If your org allows email-delivered PDFs from external senders and you cannot prove every Reader endpoint was on the patched build at the moment of opening, treat suspicious attachments from that window as potentially compromised contact points.

Detection

1. Email gateway telemetry

The highest-signal detection layer is your email security gateway. Pull the attachment metadata for any inbound PDF in the November 2025 to April 2026 window and flag senders that have ever delivered a PDF later identified as malicious by VirusTotal. The IOC dimension worth more than file hashes is sender reputation drift: senders who only ever sent invoices and suddenly delivered a PDF with embedded JavaScript are worth a second look.

2. Endpoint process tree anomalies

Acrobat Reader does not normally spawn child processes during document rendering. A PDF that triggers a child cmd.exe, powershell.exe, wscript.exe, or any network-egress binary is high-confidence exploitation. A Sysmon rule:

<Rule groupRelation="or">
  <ParentImage condition="end with">Acrobat.exe</ParentImage>
  <ParentImage condition="end with">AcroRd32.exe</ParentImage>
</Rule>
<!-- alert on any child of Acrobat that isn't a known helper -->

3. PDF static analysis at the gateway

For email gateways and DLP, scan inbound PDFs for embedded JavaScript objects with prototype-mutation indicators. Free tools like peepdf, pdfid, and pdf-parser report on JavaScript object presence; combine with regex over the JS body for __proto__, constructor.prototype, or named-property mutation patterns. False positive rate is non-trivial — many legitimate PDFs use JS for forms — but stacked with sender-reputation signals, the precision is workable.

4. EDR / hunting query

For Microsoft Defender, Sentinel, or comparable EDRs, a hunting query catches the post-exploit beacon:

// Pseudo-KQL: Acrobat process making outbound network connection to non-Adobe domain
DeviceNetworkEvents
| where InitiatingProcessFileName in ("AcroRd32.exe", "Acrobat.exe")
| where RemoteUrl !has "adobe.com" and RemoteUrl !has "adobesc.com"
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessCommandLine

Mitigation

  1. Patch. Verify every Reader endpoint is at or above the patch line for its track. Do not trust "automatic updates are enabled" — push and confirm the build string.
  2. Disable JavaScript in Acrobat Reader for environments where it isn't required. Edit > Preferences > JavaScript > uncheck "Enable Acrobat JavaScript". For enterprise scale, deploy via Group Policy: HKLM\Software\Policies\Adobe\Adobe Acrobat\<version>\FeatureLockDown\bDisableJavaScript = 1. The cost: forms with scripts will not work. The benefit: this entire bug class is unreachable.
  3. Sandbox PDF rendering. Use Adobe Reader's Protected View / Protected Mode aggressively ("Files from potentially unsafe locations" → "All files"). On macOS, App Sandbox already constrains Reader; verify it's enforced.
  4. Email gateway content disarm and reconstruction (CDR). Many CDR products can strip JavaScript from inbound PDFs by default. Consider this for email from external domains.
  5. For incident response on suspected compromise: snapshot affected hosts before remediation. Inspect %TEMP%, browser cache, and persistence locations (HKCU\Software\Microsoft\Windows\CurrentVersion\Run, scheduled tasks, startup folders). Pivot from any opened-PDF event in your EDR's audit log to the file and the sender.

Frequently Asked Questions

Is the patch sufficient?

For CVE-2026-34621, yes. Adobe addressed the prototype pollution path and the use-after-free condition. The structural lesson — that PDF-embedded JavaScript is a sustained attack surface — is not solved by any single patch. Disabling JavaScript in environments that don't need it is the durable mitigation.

Are macOS Reader installs less affected?

The bug is in cross-platform JavaScript engine code. macOS users are equally vulnerable to the JavaScript path; macOS App Sandbox limits the post-exploit blast radius compared to a Windows install running as administrator. The bug class is the same; the impact is platform-dependent.

Does Foxit Reader, PDF.js, or a non-Adobe PDF viewer help?

Foxit and other commercial PDF readers ship their own JavaScript engines and have had separate (different-CVE) RCEs over the years. Browser-based PDF.js (Chrome, Firefox, Edge) is sandboxed inside the browser process and has a much narrower JavaScript scope; it is the safest choice for PDF rendering when you don't need form interactivity. The trade-off is feature parity for enterprise workflows.

How do I forensic-triage a suspected compromise?

(1) Identify the suspect PDF — pivot from opened-document events in your EDR logs. (2) Hash the PDF and submit to VirusTotal; a malicious PDF in this campaign will already have detections. (3) On the host, look for AcroRd32.exe or Acrobat.exe as the parent process of any non-Adobe binary. (4) Check user's recent persistence locations and recently created scheduled tasks. (5) Rotate any credentials the user typed into the host within the suspect window.

What's the realistic window of compromise?

134 days as a 0-day, plus typical enterprise patch lag (days to weeks beyond Adobe's release). Realistic outer bound: ~150 days. If you cannot prove a host was on the patched build during that window and the user opened external PDFs, that host is a candidate for triage.

Key Takeaways

  • Patch every Reader endpoint to the patched build for its track. Verify the build string; do not assume auto-updates worked.
  • The composition matters — prototype pollution + use-after-free in the same engine turns an information bug into RCE.
  • 134-day in-the-wild window. Forensic triage is worthwhile if your environment routinely opens external PDFs.
  • Disabling Acrobat JavaScript via GPO is the highest-leverage durable mitigation. Most enterprise PDF workflows do not need it.
  • The KEV listing means federal mandate exists; for private-sector orgs the signal is the same: this is the patch you can't defer.

Sable Offensive Research conducts authorized phishing-resilience assessments and Reader-deployment audits: PDF gateway DLP review, JavaScript-in-PDF policy hardening, and post-compromise tabletop exercises starting from a malicious-attachment delivery. Contact us if your org's email is the primary external attack surface and you want a focused review.

References

  • Adobe Security Bulletin APSB26-43 (April 8, 2026)
  • CISA KEV Catalog: CVE-2026-34621 (added April 13, 2026)
  • The Hacker News: Adobe Reader Zero-Day Exploited via Malicious PDFs Since December 2025
  • Help Net Security: Adobe issues emergency fix for Acrobat Reader flaw exploited in the wild
  • Penligent.ai: CVE-2026-34621 prototype pollution analysis
  • Malwarebytes: Simply opening a PDF could trigger this Adobe Reader zero-day