About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.

Adobe PDF XSS Vulnerability

I've been concentrating on work this past week, but I wanted to quickly mention the Adobe PDF XSS vulnerability discovered by Stefano Di Paola and Giorgio Fedon. This is being called UXSS (universal cross-site scripting) due to the fact that it can affect virtually any web site. (The web site just has to host a PDF.)

The basic attack is pretty straightforward:


If you have a vulnerable version of Acrobat / Reader, your browser will execute this JavaScript whenever you visit the URL. In other words, any site hosting a PDF is a potential target for such an attack, regardless of whether the site would otherwise not be vulnerable to XSS. (For example, my Security 2.0 slides.) Worse, RSnake found a local PDF that can be used for more malicious attacks:


This path is clearly for Windows, but I'm sure similar local URLs can be found for other platforms.

This is all significant, because as I've mentioned before, XSS matters.

One thing missing from most of the discussion is that this issue does not affect the most recent version of Adobe Acrobat / Reader, which was released last year. I still think this is a very significant discovery, but I don't think such important information should be left out of the discussion to artificially increase concern. Adobe's security advisory provides more details about which versions are affected.

John Dowdell, who I mentioned before when discussing the YouTube security vulnerability, mentions this fact in a post on the topic, and he includes some insight from Leonard Rosenthol of the Adobe Acrobat team:

  • This issue only affects the Windows platform. Mac, Linux, etc. users are not affected.
  • We found this issue ourselves during our own security/vulnerability testing of Acrobat and introduced a fix as part of Acrobat/Reader 8 for Windows. As such, users of Acrobat/Reader 8 (regardless of browser) are not affected.
  • We already have patches prepared for earlier versions of Acrobat and will release those as soon as they are ready. This will address those users who are unable/unwilling to upgrade to Acrobat/Reader 8.

If you're a Windows user, your best bet is to either upgrade to Adobe Acrobat / Reader 8, or disable the plugin from opening within the browser.

If you're an application developer, you can opt to remove all PDFs from your site, or you can force PDFs to be downloaded instead of displayed inline. Richard Lynch has an old post / rant with some useful information. Rich Bowen offers the following advice:

AddType application/octet-stream .pdf

I keep reading about the "anchor tag" not being sent to the server. I finally realized that people mean to say fragment identifier. An anchor tag is just the <a> tag we use in HTML to create links. (I'll withhold another long-winded rant about technical vocabulary, although that was an interesting discussion.) Hopefully this tidbit can help you if you're trying to follow the ongoing discussion.

About this post

Adobe PDF XSS Vulnerability was posted on Wed, 10 Jan 2007. If you liked it, follow me on Twitter or share:


1.wesley said:

Couldn't you write a RewriteRule that would get rid of everything after .pdf? Far easier.

Wed, 10 Jan 2007 at 17:39:25 GMT Link

2.Ilia Alshanetsky said:

Actually anchor is the correct name for #foobar according to the W3C specification.


Anchor specifically refers to #text bit. <A> is an element tag.

Wed, 10 Jan 2007 at 17:49:17 GMT Link

3.Chris Shiflett said:

This particular attack uses the fragment identifier, which is not included in the request, so mod_rewrite can't detect it.

I don't think a mod_rewrite rule is necessarily any easier than the AddType directive Rich mentions. The equivalent mod_rewrite rule is something like this:

RewriteRule \.pdf - [T=application/octet-stream]

Wed, 10 Jan 2007 at 17:50:45 GMT Link

4.Chris Shiflett said:

Ilia, I think you should read that again.

"An anchor name is the value of either the name or id attribute when used in the context of anchors."

This is a reference to how the fragment identifier is declared in an anchor tag:

<a name="foo">

Now, consider this:

<img src="http://host/img.jpg" />

You wouldn't call http://host/img.jpg an image tag, would you?

This is slightly unrelated, because we're talking about URLs, not HTML. This is more relevant:


Wed, 10 Jan 2007 at 18:00:41 GMT Link

5.Ilia Alshanetsky said:

I think it is a matter on interpretation, I just asked a bunch of people and most "parsed" # as anchor. A few did seem to get a bit confused, however almost no one (one person did) recognized "fragment" which is what the addressing RFC calls it.

Given that the author tries to make things understandable as possible it only makes sense they'd use a more familiar name. IMHO.

Wed, 10 Jan 2007 at 22:17:59 GMT Link

6.Chris Shiflett said:

Yeah, I can see how anchor (not anchor tag) could make sense in some cases, because you could be referring to an anchor on a web page.

But, when people are talking about what part of a URL is or isn't sent in an HTTP request, referring to HTML tags can lead to confusion. I actually wasn't trying to initiate a debate about semantics - I just wanted to help anyone else who was mislead by the vocabulary being used.

For what it's worth, most people I know just say fragment or URL fragment rather than fragment identifier.

Wed, 10 Jan 2007 at 22:44:09 GMT Link

7.Mark IJbema said:

I call bullshit on the windows-only remark. It's at least exploitable under linux (the proof of concept runs on my machine at the university, where i use acrobat), and i guess under macosx as well, but why would you use the acrobat reader plugin in macosx, since the os itself provides decent pdf support.

Thu, 11 Jan 2007 at 11:15:15 GMT Link

8.Chris Shiflett said:

Thanks for that info, Mark. I wondered about the Windows-only remark myself.

I use Mac OS X exclusively now, so yeah, I can't imagine ever needing Acrobat for anything. :-)

Thu, 11 Jan 2007 at 15:12:15 GMT Link

9.John Dowdell said:

Thanks, Chris. For what it's worth, the Adobe Security Team released a serverside fix yesterday (so that even if your audience is using older internet software, their browsers won't get passed JS from PDF URLs clicked at suspect sources), along with updaters for old versions of Adobe Reader (if your computer, OS or intranet policies don't permit using current versions).


I haven't tested different combinations of OS, browser and Reader myself, yet it's hard for me to see incentive for misrepresentation among those who have... the shared goal is to lock out potential exploits wherever identified.

tx, jd/adobe

Thu, 11 Jan 2007 at 15:57:02 GMT Link

10.Nico said:

The fix via rewrite is to add a unique token as GET parameter and a temporary redirect if the request doesn't have a token yet. That gets rid of the anchor/fragment part.

Fri, 12 Jan 2007 at 01:56:22 GMT Link

11.Chris Shiflett said:

Hi Nico,

Thanks for the suggestion. I need to dig into this issue more myself, but I seem to recall Amit Klein making a similar suggestion and then responding with this:


It seems directly related to what you're suggesting and might be worth reading.

Thanks again!

Fri, 12 Jan 2007 at 02:27:17 GMT Link

12.Jess said:

I am using the following service for vulnerability research:


Wed, 24 Feb 2010 at 21:01:14 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.