Emergency Patch: Adobe Acrobat RCE (CVE-2026-34621) Under Active Attack
Hey everyone, just getting the word out on CVE-2026-34621. Adobe dropped an emergency patch for Acrobat Reader today. This one is nasty—CVSS 8.6 and confirmed active exploitation in the wild.
The vulnerability allows for arbitrary code execution. For those managing fleets, ensure you are targeting the Continuous and Classic 2025 tracks. If you are relying on users to auto-update, I wouldn't count on it for this one given the criticality.
We are assuming this is likely another memory corruption issue based on previous trends, but until detailed analysis drops, we need to rely on behavioral detection. I’m currently deploying detection logic to catch Acrobat Reader spawning suspicious child processes, which is a tell-tale sign of exploitation.
Here is a quick PowerShell snippet to identify installed Acrobat versions across your domain to check against the patched versions:
Get-ItemProperty "HKLM:\Software\Adobe\Acrobat Reader\DC\Installer" -ErrorAction SilentlyContinue |
Select-Object PSChildName, Version
(Note: Paths may vary slightly depending on the installation architecture).
Is anyone else seeing specific IOCs tied to this yet? I'm particularly interested in knowing if the attack vector relies on malicious JavaScript within the PDF or if it's a direct heap spray, as that changes our filtering rules significantly.
Great catch. We're treating this as a P0 incident. I've updated our SIEM correlation rules to flag any AcroRd32.exe instances spawning cmd.exe or powershell.exe.
For those using Sentinel, here is a basic KQL query to hunt for this behavior while you wait for the patch rollout:
ProcessEvents
| where InitiatingProcessFileName == "AcroRd32.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe")
| project Timestamp, DeviceName, InitiatingProcessCommandLine, CommandLine
Usually, legitimate usage doesn't involve the reader shelling out directly.
Just pushed the update via SCCM to our pilot group. The main pain point I'm anticipating is the reboot requirement. Users never restart Acrobat.
On the technical side, remember that 'Protected View' is usually the first line of defense for these types of flaws. I'm temporarily enforcing a GPO to force Protected View for all files from the internet and untrusted locations. It's a bit of friction, but better than a ransomware event.
Has anyone tried fuzzing the specific parser module yet? The advisory is vague, but typically these RCEs in Acrobat come down to parsing JavaScript or specific encoding streams in the PDF structure.
If you're doing threat hunting, check for PDFs with unusually high entropy or Polyglot files. I've seen attackers use malformed XFA forms to bypass basic sandbox protections in the past.
Solid advice. If your patch cycle is lagging, forcing 'JavaScript' to off via GPO is a solid stopgap. Since memory corruption bugs often need the JS engine to trigger the specific logic paths, this buys you time. I'm using this quick snippet to verify the setting actually applied across our endpoints:
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown" | Select-Object bEnableJS
Don't forget to verify the patch actually stuck. Since Adobe's update mechanism can be finicky, I recommend running a quick audit script via your RMM or management tool to flag machines still reporting the old version number.
Get-ChildItem "C:\Program Files (x86)\Adobe\" -Recurse -Filter "AcroRd32.exe" -ErrorAction SilentlyContinue | Select-Object FullName, @{Name="ProductVersion";Expression={$_.VersionInfo.ProductVersion}}
This gives you a quick list to hunt down stragglers that missed the SCCM push.
Solid thread. To support CryptoKatie's point on auditing, here is a quick PowerShell snippet to check registry versions without the overhead of Win32_Product:
Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*", "HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*" | Where-Object { $_.DisplayName -like "*Adobe Acrobat*" } | Select-Object PSComputerName, DisplayName, DisplayVersion
Also, given the active exploitation status, validate your VSS snapshots now. If this turns into ransomware, you'll want to ensure those recovery points aren't corrupted.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access