GnuPG 2.2.8 addresses the CVE-2018-12020 vulnerability, entitled SigSpoof. It is affecting GnuPG, Enigmail, GPGTools, and python-gnupg.

GnuPG, also known as GPG, allows users to encrypt and sign data and communications. It’s a complete and free implementation of the OpenPGP standard and defined by RFC4880 (also known as PGP). Version 2.2.8, released this month addresses the CVE-2018-12020 vulnerability, also designated as SigSpoof affecting GnuPG, Enigmail, GPGTools, and python-gnupg.

“The signature verification routine in Enigmail, GPGTools 2018.2, and python-gnupg 0.4.2 parse the output of GnuPG 2.2.6 with a ‘–status-fd 2’ option, which allows remote attackers to spoof arbitrary signatures via the embedded ‘filename’ parameter in OpenPGP literal data packets, if the user has the verbose option set in their gpg.conf file,” reads the blog post published by Marcus Brinkmann who discovered the SigSpoof flaw.



The security researcher said that even if the verbose is disabled by default, it is included in several recommended configurations for GnuPG.

Initially, status messages are parsed by applications that get information from GPG about the validity of a signature.

“Status messages are created with the option “–status-fd N,” where N is a file descriptor. If N is 2, status messages and regular diagnostic messages share the stderr output channel.” explains GnuPG maintainer Werner Koch.

“The issue resides in the OpenPGP protocol allowing the inclusion of the file name of the original input file into a signed or encrypted message. The GnuPG tool can display a notice with that file name during decryption and verification, but it does not sanitize the file name, meaning that an attacker could include line feeds or other control characters in it.”

The lack of file name sanitization in GnuPG tool could be exploited by attackers to include line feeds or other control characters.


In this sense, an attacker can inject terminal control sequences and create fake status messages. It can also fake the verification status of a signed email.

“The attacker can inject arbitrary (fake) GnuPG status messages into the application parser to spoof signature verification and message decryption results. The attacker can control the key ids, algorithm specifiers, creation times and user ids, and does not need any of the private or public keys involved.” continues Brinkmann.


Brinkmann said that the limit for the file name of the encrypted file in OpenPGP is 255.

The researcher suggests to don’t include the verbose in gpg.conf and to avoid using gpg –verbose on the command line in order to mitigate this vulnerbility. Developers have to add –no-verbose option to all calls of the gpg.

“The vulnerability in GnuPG goes deep and has the potential to affect a large part of our core infrastructure. GnuPG is not only used for email security, but also to secure backups, software updates in distributions, and source code in version control systems like Git,” Brinkmann concludes.