It was found that the OPVPWrapper::loadDriver() function in the pdftoopvp filter did not restrict the directory drivers could be loaded from. As the driver name can be configured based on a PPD file, processing a PDF in an attacker-controlled directory containing a malicious driver could lead to arbitrary code execution with the privileges of the "lp" user. Acknowledgements: This issue was discovered by Florian Weimer of the Red Hat Product Security Team.
Public via: http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/revision/7176 This issue has been resolved in upstream cups-filters-1.0.47
Created cups-filters tracking bugs for this issue: Affects: fedora-all [bug 1074840]