CVE-2023-51764
Postfix ≤ 3.5.23
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:NCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2023-51764 is a medium-severity Insufficient Verification of Data Authenticity (CWE-345) vulnerability in Postfix Postfix. Its CVSS base score is 5.3 (Medium).
Operationally, ranked in the top 15% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
Postfix through version 3.8.5 is vulnerable to SMTP smuggling because it accepts the sequence <LF>.<CR><LF> in SMTP data even when other mail servers reject it. The flaw stems from insufficient restrictions on bare newlines and pipelining, allowing malformed messages to be processed differently across implementations. Affected deployments that lack the recommended smtpd_data_restrictions or smtpd_discard_ehlo_keywords settings are exposed by default.
Remote attackers who can reach an unpatched or misconfigured Postfix server can inject messages that carry a spoofed MAIL FROM address. This permits bypass of SPF checks on receiving systems that interpret the message differently, enabling phishing or other spoofed-mail campaigns without authentication.
Advisories from Red Hat and oss-security lists recommend applying the configuration smtpd_data_restrictions=reject_unauth_pipelining together with smtpd_discard_ehlo_keywords=chunking, or upgrading to Postfix 3.5.23, 3.6.13, 3.7.9, 3.8.4 or later and enabling smtpd_forbid_bare_newline=yes. These steps close both the original smuggling vector and variant newline-handling attacks.
The EPSS score has remained at 0.2846 since disclosure with no material increase observed.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-56453
Vulnerability Data
Postfix through 3.8.5 allows SMTP smuggling unless configured with smtpd_data_restrictions=reject_unauth_pipelining and smtpd_discard_ehlo_keywords=chunking (or certain other options that exist in recent versions). Remote attackers can use a published exploitation technique to inject e-mail messages with a spoofed MAIL FROM address, allowing…
more
bypass of an SPF protection mechanism. This occurs because Postfix supports <LF>.<CR><LF> but some other popular e-mail servers do not. To prevent attack variants (by always disallowing <LF> without <CR>), a different solution is required, such as the smtpd_forbid_bare_newline=yes option with a Postfix minimum version of 3.5.23, 3.6.13, 3.7.9, 3.8.4, or 3.9.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
Directly requires independent verification of matching output before adverse decisions, mitigating insufficient authenticity checks on data from external sources.
Use of approved PKI certificates provides verifiable data authenticity and origin for communications and artifacts.
Mandates provision of authenticity and integrity artifacts that enable verification of name/address resolution data.
Requires explicit verification of data authenticity from authoritative sources, preventing acceptance of unauthenticated resolution responses.
Control requires verification of data authenticity/integrity (e.g., checksums) after aggregation/packing, directly reducing exploitation of insufficient verification before transmission.
Time synchronization supports reliable freshness verification when checking data authenticity across systems or components.
Mandates verification of data authenticity for software, firmware, and information.
Provenance documentation and monitoring directly enables verification of authenticity for components and data throughout their history.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
A.8.24's guidance on identifying protection levels, selecting algorithms/strength for authenticity/integrity (items b,f), using cryptography for transmitted/stored data (c), and key management directly stops many CWE-345 exploits by ensuring verifiable authenticity; however, it leaves a bounded remainder where verification logic itself is flawed or absent (e.g. accepting unverified signatures or weak schemes), as the control depends on correct implementation in other mechanisms.
Secure SDLC incorporates authenticity verification requirements throughout development.
Application security requirements can mandate data authenticity verification mechanisms.
Secure coding practices include implementing proper data authenticity checks.
Security testing can detect missing or weak data authenticity verification.
Secure authentication of data sources ensures only valid, authentic data is accepted.
Hardening callouts derived
DISA STIG baselines are authored against specific weaknesses. Where this CVE cites a broad weakness class, the mapping is not asserted at that abstraction (owner ruling, 2026-09-25: grade only at Base and below), so no rule is shown here rather than a rule shown against the wrong grain.