SURIQ
The riskiest software on your users' laptops is not always the app they installed on purpose. A cross-origin flaw in Adobe's Acrobat extension for Chrome, a browser add-on with more than 300 million installs, briefly turned a document helper into a bridge that any website could ride to read a victim's WhatsApp Web conversations. No malware landed, no password was phished, no multi-factor prompt was intercepted. The victim only had to open a booby-trapped page while the extension sat installed in the background.
Guardio Labs found the bug, named it HermeticReader, and reported it as CVE-2026-48294 (CVSS 7.4). WhatsApp Web was the proof, not the boundary. The mechanism underneath is a bug class that applies to a large slice of the extensions your fleet already runs, and that is the part worth your attention.
What the Adobe Acrobat extension flaw let an attacker do
A malicious web page could quietly command the Adobe Acrobat Chrome extension to open a logged-in web app in a background tab and hand the rendered page content back to an attacker-controlled server. Guardio demonstrated the read against WhatsApp Web: chat lists, contact names, profile names, and visible message text. The victim saw nothing.
The exposure is real but the response was fast. According to Guardio's writeup, the weakness was introduced by an Adobe extension update and found within about four hours, and Adobe shipped a fix within roughly two days. The flaw affects builds up to and including 26.5.2.2 by Guardio's account, and Adobe's corrected build is 26.5.2.3. The two outlets that covered this differ slightly on the exact last-vulnerable version and on the install count (reports cite figures from 314 million to 329 million), so treat the precise numbers as approximate and the action as certain: update the extension. Neither Guardio nor Adobe has reported any exploitation in the wild.
The confused deputy hiding inside a browser extension
This is a textbook confused deputy: a privileged component that acts on instructions without checking who sent them. The extension shipped an internal HTML resource marked web-accessible, which means any page on the internet is allowed to load it inside an iframe. That internal page took commands through a URL parameter and forwarded them to the extension's service worker, the privileged background component, without verifying whether the request came from a genuine Adobe content script or from a random attacker page framing it.
From there the chain used ordinary browser behavior rather than any exotic exploit. An attacker page framed the internal resource, told the extension to activate its integration engine, and had it open WhatsApp Web in a background tab reachable through predictable tab identifiers. Two more design gaps completed the read: an HTML quirk where a form option with no value attribute submits its own rendered text content, and, per Guardio's analysis, the absence of a form-action content-security-policy directive on WhatsApp Web, which let the attacker POST the target page's rendered DOM to an endpoint they controlled. Guardio published the analysis, reported by BleepingComputer; we are describing the shape of the failure, not a recipe.
Notice what had to break. The extension trusted an unauthenticated caller, and the target web app did not restrict where its own forms could submit. Either fix alone would have blunted the attack. That second point is a cheap, portable lesson for anyone who ships a web application: set form-action 'self' so a failure one layer up in the browser cannot quietly exfiltrate your page. It is a defense-in-depth control that costs one CSP line.
Why a personal-sounding bug is really a fleet problem
Coverage framed this as "a website could read your WhatsApp." For a security team the framing is different. A browser add-on installed on hundreds of millions of endpoints is unmanaged privileged software running next to every authenticated session your users hold. When that add-on can be driven by an arbitrary page, the blast radius is not one person's chats. It is any logged-in web app the extension is permitted to open in a tab, across every host where the add-on is installed.
We have watched this same seam open repeatedly: a rogue extension coaxed into reading Gmail, malicious add-ons hiding payloads in images for two years, and attacks that run entirely inside the browser tab where host tools cannot see them. The pattern is consistent. The browser is now an operating system, its extensions are third-party software with broad reach, and most organizations inventory neither. A PDF helper with 300 million installs deserves the same review you would give any agent you let run on a server.
Why your endpoint tools would have missed it
The uncomfortable part is detection. This attack leaves almost no host-side footprint. No file is written, no new process spawns, no credential is stolen, no session cookie is exfiltrated. Endpoint antivirus and most EDR have nothing to alert on, because from the operating system's view nothing unusual happened: a browser opened a tab and made an outbound web request, which it does thousands of times a day.
The only signals live above the host. On the network, an unexpected outbound POST carrying a large blob of page content to an unfamiliar domain is the tell. In the browser, a background tab opening a login-bound app like WhatsApp Web, driven from an unrelated page, is anomalous. That is the practical takeaway that the patching advice skips: applying the update closes this specific hole, but knowing whether you were touched in the window before you patched depends on browser and egress telemetry, not on the endpoint agent most teams lean on. Session-bound data theft rarely trips host alarms, a gap we walked through in how live-session theft sidesteps a password reset.
Update to 26.5.2.3, then close the governance gap
The immediate action is small. Confirm the Adobe Acrobat extension (extension ID efaidnbmnnnibpcajpcglclefindmkaj) has auto-updated to 26.5.2.3 or later across your fleet; Chrome usually handles this within a day, but a managed environment should verify rather than assume. If you cannot confirm the version quickly, disabling the extension until you can is a reasonable interim step.
The durable work is governance. Inventory which browser extensions run in your environment and who approved them. Prefer a managed allowlist over letting every user install what they like. For web applications your own teams build, add a form-action policy so a browser-layer failure cannot lift your rendered pages. And put browser and network telemetry where you can actually query it, because the next confused-deputy extension bug will be just as invisible to the endpoint agent as this one was.