On August 10, 2026, Wietse Venema released Postfix 3.11.6, along with coordinated updates for six legacy branches: 3.10.13, 3.9.14, 3.8.20, 3.7.22, 3.6.20, and 3.5.27. If you run mail on Linux, you almost certainly run Postfix. You should update.

The release is unusual for two reasons: the scope of what was found, and how it was found.

How the bugs were discovered

Qualys, working with Anthropic’s Claude Mythos Preview, and separately OpenAI Security, ran an AI-assisted audit of the Postfix codebase — over 150,000 lines of C accumulated across nearly three decades of single-developer maintenance. The results were, to put it charitably, humbling. More than half of the discovered defects date from 20 or more years ago. The oldest traces back to before Postfix’s first public alpha release in April 1997.

Venema acknowledged this directly in the release notes: “The number of defects may seem large, but considering that they were found in a code base of over 150 thousand lines, the error rate is still lower than what I designed for.” That’s either reassuring or terrifying depending on how you feel about legacy C.

What was actually fixed

The headline issue is a policy bypass that has been sitting in Postfix 2.2 since November 2004. When smtpd_end_of_data_restrictions rejects a message, Postfix was failing to reset its MAIL FROM and RCPT TO state. A crafted SMTP client could exploit this to send a second message immediately after — one that bypasses check_recipient_access constraints entirely, because the recipient counter is still greater than one from the previous transaction.

If you use Milter-based spam filtering, the same bug bites you differently: after a rejection, the Milter client remains stuck in an “accept” state for the smuggled message. Your filter inspects the first envelope but the second delivery slips through.

Beyond policy bypass, the release addresses two denial-of-service paths: memory exhaustion via a large number of very small BDAT requests (introduced 2018), and an address verification cache poisoning bug from 2002 that lets a local user inject a negative cache entry for a legitimate address, causing the SMTP server to reject mail it should accept.

There are also several crashes: a null pointer read when processing a malformed Dovecot AUTH server response, and another null pointer crash triggered by a BDAT command error when RCPT TO state wasn’t properly reset.

The memory safety issues are mostly low-severity but numerous — read-after-free in postscreen_dnsbl.c, an uninitialized read in the HaProxy client path, an over-read in the DNS client that has been present since 1997. None of these enable privilege escalation based on available information, but they represent the kind of accumulated technical debt that tends to look worse under close examination.

What you need to do

Check your running version:

postconf mail_version

Then update to the appropriate branch. If you’re on a supported branch (3.8 through 3.11), grab the corresponding patch release. If you’re on 3.5, 3.6, or 3.7 — all officially out of support — this release includes fixes for them too, but the announcement is explicit that those branches do not include the earlier advisories from June 2026 covering large SMTP inputs, TLSA parsing, and SMTP smuggling. You’ll need to apply those separately.

Most Linux distributions have already backported the relevant fixes into their package repositories. On Debian/Ubuntu: apt update && apt upgrade postfix. On RHEL/AlmaLinux/Rocky: dnf update postfix. Verify the installed version afterward.

The policy bypass is the fix to prioritize. It’s been in production code since 2004 and affects anyone using smtpd_end_of_data_restrictions — a common configuration in spam-filtering setups.

What this means for kalfaoglu.net customers

Your email is processed by Postfix on our mail servers. We’ve already applied the 3.11.6 updates across the stack. You don’t need to take any action. If you manage your own VPS or dedicated server and run Postfix directly, update now — the policy bypass in particular is the kind of flaw that, once documented in a public release announcement, becomes a recipe for exploitation.

If you’re unsure what version of Postfix you’re running, open a support ticket and we’ll check for you.

The broader takeaway from this release is that AI-assisted code auditing is starting to find things that decades of human review missed. A 30-year-old codebase written by one person, maintained carefully and conservatively, still yielded a batch of defects that had sat untouched since before many of its current users were born. The tools are getting better at finding them. It’s worth keeping up.

Sources: