In Enigmail below 2.1, an attacker in possession of PGP encrypted emails can wrap them as sub-parts within a crafted multipart email. The encrypted part(s) can further be hidden using HTML/CSS or ASCII newline characters. This modified multipart email can be re-sent by the attacker to the intended receiver. If the receiver replies to this (benign looking) email, he unknowingly leaks the plaintext of the encrypted message part(s) back to the attacker. This attack variant bypasses protection mechanisms implemented after the "EFAIL" attacks.
Enigmail before 2.0.11 allows PGP signature spoofing: for an inline PGP message, an attacker can cause the product to display a "correctly signed" message indication, but display different unauthenticated text.
The signature verification routine in Enigmail before 2.0.7 interprets user ids as status/control messages and does not correctly keep track of the status of multiple signatures, which allows remote attackers to spoof arbitrary email signatures via public keys containing crafted primary user ids.
mainproc.c in GnuPG before 2.2.8 mishandles the original filename during decryption and verification actions, which allows remote attackers to spoof the output that GnuPG sends on file descriptor 2 to other programs that use the "--status-fd 2" option. For example, the OpenPGP data might represent an original filename that contains line feed characters in conjunction with GOODSIG or VALIDSIG status codes.
An issue was discovered in Enigmail before 1.9.9. In a variant of CVE-2017-17847, signature spoofing is possible for multipart/related messages because a signed message part can be referenced with a cid: URI but not actually displayed. In other words, the entire containing message appears to be signed, but the recipient does not see any of the signed text.
An issue was discovered in Enigmail before 1.9.9. Signature spoofing is possible because the UI does not properly distinguish between an attachment signature, and a signature that applies to the entire containing message, aka TBE-01-021. This is demonstrated by an e-mail message with an attachment that is a signed e-mail message in message/rfc822 format.
An issue was discovered in Enigmail before 1.9.9. Regular expressions are exploitable for Denial of Service, because of attempts to match arbitrarily long strings, aka TBE-01-003.
An issue was discovered in Enigmail before 1.9.9. Improper Random Secret Generation occurs because Math.Random() is used by pretty Easy privacy (pEp), aka TBE-01-001.
An issue was discovered in Enigmail before 1.9.9. A remote attacker can obtain cleartext content by sending an encrypted data block (that the attacker cannot directly decrypt) to a victim, and relying on the victim to automatically decrypt that block and then send it back to the attacker as quoted text, aka the TBE-01-005 "replay" issue.
An issue was discovered in Enigmail before 1.9.9 that allows remote attackers to trigger use of an intended public key for encryption, because incorrect regular expressions are used for extraction of an e-mail address from a comma-separated list, as demonstrated by a modified Full Name field and a homograph attack, aka TBE-01-002.