CVE-2009-1490 json
Heap-based buffer overflow in Sendmail before 8.13.2 allows remote attackers to cause a denial of service (daemon crash) and possibly execu…
published 2009-05-05 17 y ago modified 2026-06-16 4 mo ago also EUVD-2009-1487
- cvss
- 5.0
- version 2.0, NVD
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 12.6%
- EPSS 12.6% chance of exploitation in 30 days, percentile 96%
- public exploits
- 1
- Exploit-DB
Summary
Heap-based buffer overflow in Sendmail before 8.13.2 allows remote attackers to cause a denial of service (daemon crash) and possibly execute arbitrary code via a long X- header, as demonstrated by an X-Testing header.
Patch / fix
- sendmail Debian 14, Debian 13, Debian 12 8.13.2-0
debian advisories DEBIAN-CVE-2009-1490
- sendmail.org/releases/8.13.2 advisory
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2009-1490 updated
sendmail: long first header can overflow into message body
-
Red Hat All currently supported Red Hat productsnot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Timeline
- Published
- First public exploit (EDB-32995)
Exploit prediction
12.61% chance of exploitation in the next 30 days, higher than 96% of all scored CVEs (FIRST EPSS, 2026-11-08).
Exploits and checks
- EDB-32995 Sendmail 8.12.x - 'X-header' Remote Heap Buffer Overflow (PoC) dos, 2009-05-27
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| NVD | 2.0 | 5.0 | AV:N/AC:L/Au:N/C:N/I:N/A:P |
Classification
- Weakness
-
- CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer
References
-
sendmail.org
/releases/8.13.2
patch, vendor-advisory
- nmrc.org /~thegnome/blog/apr09/
-
exchange.xforce.ibmcloud.com
/vulnerabilities/50355
vdb-entry
Sources
- CVE List CVE-2009-1490
- NVD CVE-2009-1490
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.