Blog

Adobe Acrobat Hollowing Out Same-origin Policy

Posted on September 27, 2026 by Neva

It’s unclear whether or not all of the numerous folks who have the Adobe Acrobat browser extension installed actually use it. The extension being installed mechanically together with the Adobe Acrobat utility, chances are that they don’t even find out about it. But safety-wise it doesn’t matter, an extension that’s put in and unused may still be exploited by malicious actors. So just a few months in the past I decided to take a look. To my surprise, the extension itself did virtually nothing regardless of having a fairly appreciable code dimension. It’s actually little more than a solution to current Adobe Document Cloud by way of an extension, all of the user interface being hosted on Adobe’s servers. And that’s the place hassle starts, it’s arduous to maintain these privileges restricted to Adobe properties. Companies don’t often like safety studies pointing out that something unhealthy might occur. While I eventually succeeded, this investigation yielded a bunch of useless ends which are interesting on their very own. These have been reported to Adobe, and I’ll outline them in this article as properly.

TL;DR: Out of six points reported, only one is resolved. The principle subject received a partial repair, two extra bought fixes that didn’t quite tackle the problem. Two (admittedly minor) points haven’t been addressed in any respect inside ninety days from what I can inform. Why does similar-origin policy matter? Why does same-origin policy matter? The identical-origin policy is the most basic security concept of the online. So even if you happen to visit a malicious website, that website is restricted to doing mischief inside its own bounds – or exploiting web sites with safety vulnerabilities. What occurs if that security boundary breaks down? Suddenly a malicious website can impersonate you towards other websites, even if these don’t have any recognized vulnerabilities. Are you logged into Gmail for example? A malicious webpage can request your information from Gmail, downloading all your e mail conversations. And then it will probably ask Gmail to send out emails in your title.

Similarly if you are logged into Twitter or Facebook, your non-public messages are not personal. And your energetic on-line banking session will enable that malicious website to examine your transaction history (luckily not making any transfers, that normally requires authorization by way of a second issue). Now you hopefully get an concept why a gap in the same-origin policy is a critical vulnerability and must be prevented at any value. Next: Adobe Acrobat extension. As I discussed before, the Adobe Acrobat extension doesn’t actually do anything by itself. So while you edit a PDF file for example, you aren’t really within the extension – you’re in Adobe’s Document Cloud. You might be using a web utility. Now that web utility has an issue: in an effort to do something with a PDF file, it needs to entry its data. And with it hosted anyplace on the internet, similar-origin policy gets in the way in which. The standard resolution can be utilizing a proxy: let some Adobe server obtain the PDF file and supply the info to the net application.

Downside right here: proxy server can not entry PDF recordsdata hosted on some company intranet, and neither PDF files that require the user to be logged in. These can solely be accessed through user’s browser. So Adobe went with one other solution: let the extension “help” the net utility by downloading the PDF knowledge for it. The extension web page will try and download data from the address it obtained by way of pdfurl parameter and send it to the body through window.postMessage(). This could be principally effective in case you navigating to some PDF file were a obligatory step of the process. ’s manifest. Which agreement means that any web site is allowed to load chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/viewer.html and give it no matter worth for pdfurl. Google homepage and intercepting the ensuing information would give attackers access to your Google user identify for instance. Even the place CSP is used, its protection is weakened considerably by allowing scripts from a multitude of various companies and through the use of key phrases like ‘unsafe-eval’.

Should show the difficulty nicely, what could presumably go fallacious? Well, for once Adobe may repair the XSS vulnerability before even taking a look at my proof of concept for this issue. And that’s precisely what they did in fact. More than a month after the report they asked me why they couldn’t reproduce the problem. To their defense, they didn’t give up on this situation although I couldn’t deliver a brand new proof of concept. As of Adobe Acrobat 15.1.3.10, it is partially resolved. I may confirm that exploiting it to download regular pages not works. The half waiting for readyReceived and seenPdf variables to be set is new. This is probably meant to handle my proof of idea where the message source happened to be an external web page. It doesn’t provide any value beyond what isValidOrigin() already does nonetheless. This access can be used to run code within the body and thus send messages with the body being the message source.