The key selection dialogue in Enigmail before 0.92.1 can incorrectly select a key with a user ID that does not have additional information, which allows parties with that key to decrypt the message.

Enigmail 1.7.x before 1.7.2 sends emails in plaintext when encryption is enabled and only BCC recipients are specified, which allows remote attackers to obtain sensitive information by sniffing the network.

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.

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. 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. 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. 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. 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.

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.

Enigmail before 2.0.6 is prone to to OpenPGP signatures being spoofed for arbitrary messages using a PGP/INLINE signature wrapped within a specially crafted multipart HTML email.

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.

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.