CVE-2026-48294: Silent WhatsApp Hijack via Adobe Acrobat Extension
Just caught the writeup from Guardio Labs on CVE-2026-48294 (dubbed HermeticReader). It's a nasty one because it targets such a ubiquitous piece of software—the Adobe Acrobat Chrome extension with over 300 million users.
The vulnerability chain (CVSS 7.4) allows a malicious site to bypass the browser's Same-Origin Policy (SOP). Specifically, it can read data from web.whatsapp.com, effectively allowing an attacker to hijack a WhatsApp session if the user has the Web client active. The issue stems from how the extension handles messages and origins, permitting the attacker to script into the WhatsApp context. Since the extension runs with elevated privileges compared to a standard webpage, this breach effectively compromises the isolation of the browser tabs.
While the Chrome Web Store should auto-update the extension silently, we know that doesn't always happen instantly across every managed environment. If you manage Linux workstations, you can manually verify the extension version (ensure it's the patched build) by checking the manifest path:
grep -i "version" ~/.config/google-chrome/Default/Extensions/efaidnbmnnnibpcajpcglclefindmkaj/*/manifest.
For those using Sentinel or M365 Defender, we can correlate browser extension updates. Here is a basic KQL query to hunt for vulnerable version usage (assuming you have Browser telemetry):
DeviceBrowserEvents
| where ActionType == "ExtensionInstalled" or ActionType == "ExtensionUpdated"
| where BrowserExtensionId == "efaidnbmnnnibpcajpcglclefindmkaj"
| where BrowserExtensionVersion "
| project DeviceName, BrowserExtensionVersion, Timestamp
The scary part here is the "silent" nature—no prompts, no warnings, just data exfiltration while the user browses.
How is everyone handling extension updates at scale? Are you relying on Chrome Web Store auto-updates, or are you forcing specific versions via Group Policy?
We moved to a block-all-by-default policy for extensions years ago. It's a pain initially, but seeing something like this targeting 300M+ users validates the headache. For clients that must have Acrobat, we're deploying the updated version via Configuration Manager immediately. We also run a monthly audit of installed extensions to catch shadow IT.
The bypass technique is interesting—it relies on the extension's high privileges. It reminds me a lot of the MagicLine issues last year. From a red team perspective, this is a great payload for phishing campaigns. Send the link, wait for them to open WhatsApp Web (which many people leave open all day), and grab the session tokens. Highly recommend checking browser.extensions.enabled flags in your hardened baselines.
We didn't see any IOCs in our logs yet, but we updated our correlation rules to flag any outbound connections from known Adobe extension sub-resources to unknown domains. Also, for anyone using Chrome Enterprise, you can set ExtensionSettings to force the update URL to point to the fixed version immediately.
Solid points. For immediate response if you suspect compromise, forcing a log-out of all WhatsApp Web sessions from the mobile app is the fastest way to kill the hijack. To ensure policy compliance with Sarah's block-all approach, you might want to audit endpoints. Here's a quick PowerShell snippet to enumerate installed Chrome extensions:
Get-ChildItem "HKCU:\Software\Google\Chrome\Default\Extensions\" | Select-Object PSChildName
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access