{"id":"CVE-2026-60074","summary":"Date::Manip versions through 7.00 for Perl return corrupted dates via non-ASCII decimal digits that pass the numeric range tests in check","details":"Date::Manip versions through 7.00 for Perl return corrupted dates via non-ASCII decimal digits that pass the numeric range tests in check.\n\nThe 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\u003c1 || $y\u003e9999`, `$m\u003c1 || $m\u003e12`, `$d\u003c1 || $d\u003e$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.\n\nAny caller that passes an untrusted character string to ParseDate() or Date::Manip::Date-\u003eparse() 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.","modified":"2026-09-05T11:45:28.663864855Z","published":"2026-07-30T13:42:03.068Z","related":["SUSE-SU-2026:23218-1","SUSE-SU-2026:23229-1","SUSE-SU-2026:3537-1","SUSE-SU-2026:3551-1","openSUSE-SU-2026:11457-1","openSUSE-SU-2026:21510-1","openSUSE-SU-2026:21552-1"],"database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/60xxx/CVE-2026-60074.json","cna_assigner":"CPANSec","cwe_ids":["CWE-1289"]},"references":[{"type":"WEB","url":"http://www.openwall.com/lists/oss-security/2026/07/30/19"},{"type":"WEB","url":"https://cpan.org/modules"},{"type":"WEB","url":"https://metacpan.org/release/SBECK/Date-Manip-6.99/source/lib/Date/Manip/Base.pm#L602-614"},{"type":"WEB","url":"https://metacpan.org/release/SBECK/Date-Manip-6.99/source/lib/Date/Manip/Date.pm#L1536-1539"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/60xxx/CVE-2026-60074.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-60074"},{"type":"REPORT","url":"https://github.com/SBECK-github/Date-Manip/pull/54"},{"type":"FIX","url":"https://security.metacpan.org/patches/D/Date-Manip/6.99/CVE-2026-60074-r1.patch"},{"type":"PACKAGE","url":"https://github.com/SBECK-github/Date-Manip"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://github.com/sbeck-github/date-manip","events":[{"introduced":"0"},{"fixed":"0bf04709c1719fd3fbf062701b1112eee8a7a027"}],"database_specific":{"extracted_events":[{"introduced":"0"},{"last_affected":"7.00"},{"fixed":"7.00"}],"source":["AFFECTED_FIELD","DESCRIPTION"]}}],"versions":["v6.99","v6.98","v6.97","v6.96","v6.95","v6.94","v6.93","v6.92","v6.91","v6.90","v6.89","v6.88","v6.87","v6.86","v6.85","v6.84","v6.83","v6.82","v6.81","v6.80","v6.79","v6.78","v6.77","v6.76","v6.75","v6.74","v6.73","v6.72","v6.71","v6.60","v6.59","v6.58","v6.57","v6.56","v6.55","v6.54","v6.53","v6.52","v6.51","v6.50","v6.48"],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-60074.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"}]}