KDE KMail

KMail since version 5.3.0 used a QWebEngine based viewer that had JavaScript enabled. Since the generated html is executed in the local file security context by default access to remote and local URLs was enabled.

Through a malicious URL that contained a quote character it was possible to inject HTML code in KMail's plaintext viewer. Due to the parser used on the URL it was not possible to include the equal sign (=) or a space into the injected HTML, which greatly reduces the available HTML functionality. Although it is possible to include an HTML comment indicator to hide content.

KDE kmail before 5.5.2 and messagelib before 5.5.2, as distributed in KDE Applications before 17.04.2, do not ensure that a plugin's sign/encrypt action occurs during use of the Send Later feature, which allows remote attackers to obtain sensitive information by sniffing the network.

KMail since version 5.3.0 used a QWebEngine based viewer that had JavaScript enabled. HTML Mail contents were not sanitized for JavaScript and included code was executed.

An issue was discovered in KDE KMail before 19.12.3. By using the proprietary (non-RFC6068) "mailto?attach=..." parameter, a website (or other source of mailto links) can make KMail attach local files to a composed email message without showing a warning to the user, as demonstrated by an attach=.bash_history value.

KDE KMail 19.12.3 (aka 5.13.3) engages in unencrypted POP3 communication during times when the UI indicates that encryption is in use.

The S/MIME specification allows a Cipher Block Chaining (CBC) malleability-gadget attack that can indirectly lead to plaintext exfiltration, aka EFAIL.

KDE KMail does not encrypt attachments in emails when "automatic encryption" is enabled, which allows remote attackers to obtain sensitive information by sniffing the network.

In KDE KMail 19.12.3 (aka 5.13.3), the SMTP STARTTLS option is not honored (and cleartext messages are sent) unless "Server requires authentication" is checked.

In KDE KMail 5.2.3, an attacker in possession of S/MIME or 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, they unknowingly leak the plaintext of the encrypted message part(s) back to the attacker.