This commit was released in GNU mailutils version 3.13.

comment #1:

> Fixed in 4befcfd015256c568121653038accbd84820198f. Thank you.

Thanks! Are there any plans to make a release?

I ask because it makes it a lot easier to distribute fixes downstream (Gentoo for us) and we're keen because of the security impact here.

mail(1) processes escape sequences in message bodies unless given -E 'set escape'. This is fine for interactive use, but non-interactively it seems like nothing but a bad surprise.

This creates a vulnerability any time some content under an attacker's control is piped to mailutils' mail, unless that -E option is added. Other mail(1) implementations have disabled escape sequences in non-interactive mode since at least ~2002, for instance:

https://salsa.debian.org/debian/bsd-mailx/-/blob/50e29dfc5573ee2f03d814b7ae186dc3cc50a7da/collect.c#L161

A recent example of such mailutils behavior leading to an RCE vulnerability is https://github.com/fail2ban/fail2ban/security/advisories/GHSA-m985-3f3v-cwmm

fail2ban is treating that as a bug in their software, but it's a mailutils-specific bug, and a mailutils-specific fix, which breaks for any other mail(1) that doesn't use -E the same way.