Okular is a universal document viewer developed by the KDE project.

We found a command execution inside a PDF document that can be used with social engineering attacks to remotely execute commands on a target system.


The Okular PDF reader does not correctly handle HyperLink correctly, allowing system binary execution.

In the case where an attacker could send the malicious PDF, he would be able to remotely take over the system.


Processing hyperLinks in PDF documents should never lead to command execution.

Vulnerability records

CVE ID: CVE-2020-9359

Access Vector: local

Security Risk: medium

Vulnerability: CWE-78

CVSS Base Score: 6.1

CVSS Vector String: CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L


We identified a code execution vulnerability in the HyperLink parsing. Okular would execute forged links, containing system commands like /usr/bin/ls.

Proof of Concept 1 : Native binary execution

We forged the following Latex file, to compile with pdflatex file.tex.

Note that it contains a malicious link pointing to the /usr/bin/ls binary:

\title{First POC \LaTeX{}}
\author{Mickael Karatekin}
\section{Code Execution Example using native binary}
\item{\url{/usr/bin/ls}{: Here is an exec using URL tag}}

After the compilation, we obtain the malicious PDF document that can be sent to the victim.

When opened in Okular, the "/usr/bin/ls" binary gets executed when the victim clicks on the hyperLink.

Proof of Concept 2: Automated Binary execution on document opening

Using the Adobe Acrobat DC, we were able to create a form inside the PDF document.

We then configured the form in form options to catch the mouse movement and call the HyperLink of the binary.

The proof of concept file is available at the following URL:

In this scenario, the threat is higher as the malicious payload gets executed right after the user accepts the warning to enable forms. This is a much more plausible phishing scenario.

Affected versions

  • Okular versions < 1.10.0


There's no real workaround other than not opening PDF files from untrusted sources.

Timeline (dd/mm/yyyy)

  • 20/02/2020 : Initial discovery
  • 28/02/2020 : Report to the KDE security team
  • 29/02/2020 : Acknowledgement from Albert Astals Cid from the KDE team
  • 08/03/2020 : Albert updated us with a patch
  • 11/03/2020 : Albert proposed us a draft KDE security advisory
  • 12/03/2020 : Publication of the KDE official advisory (
  • 24/03/2020 : Sysdream publication


  • Mickael Karatekin, Sysdream (m.karatekin -a-t- -sysdream-dot- -com)
  • Albert Astals Cid from the KDE team for the fix and perfect handling of our report.


  • Nicolas Chatelain