CVE-2026-60074

Date::Manip versions through 7.00 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.

Weakness

The product receives an input value that is used as a resource identifier or other type of reference, but it does not validate or incorrectly validates that the input is equivalent to a potentially-unsafe value.

Affected Software

Name	Vendor	Start Version	End Version
Libdate-manip-perl	Ubuntu	upstream	*

Extended Description

Attackers can sometimes bypass input validation schemes by finding inputs that appear to be safe, but will be dangerous when processed at a lower layer or by a downstream component. For example, a simple XSS protection mechanism might try to validate that an input has no “” tags using case-sensitive matching, but since HTML is case-insensitive when processed by web browsers, an attacker could inject “” and trigger XSS.

Potential Mitigations

Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

NVD	https://nvd.nist.gov/vuln/detail/CVE-2026-60074
CWE	https://cwe.mitre.org/data/definitions/1289.html

Improper Validation of Unsafe Equivalence in Input

Weakness

Affected Software

Extended Description

Potential Mitigations

References