This vulnerability is not the exception, but rather the rule, Tanase said. "Similar ones are discovered every year, in mostly every product version and they can all be used by attackers to run code and install software, requiring no user interaction beyond normal browsing."
However, this doesn't mean that it's not prone to vulnerabilities, he said. "If new functionality has been added to the browser or the PDF reader otherwise becomes privileged in the browser, then it may be vulnerable and become a new vector to exploit these vulnerabilities in the browser."
In general, the less code there is on a system, the less exposed it is to potential attacks, Eiram said. Using this built-in PDF viewer component instead of installing a separate a PDF reader application that often includes features many users don't really need and which can be vulnerable, reduces the system's overall attack surface, he said.
Tanase also agrees with this theory. "There's a clear benefit for using the same rendering engine for both Web pages and PDFs which needs to be pointed out: the code base is smaller, therefore the attack surface and potential risk is lowered," he said.
Fortunately, if such vulnerabilities are found, the job of fixing them falls to the browser vendor. Browser makers, especially Mozilla and Google, have a very good track record of managing vulnerabilities and historically have had better updating mechanisms than third-party plug-in vendors, Tanase said.