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

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

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

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

An issue was discovered in Mutt before 1.10.1 and NeoMutt before 2018-07-16. imapquotestring in imap/util.c has an integer underflow.

An issue was discovered in Mutt before 1.10.1 and NeoMutt before 2018-07-16. imap/util.c mishandles ".." directory traversal in a mailbox name.

An issue was discovered in Mutt before 1.10.1 and NeoMutt before 2018-07-16. They allow remote IMAP servers to execute arbitrary commands via backquote characters, related to the mailboxes command associated with an automatic subscription.

An issue was discovered in Mutt before 1.10.1 and NeoMutt before 2018-07-16. pop.c mishandles a zero-length UID.

A flaw was found in mutt before 1.10.1. When "subscribing" to an IMAP mailbox, either via $imapchecksubscribed, or via the <subscribe> function in the browser menu, the lack of proper input parsing may lead to remote code injection from a malicous IMAP server.

Upstream patch:

References:

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

Buffer overflow in copy.c in Mutt before 1.5.23 allows remote attackers to cause a denial of service (crash) via a crafted RFC2047 header line, related to address expansion.

Buffer overflow in Mutt 1.4.2 might allow local users to execute arbitrary code via "&" characters in the GECOS field, which triggers the overflow during alias expansion.

Mutt 1.5.13 and earlier does not properly use the --status-fd argument when invoking GnuPG, which prevents Mutt from visually distinguishing between signed and unsigned portions of OpenPGP messages with multiple components, which allows remote attackers to forge the contents of a message without detection.

Race condition in the safeopen function in the Mutt mail client 1.5.12 and earlier, when creating temporary files in an NFS filesystem, allows local users to overwrite arbitrary files due to limitations of the use of the OEXCL flag on NFS filesystems.

The muttadvmktemp function in the Mutt mail client 1.5.12 and earlier does not properly verify that temporary files have been created with restricted permissions, which might allow local users to create files with weak permissions via a race condition between the mktemp and safefopen function calls.