Contents

HermeticReader Turned Adobe Acrobat Into a WhatsApp Spy on 329 Million Browsers

 

Ethical Hacking Complete Course Zero to Expert

Hack like black hat hackers. Penetration testing, Kali Linux, WiFi and web hacking, and the hacker mindset behind it.

→ Take the full course
 
Contents

An Adobe extension on roughly 329 million browsers had a flaw the researchers named HermeticReader, and it let any web page you opened read your WhatsApp Web. The chat list, the contact names, the conversation you had open, all of it lifted off the screen while you did nothing but land on the page. 🧐

There was no malware. Nothing landed on your machine, nothing was downloaded. Your password stayed untouched, your session cookie too. WhatsApp itself had no bug. The attacker needed no Adobe account and no way onto your computer. You opened a page that looked like a search result or a link in an email, and that was enough.

The extension is Adobe’s Acrobat PDF add-on for Chrome, one of the most installed in the Chrome Web Store. Guardio Labs found the bug and gave it the name HermeticReader. It is filed as CVE-2026-48294. Adobe rated it 7.4 out of 10, and the NIST database put it higher at 8.2. The two nearly match. NIST added one thing Adobe did not: the same chain can change the page, not just read it. That is what pushed its score higher. It lives in a feature Adobe shipped on June 3, a WhatsApp link-up whose engine is called Hermes on the inside.

It worked in three moves. Each one leaned on a shortcut that looked harmless on its own.

The first move let the page pretend it was Adobe. The extension ships some of its own pages and lets any website load them in a hidden frame. Each of those pages reads a chunk of text out of its own address and passes it to the extension’s background service. That service sees an address starting with chrome-extension:// and trusts it as its own. It never checks who is talking, and one of its handlers writes whatever it is handed straight into the extension’s storage, with no list of what is allowed. So any page could write any value into Adobe’s extension. Write one flag, and the sleeping WhatsApp engine wakes up:

1
2
3
4
5
// floodgate.js, updateLocalFeatureFlags (from Guardio's writeup)
updateLocalFeatureFlags(e) {
    const t = n.getItem("floodgate-add").split(/[, ]+/).filter(t => !e.includes(t));
    e.push(...t);
}

Drop dc-cv-hermes into that value and the flag turns true on the next check. The engine is armed.

The second move found the WhatsApp tab. The service needs the number Chrome gives to the tab that has WhatsApp Web open. Chrome hands out those numbers one at a time, always counting up. So the attacker page reads its own number, opens web.whatsapp.com itself, and the new tab is just its own number plus one. No searching, no guessing. To read its own number it used a second weak spot: the extension treats a page as a Google or Bing result if the address only starts with www.google., so www.google.attacker-domain.com passes the check:

1
2
new URL(location).host.startsWith("www.google.")   // also "www.bing."
// "www.google.attacker-domain.com".startsWith("www.google.") === true

The third move sent orders into WhatsApp. With the tab number in hand, the page forged messages that the extension carried into the WhatsApp tab, where Adobe’s own script ran them. That script takes a menu of actions on the page: inject HTML, call methods on elements, call methods on the window. It never asks who is sending.

One wall was left. WhatsApp Web blocks any injected script from running. So the researchers did not run a script. They made WhatsApp hand itself over.

They dropped a plain form into the WhatsApp page, aimed at their own server, with an empty dropdown inside it. Then they moved the live WhatsApp page into that dropdown and hit submit. Two old rules in the HTML standard finish the job. A dropdown option with no set value submits its own text, and the text of an element is whatever sits under it, so the submitted value became the full page. And WhatsApp never said where a form was allowed to send, so the browser posted its own screen straight to the attacker. They pulled nothing out of the extension. WhatsApp was asked to send itself, and it did.

For a logged-in user, what walked out was the chat list, the contact names, the message previews, the profile name, and the text of the open conversation. Run it again as new messages come in, and it keeps giving.

Reading was only the start. That same HTML injection could swap the WhatsApp Web login QR code for one the attacker owns. Scan it to link a device, and you link the attacker’s phone to your account instead of your own. That is a full takeover. And plenty of services send their login codes over WhatsApp, so those one-time codes sat right there in the readable text too.

Two things here matter more than the bug itself.

The first is the speed. Guardio ran this with an in-house AI system that unpacked the extension, cleaned up 344 scrambled code files, and mapped a message handler with 138 branches, then pointed a human researcher at the parts that mattered. They had a working exploit within hours of Adobe shipping the new version. The gap between a flaw going live and a flaw being caught used to be weeks or months. It is shrinking to hours, and that same speed is there for whoever points the tools the other way.

The second is how ordinary this was. No memory-corruption magic, no state-sponsored implant. Just a pile of small, dull shortcuts in the plumbing, message passing, storage, feature flags, address checks, each fine on its own, stacking up into a full read of your WhatsApp. The bigger the install base, the longer a flaw like this sits there before someone looks closely.

Adobe comes out of this well. They took the report, fixed it, and shipped the patch across a single weekend, with the CVE following days later. For an add-on on hundreds of millions of browsers, that is the response you want.

What to do on your side:

  • → Check that your Adobe Acrobat extension is on version 26.5.2.3 or newer. The fix went out through the Chrome Web Store on its own, but open your extensions page and look.
  • → Go through the other extensions you have handed broad access to, the ones you set up once and forgot. Each one runs on the pages you visit.
  • → Guardio saw no sign it was used before the fix. The window shut fast.

This is a page on one site reaching across into another site you are logged into, past the boundary the browser is supposed to keep between them. That boundary, and the cross-site scripting family behind it, is what I cover hands-on in my ethical hacking course, from your first XSS payload to the kind that runs entirely inside the browser:

Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Guardio Labs | NIST NVD

 
NEWSLETTER

Stay updated

Get the latest posts in your inbox every week. Ethical hacking, security news, tutorials, and everything that catches my attention. If that sounds useful, drop your email below.

By Bulls Eye

Jolanda de koff • emaildonate

My name is Jolanda de Koff and on the internet, I'm also known as Bulls Eye. Ethical Hacker, Penetration tester, Researcher, Programmer, Self Learner, and forever n00b. Not necessarily in that order. Like to make my own hacking tools and I sometimes share them with you. "You can create art & beauty with a computer and Hacking is not a hobby but a way of life ...

I ♥ open-source and Linux