mutt before 2.3.2 has a showsigsummary NULL pointer dereference.

mutt before 2.3.2 has an infinite loop in dataobjecttostream in crypt-gpgme.c.

In mutt before 2.3.2, the imapauthgss security level is mishandled.

mutt before 2.3.2 does not check for '\0' in urlpctdecode.

mutt before 2.3.2 sometimes truncates the hashpasswd by one byte for IMAP authcram MD5 digest.

mutt before 2.3.2 sometimes uses strfcpy instead of memcpy for the IMAP authcram MD5 digest.

In the ChangeLog [0], all of these are listed as security fixes.

""" 2026-04-26 10:45:26 +0800 Kevin J. McCarthy <kevin () 8t8 us> (4a9c9248)

Update UPDATING file for 2.3.2 release.

M UPDATING

2026-04-18 22:08:19 +0800 Kevin J. McCarthy <kevin () 8t8 us> (834c5a2e)

Fix IMAP authcram MD5 digest of secret to use memcpy(). For a secret longer than MD5BLOCKLEN, an MD5 digest is used instead. However, mutt was incorrectly using strfcpy() instead of memcpy() on the raw binary value returned by md5buffer in hashpasswd. If hashpasswd contained an '\0' it would result in the value being truncated. Additionally, the strfcpy was truncating the hashpasswd by one byte regardless, due to passing a "size" of MD5DIGESTLEN when the data itself was length MD5DIGESTLEN. This likely hasn't been a reported issue because: 1. CRAM-MD5 is not used much anymore 2. Most people likely don't have a password length greater than 64 bytes. Thanks to evilrabbit () tutamail com for the security report.

M imap/authcram.c

2026-04-18 22:40:46 +0800 Kevin J. McCarthy <kevin () 8t8 us> (12f54fe3)

Check for embedded nul in urlpctdecode(). Consider %00 an invalid character in a URL. Thanks to evilrabbit () tutamail com for the security report. Reviewed-by: Alejandro Colomar <alx () kernel org>

M url.c

2026-04-18 22:36:37 +0800 Kevin J. McCarthy <kevin () 8t8 us> (f547a849)

Fix imapauthgss() security level size check and bufsize type. Make sure sendtoken.length is 4 bytes before reading the data. Fix the bufsize type to be uint32t instead of long. ntohl() operates on, and returns, a 32 bit unsigned integer. Most architectures now use a 64-bit long. I believe this only worked because in Little-Endian, the least-significant bits come first, so even though we were using 8 bytes of sendtoken.value (4 of which were out of bounds) for the cast to long, only the first 4 bytes were used to truncate to the uint32t that ntohl() used. Likewise when we converted htonl() further down. Additionally, the comments indicate that mutt wasn't using bufsize in any case, so perhaps that also explains the lack of bug reports. Thanks to evilrabbit () tutamail com for the security report. Reviewed-by: Alejandro Colomar <alx () kernel org>

M imap/authgss.c

2026-04-18 21:54:34 +0800 Kevin J. McCarthy <kevin () 8t8 us> (fdc04a17)

Fix infinite loop in gpgme dataobjecttostream(). The code was not properly checking for a -1 return value in the read, leading to an infinite loop, and printing past the buffer value to the stream. Thanks to evilrabbit () tutamail com for the security report. Reviewed-by: Alejandro Colomar <alx () kernel org>

M crypt-gpgme.c

2026-04-18 21:41:23 +0800 Kevin J. McCarthy <kevin () 8t8 us> (ebfa2969)

Fix NULL dereference in showsigsummary(). Inside showonesigstatus(), if the error code is GPGERRNOPUBKEY, key is NULL. However, showsigsummary() doesn't check for a NULL key before dereferencing for the "key expired" case. Thanks to evilrabbit () tutamail com for the security report. Thanks to Alejandro Colomar for his review and suggestion to keep the ternary operator. Reviewed-by: Alejandro Colomar <alx () kernel org>

M crypt-gpgme.c """

[0] https://gitlab.com/muttmua/mutt/raw/mutt-2-3-2-rel/ChangeLog

-------------------- Start of forwarded message -------------------- Date: Sun, 26 Apr 2026 12:34:17 +0800 From: "Kevin J. McCarthy" <kevin () 8t8 us> To: mutt-announce () mutt org Subject: mutt 2.3.2 released Hello Mutt Users,

I've just released version 2.3.2. Instructions for downloading are available at <http://www.mutt.org/download.html>, or the tarball can be directly downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to verify the signature file against my public key[1].

Please note that my public key expired a few weeks ago, however I updated the expiration date. If you are receiving an expired key notice, please refresh your keyring, or just import my key again from one of the sources below.

This release fixes an assortment of issues, including a possible segv in the GPGME code. For more details see the commits:

834c5a2e Fix IMAP authcram MD5 digest of secret to use memcpy(). 12f54fe3 Check for embedded nul in urlpctdecode(). f547a849 Fix imapauthgss() security level size check and bufsize type. fdc04a17 Fix infinite loop in gpgme dataobjecttostream(). ebfa2969 Fix NULL dereference in showsigsummary(). -Kevin

[1] My public key is available at: - my personal website: https://8t8.us/configs/80316BDA.asc.pubkey - the mutt website: http://www.mutt.org/keys/kevin.key - The keys.openpgp.org network https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA -------------------- End of forwarded message --------------------

In mutt and neomutt, PGP encryption does not use the --hidden-recipient mode which may leak the Bcc email header field by inferring from the recipients info.

In mutt and neomutt, PGP encryption does not use the --hidden-recipient mode which may leak the Bcc email header field by inferring from the recipients info.

In mutt and neomutt the In-Reply-To email header field is not protected by cryptographic signing which allows an attacker to reuse an unencrypted but signed email message to impersonate the original sender.

In mutt and neomutt the In-Reply-To email header field is not protected by cryptographic signing which allows an attacker to reuse an unencrypted but signed email message to impersonate the original sender.

In neomutt and mutt, the To and Cc email headers are not validated by cryptographic signing which allows an attacker that intercepts a message to change their value and include himself as a one of the recipients to compromise message confidentiality.

In neomutt and mutt, the To and Cc email headers are not validated by cryptographic signing which allows an attacker that intercepts a message to change their value and include himself as a one of the recipients to compromise message confidentiality.

On Sat, Sep 09, 2023 at 07:00:40PM -0000, Tavis Ormandy wrote: FYI, a mutt update that fixes a crash on header parsing:

http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20230904/000056.html

Tavis.

-- o) $ lynx lock.cmpxchg8b.com /\\ o) o) $ finger taviso () sdf org \V ( ) ( ) @taviso These are CVE-2023-4874 and CVE-2023-4875.

Cascardo.

FYI, a mutt update that fixes a crash on header parsing:

http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20230904/000056.html

Tavis.

-- o) $ lynx lock.cmpxchg8b.com /\\ o) o) $ finger taviso () sdf org \V ( ) ( ) @taviso

Null pointer dereference when viewing a specially crafted email in Mutt 1.5.2 <2.2.12

Null pointer dereference when composing from a specially crafted draft message in Mutt >1.5.2 <2.2.12

Buffer Overflow in uudecoder in Mutt affecting all versions starting from 0.94.13 before 2.2.3 allows read past end of input line

Last updated 16 January 2025

rfc822.c in Mutt through 2.0.4 allows remote attackers to cause a denial of service (mailbox unavailability) by sending email messages with sequences of semicolon characters in RFC822 address fields (aka terminators of empty groups). A small email message from the attacker can cause large memory consumption, and the victim may then be unable to see email messages from other persons.

Last updated 16 January 2025

Last updated 25 August 2025

Last updated 25 August 2025

Last updated 25 August 2025

Mutt before 1.5.20 patch 7 allows an attacker to cause a denial of service via a series of requests to mutt temporary files.

It was discovered that Mutt incorrectly handled certain requests. An attacker could possibly use this to execute arbitrary code. (CVE-2018-14350, CVE-2018-14352, CVE-2018-14354, CVE-2018-14359, CVE-2018-14358, CVE-2018-14353 ,CVE-2018-14357) It was discovered that Mutt incorrectly handled certain inputs. An attacker could possibly use this to access or expose sensitive information. (CVE-2018-14355, CVE-2018-14356, CVE-2018-14351, CVE-2018-14362, CVE-2018-14349)

USN-3719-1 fixed a vulnerability in Mutt. This update provides the corresponding update for Ubuntu 12.04 ESM. Original advisory details: It was discovered that Mutt incorrectly handled certain requests. An attacker could possibly use this to execute arbitrary code. (CVE-2018-14350, CVE-2018-14352, CVE-2018-14354, CVE-2018-14359, CVE-2018-14358, CVE-2018-14353 ,CVE-2018-14357) It was discovered that Mutt incorrectly handled certain inputs. An attacker could possibly use this to access or expose sensitive information. (CVE-2018-14355, CVE-2018-14356, CVE-2018-14351, CVE-2018-14362, CVE-2018-14349)

An issue was discovered in Mutt before 1.10.1 and NeoMutt before 2018-07-16. They have a buffer overflow via base64 data.

An issue was discovered in Mutt before 1.10.1 and NeoMutt before 2018-07-16. imap/message.c has a stack-based buffer overflow for a FETCH response with a long RFC822.SIZE field.

A flaw was found in mutt before 1.10.1. There is a path traversal flaw for UID values in POP bcache directory.

References:

http://www.mutt.org/news.html https://gitlab.com/muttmua/mutt/blob/master/ChangeLog