CVE-2026-60074 Affecting libdate-manip-perl package, versions <6.99-2
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-DEBIANUNSTABLE-LIBDATEMANIPPERL-18470444
- published31 Jul 2026
- disclosed30 Jul 2026
Introduced: 30 Jul 2026
NewCVE-2026-60074 (opens in a new tab)How to fix?
Upgrade Debian:unstable libdate-manip-perl to version 6.99-2 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream libdate-manip-perl package and not the libdate-manip-perl package as distributed by Debian.
See How to fix? for Debian:unstable relevant fixed versions and status.
Date::Manip versions through 6.99 for Perl return corrupted dates via non-ASCII decimal digits that pass the numeric range tests in check.
The parse regexes capture year, month and day with the \d shorthand, which on a character string matches the whole Unicode decimal digit property \p{Nd} and not just [0-9]. Date::Manip::Base::check then validates the captured fields with numeric comparisons alone ($y<1 || $y>9999, $m<1 || $m>12, $d<1 || $d>$days), and _parse_check stores the numified fields ($y+0). Perl truncates a string at the first character that is not an ASCII digit, so a field whose leading characters are ASCII digits numifies to an in-range prefix and satisfies every test: a year field of three ASCII digits followed by U+0664 ARABIC-INDIC DIGIT FOUR numifies to 202, giving the year 0202, and one non-ASCII digit in the month or day field shifts those fields the same way. The hour, minute and second fields match explicit ASCII character classes (0?[0-9], [0-5][0-9]) and do not shift, though a non-ASCII digit in a fractional hour or minute field truncates the fraction.
Any caller that passes an untrusted character string to ParseDate() or Date::Manip::Date->parse() can get back a date that differs from the string it parsed, with no parse error. Where the parsed date gates logic such as an expiry check or a retention window, the shift goes unnoticed.
References
- https://security-tracker.debian.org/tracker/CVE-2026-60074
- https://metacpan.org/release/SBECK/Date-Manip-6.99/source/lib/Date/Manip/Base.pm#L602-614
- https://metacpan.org/release/SBECK/Date-Manip-6.99/source/lib/Date/Manip/Date.pm#L1536-1539
- https://security.metacpan.org/patches/D/Date-Manip/6.99/CVE-2026-60074-r1.patch
- http://www.openwall.com/lists/oss-security/2026/07/30/19
- https://github.com/SBECK-github/Date-Manip/pull/54