Firefox 19 ships with pdf.js as the default PDF reader.
One of the main stated goals is to reduce the exposure of users to the often vulnerable Adobe PDF reader/plugin.
So what new risks does pdf.js bring?
An attacker that can get a user to browse to their malicious PDF could also get the user to browse to a malicious web page. Any vulnerabilities in the HTML5 renderer or javascript interpreters could have been exploited that way anyway.
I actually think the Mozilla devs have been pretty smart with this.
Historically, most PDF exploits have come from the rendering engine rather than the parsing side. Adobe got wise early to the fact that malformed structure and content would screw them, and put a lot of effort into making sure that their parsing engine was rock solid. If you look at some of the recent 0-day stuff for Adobe Reader, you'll see that most of it relies on bugs in the rendering engine and some of the more exotic areas of content handling.
The new Firefox PDF engine simply takes the structure of the PDF and translates it into a DOM structure, which can be rendered by the browser's standard HTML renderer and interacted with via JavaScript. This removes a huge portion of the attack surface, and allows them to entirely focus on the security of the document translation engine. Any real exploitable bugs are likely to be reliant on a secondary bug that could be exploited through other means anyway.
If there are exploits, I see them coming from the following areas:
All in all, I don't think it brings much of an increased security risk, and once it's been around for a few months I'd consider it an ideal drop-in replacement for Adobe PDF plugins, which have been a source of many headaches.
Exploits fall into roughly two distinct categories: those which break the semantic rules of the implementation language (buffer overflows, use-after-free, uncontrolled type casts...) and those which play "by the rules". Since the new PDF reader is written in Javascript, exploits from the first category ought to be extremely rare, because of the intrinsic protection which is built-in in the language (checked array accesses, garbage collection, strong typing...). To obtain an arbitrary code execution exploit out of Javascript software, you have to find a hole in the Javascript engine itself; holes in the software written in Javascript will lead "only" to an exception, i.e. software crash, which is inconvenient but not as much as seeing your machine hijacked.
Presumably, the Javascript engine in Firefox is thoroughly tested, since it is so much used.
Exploits which play "by the rules" include all the workarounds around the Same Origin Policy and abuse of gateways to local resources. These are not made intrinsically harder or easier by virtue of the PDF reader being implemented in Javascript. However, doing such things right is similar to rendering Web content securely, something which has been a main goal of Firefox for years. We may hope that by implementing PDF rendering in the browser, they will be able to piggyback on all the hard work already done to keep your browser safe from hostile Web pages. At least, when it comes to containing PDF scripts into an appropriate sandbox, I would trust people who've done that for years (the Firefox developers) more than people for whom this is only a secondary work item, distinct from their core craft (the Adobe Reader developers).
So, for security, this new reader actually looks quite promising. Things become better, not worse.
PDF exploits are not exploiting the PDF file format. Instead, they are exploiting vulnerabilities found in the PDF reader.
If a PDF files contains an exploit for Adobe's reader, opening the file using pdf.js will prevent the exploit from working. Assuming Mozilla is fixing the bugs in pdf.js on a regular basis, this can reduce the impact of PDF exploits.
Like you said, any vulnerabilities found in Firefox can be exploited. This can be seen as a means to reduce reliance on Adobe for security updates.