Practical Linux guidance for safer servers and self-hosted systems.Linux • Security • Self-hosting • Practical tools
Linux Server Basics / Hardening

Postfix Security Update DSA-6430-1: Why There's No CVE, and What Actually Got Fixed

Debian Security Advisory DSA-6430-1, published August 11, 2026, patches Postfix but lists no CVE number — just “CVE ID: not yet available.” That’s not a scanner glitch. The detail behind it lives in Postfix maintainer Wietse Venema’s own upstream announcement, which itemizes roughly a dozen defects directly rather than through CVE entries. If you run Postfix on Debian Trixie, upgrade to 3.10.13-0+deb13u1. Most of the batch is denial-of-service or policy-bypass, not remote code execution, and only two of the disclosed items are actually reachable by a remote SMTP client.

What DSA-6430-1 actually fixes, and why there’s no CVE

Debian’s advisory text is one sentence: “Several vulnerabilities were discovered in postfix, a high-performance mail transport agent, which could result in denial of service or policy bypass.” No CVE ID is attached, and as of this writing the Debian security tracker’s postfix page still shows no CVE cross-reference for DSA-6430-1.

That’s because the technical substance comes from upstream, not a CVE-assigning body. Wietse Venema published postfix-3.11.6 and six legacy branch releases on August 10, 2026 — the day before the Debian advisory — with a full itemized defect list. Debian trixie’s security fix (3.10.13-0+deb13u1) corresponds to the legacy 3.10.13 release in that same announcement.

If you searched a CVE database for “DSA-6430” and found nothing, that’s expected: most of these defects were reported directly to Venema by security researchers rather than routed through a CVE numbering authority. Absence of a CVE here does not mean absence of a real fix — it means the disclosure took a different path.

The two defects that matter for an internet-facing mail server

Venema’s announcement lists close to a dozen items, but only two are reachable by a remote SMTP client without local access:

Defect Type Introduced File
MAIL FROM/RCPT TO state desync after smtpd_end_of_data_restrictions rejection Policy bypass Postfix 2.2 (2004) smtpd/smtpd.c
SMTP command-history memory exhaustion via many small BDAT requests Denial of service Postfix 3.4 (2018) smtpd.c

The policy-bypass defect is the more interesting of the two. Postfix’s SMTP server failed to reset MAIL FROM/RCPT TO command state after smtpd_end_of_data_restrictions rejected a message. A crafted remote client could exploit that by sending RCPT TO and DATA without a fresh MAIL FROM, delivering a second message in the same session — and because a recipient counter was already above 1, smtpd_end_of_data_restrictions skipped check_recipient_access constraints on that second message. The same missing-reset bug also affected Milter support: if a Milter had already approved one message’s envelope, the Postfix SMTP server let a second message through without re-running Milter policy checks. If you rely on check_recipient_access or Milter-based filtering as an access-control layer in front of a mail server, this is the item that actually matters to you.

The DoS defect is simpler: sending a large number of very small BDAT (chunked DATA) requests could exhaust memory used to track SMTP command history. Both of these were reported by OpenAI Security.

Everything else in the announcement is either local-only or explicitly described by upstream as having no exploitable effect: address-verification cache poisoning requires local postdrop access; several read-after-free and uninitialized-memory-read items in postscreen_dnsbl.c, inet_connect.c, and postscreen_haproxy.c are described by upstream as having “no effect on program execution” or producing only garbage log output; a DNS-record over-read of up to six bytes and a postsuper queue-filename over/under-read are both stated as producing “no crash, information leak, or privilege escalation.” The remainder are code-hygiene fixes — an integer over-shift in the queue-file parser, a non-transitive IPv4 address comparison, and a duplicate-suppression inefficiency in the fast-flush server.

Debian, and everyone else: which package version do you need

Debian trixie (13): the fix is in the security pocket at 3.10.13-0+deb13u1. As of this writing, trixie’s main archive still carries 3.10.11-0+deb13u1, which is vulnerable — you need the security-pocket version specifically, not just the latest trixie main package.

Upstream (any distro, tarball install): current stable is 3.11.6. Legacy branches also received matching fixes on the same day: 3.10.13, 3.9.14, 3.8.20, 3.7.22, 3.6.20, and 3.5.27. Note upstream’s own caveat: these legacy releases do not include separately-issued patches for “large SMTP inputs” and “TLSA parsing” (both June 2026) or earlier SMTP smuggling fixes — those still need to be applied on top if you haven’t already.

Ubuntu: no Ubuntu Security Notice was located covering this specific batch as of this writing. Don’t confuse this with USN-8253-1, published back on May 7, 2026 — that one fixed a different, earlier-disclosed issue (CVE-2026-43964, a crash triggered by malformed enhanced status codes) and is unrelated to DSA-6430-1. If you’re on Ubuntu, check your installed Postfix version directly rather than assuming either notice covers you.

What the AI-assisted disclosure sourcing means for you

Venema’s announcement credits the defects to “Qualys assisted by Claude Mythos Preview, and by OpenAI Security,” and notes that “more than half date from 20 or more years ago” — several trace back to before Postfix’s first public alpha release in 1997. That framing matters for how you prioritize this update.

This isn’t a freshly discovered exploit chain circulating in the wild. It’s the output of newer automated and AI-assisted code-review tooling finding latent defects that have sat in a mature, widely-deployed C codebase for two decades or more. Treat this update on your normal patch cadence rather than as an emergency — but don’t skip it either. The two remotely-reachable items (the policy-bypass state desync and the BDAT memory-exhaustion DoS) are real, and Postfix is a network-facing daemon by definition.

Expect more of this pattern through the rest of 2026: mature, long-lived daemons getting AI-assisted audits that surface a batch of old, low-drama defects at once, frequently without individual CVE numbers. Judge each one on what’s actually remotely reachable, not on the size of the defect list.

Sources and next steps

  1. Confirm your installed Postfix version and package source (Debian, Ubuntu, or upstream tarball).
  2. On Debian trixie, verify the security-pocket version (3.10.13-0+deb13u1) is available as a candidate before upgrading — if it isn’t showing yet, your package lists may need refreshing.
  3. If you rely on check_recipient_access or a Milter for policy enforcement on inbound mail, that’s the item in this batch most relevant to your setup.
  4. On Ubuntu or an upstream/tarball install, check your version directly — don’t assume either USN-8253-1 or a future USN covers this batch.

Primary sources:

For the same triage discipline applied to a CVE-heavy advisory the day before this one, see the Caddy DSA-6429-1 breakdown. For another advisory where the public text was too sparse to act on without going upstream, see the BIND9 DNSSEC advisory triage. And for the general discipline of not skipping routine-looking update notices, see why unattended upgrades don’t cover everything.