Adobe Acrobat Reader: CVE-2026-34621 Active Exploitation & Patching
CVE-2026-34621: Acrobat Reader Under Active Attack
Just saw the alert drop on CVE-2026-34621. Adobe has released an emergency out-of-band patch for Acrobat and Acrobat Reader. This one is nasty—CVSS 8.6 (High) and confirmed to be exploited in the wild. Successful exploitation allows for arbitrary code execution, which is basically a game-over for the user session.
Given how ubiquitous PDF handling is in most environments, this should be treated as a priority update today. If you can't patch immediately, you need to tighten your allow-lists.
Patch Verification
For those running fleet management, here is a quick PowerShell snippet to identify vulnerable versions (adjust version logic based on the specific patched release notes for your environment):
Get-ItemProperty "HKLM:\Software\Wow6432Node\Adobe\Product Transformers\*", "HKLM:\Software\Adobe\Acrobat Reader\*" -ErrorAction SilentlyContinue |
Select-Object PsChildName, DisplayVersion |
Where-Object { $_.DisplayVersion -lt "24.003.20100" }
Detection Logic
For the SOC folks, we should be hunting for suspicious child processes spawned by the Reader executable. Legitimate usage rarely spawns a shell or powershell directly.
DeviceProcessEvents
| where FileName in~ ("AcroRd32.exe", "Acrobat.exe")
| where InitiatingProcessFileName in~ ("AcroRd32.exe", "Acrobat.exe")
| where ProcessCommandLine contains "-EncodedCommand" or ProcessCommandLine contains ".ps1"
Who else is seeing active exploitation attempts targeting this specific vulnerability yet? I'm curious if the delivery mechanism is standard phishing maldocs or something more stealthy.
Thanks for the heads up. We just pushed the update via SCCM to our pilot group. We are seeing a lot of resistance from the design team regarding downtime, but the risk is too high. We are also blocking incoming PDFs on the email gateway that aren't sandboxed until the rollout is complete.
The KQL query is solid, but don't forget to look for Memory Injection indicators as well. We've seen similar Acrobat flaws used to load shellcode directly into memory without touching the disk to bypass AV. Look for suspicious process access grants granted by the reader process.
If you're an MSP, this is a 'wake up the on-call' kind of day. I'm using PDQ Deploy to hit the Critical servers first. One thing to note: the auto-update mechanism in Reader often fails if the user doesn't have admin rights, so make sure you force the install via system context.
Since Dana mentioned auto-update failures, use this PowerShell script to quickly verify patch compliance across your endpoints. It checks the registry directly, which is much faster than querying WMI:
Get-ChildItem 'HKLM:\Software\Adobe\Adobe Acrobat' -Recurse -ErrorAction SilentlyContinue | Get-ItemProperty | Where-Object { $_.Version } | Select-Object PSChildName, Version
Also, consider temporarily disabling PDF previews in your webmail gateways. We’ve noticed similar exploits triggering just from the preview pane before users even download the file.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access